목차
프레임
전송데이터 처리 단위
데이터 링크 계층에서는 전송 데이터를 프레임 Frame 이라는 작은 단위로 나누어 처리한다.
[전송 프레임에 포함된 정보]
- 체크섬 Checksum: 상위 계층에서 보낸 전송 데이터의 오류를 확인하기 위함
- 송수신 호스트의 주소
- 기타 프로토콜에서 사용하는 제어 코드
[정보처리]
- 1) 프레임을 전송받은 수신 호스트는 제일 먼저 체크섬을 확인
➡ 전송 중에 프레임 변형 오류가 발생했는지 확인해야 함 - 2) 오류가 발생하면 부정 응답 프레임을 회신하여, 송신 호스트가 원래의 데이터를 재전송하도록 요구함으로써 복구 과정을 시작해야 함
프레임 내용에 포함되는 정보는 프로토콜의 용도에 따라 다르다.
일반적으로 프레임은 내부 정보를 표현하는 방식에 따라 문자 프레임과 비트 프레임으로 구분된다.
문자 프레임
문자 프레임 Character Frame: 프레임 내용이 문자로 구성되므로 문자 데이터를 전송할 때 사용.
➡ 문자 프레임 방식은 8비트 단위(또는 ASCII 문자 코드) 의 고정 크기로 동작한다.
프레임의 구조
하나의 프레임 단위를 구분하기 위해 프레임의 앞뒤에 ASCII 코드의 특수 문자를 이용한다.
- 각 프레임의 시작 위치: DLE, STX 문자를 추가
- 각 프레임의 끝나는 위치: DLE . ETX를 추가
➡ 프레임의 다른 정보와 구분할 수 있도록 함
프레임의 시작과 끝 위치에 프레임 구분용 특수 문자를 사용하며,
그 사이에는 프로토콜에서 정의한 제어 정보와 전송 데이터를 포함한다.
[PROBLEM]
이 방식에서 발생 가능한 문제점은 아래의 그림처럼 데이터의 내용 중에 DLE . STX나 DLE . ETX 문자가 포함될 수 있다는 것이다.
이는 프레임을 수신하는 호스트가 프레임의 시작과 끝 위치를 결정하는 데 혼선을 준다.
이러한 현상은 문자 프레임 방식을 사용해 실행 파일과 같은 이진 코드 데이터를 전송하는 경우에 발생할 확률이 높다.
문자 스터핑
문자 스터핑 Character Stuffing: 문자 프레임 내부의 전송 데이터에 DLE 문자가 포함되면서 발생하는 혼란을 예방하는 방법이다.(위의 PROBLEM 해결)
문자 프레임의 전송 과정에서 제어 문자를 추가하는 기능
해결을 위해 아래 그림처럼 송신 호스트가 전송하는 데이터를 미리 조작함으로써 혼선의 여지를 없앨 수 있다.
즉, 전송 데이터가 DLE 문자를 포함하면 DLE 문자 다음에 DLE 문자 하나를 강제로 추가한다.
[처리과정] 1) 문자열 스터핑
수신 호스트는 프레임 내용에 DLE 문자가 연속해서 두 번 나타나면,
두 번째 DLE는 송신 호스트가 임의로 추가한 문자라고 판단할 수 있다.
2) 스터핑 제거
상위 계층인 네트워크 계층에 데이터를 전달하기 전에 둘 중 하나를 제거해야 한다.
즉 송신 호스트가 최초에 전송한 프레임인 [PROBLEM]형태와 동일한 결과가 된다.
[문자 스터핑 기능이 올바르게 동작하는 이유]
프레임의 시작과 끝을 나타내는 제어 코드에는 어떤 경우에도 DLE 문자가 연속해서 두 번 발생하지 않기 때문.
비트 프레임
비트 프레임 Bit Frame: 문자 단위의 가정을 없애고, 임의의 비트 패턴 데이터를 전송
프레임의 시작과 끝 위치에 플래그 Flag 라는 특수하게 정의된 비트 패턴(01111110) 을 사용해 프레임 단위를 구분함
프레임의 구조
데이터를 전송하기 전에 프레임의 좌우에 플래그를 추가하고,
수신 호스트는 이 플래그를 제거해 전송 데이터와 필요한 제어 정보를 상위 계층에 전달할 수 있다. 
[PROBLEM]
문자 프레임 방식에서 DLE 패턴이 프레임의 내용에 나타날 가능성이 있는 것처럼,
비트 프레임 방식에서도 플래그와 동일한 비트 패턴을 포함할 수 있다.
➡ 데이터의 내용에 이 패턴이 나타나면 전송하기 전에 이를 적당히 조작하는 과정이 필요하다.
비트 스터핑
비트 프레임 방식에서는 송신 호스트가 전송하고자 하는 데이터의 내용 중에,
값이 1인 패턴이 연속해서 5번 발생하면 강제로 0을 추가해 전송한다.
플래그는 1이 연속해서 6개 나오는 패턴이므로 원천적으로 데이터 내용에 플래그 패턴이 발생하는 것을 차단하기 위함이다.
수신 호스트가 수신한 데이터의 내용에서 플래그 패턴 외에는 어떤 경우에도 1이 연속해서 5 개를 넘지 않는다.
다시 말해서 플래그 패턴과 동일한 형태의 패턴이 데이터 링크 계층의 전송 데이터에는 발생할 수 없다.
이와 같은 기능을 비트 스터핑 Bit Stuffing 이라 하며, 수신 호스트는 송신 과정에서 추가된 0을 제거하여 원래의 데이터를 상위 계층에 전달한다.
다항 코드
프레임 전송 과정에서 발생하는 오류를 극복하는 방법
- 오류 검출 코드 삽입: 전송 프레임에 오류 검출 코드를 넣어 수신 호스트가 전송 과정의 오류를 검출하도록 하는 것
➡ 이 방법의 오류 복구는 주로 재전송으로 이루어짐.- 패리티 비트 추가: 가장 간단한 오류 검출 코드 방법
➡ 컴퓨터 네트워크에서는 일반적으로 다항 코드 방식을 사용.
- 패리티 비트 추가: 가장 간단한 오류 검출 코드 방법
- 프레임에 오류 복구 코드 삽입: 수신 호스트가 오류 검출과 복구 기능을 모두 수행하도록 하는 것
- 해밍 코드 Hamming Code: 1비트 오류를 검출하고 복구하는 기능이 있음.
- 순방향 오류 복구 FEC: 오류 복구 코드를 사용해 수신 호스트가 오류 복구 기능을 수행하는 방식
오류 검출
[역방향 오류 복구 BEC]
= BEC (Backward Error Correction)
= ARQ (Automatic Repeat reQuest)
네트워크에서는 일반적으로 오류 복구 코드를 이용한 순방향 오류 복구 방식은 사용하지 않고, 재전송 Retransmission 방식을 이용해 오류를 복구한다.
역방향 오류 복구 기능을 수행하려면, 수신한 프레임에 오류가 있는지 판단할 수 있어야 한다.
즉 당연히 오류가 있어서 재전송을 하려면 오류가 있는지부터 알 수 있어야 하는 것이다.
이렇게 오류를 판단하는 것은,
➡ 송신 호스트가 오류를 검출하기 위한 코드를 전송 데이터와 함께 송신해야 한다.
➡ 오류 검출 코드는 패리티 비트, 블록 검사, 다항 코드 등을 이용해 생성할 수 있다.
패리티 비트
의미: 1바이트(8비트) 구조에서 패리티 Parity 비트는 7비트의 ASCII 코드를 제외한 나머지 1비트임
패리티 비트는 전송 과정에서 1비트 오류를 검출하기 위한 것으로,
패리티 비트를 포함해 1의 개수가 짝수나 홀수 개가 되도록 한다.
[짝수 패리티 Even Parity]
데이터 끝에 패리티 비트를 추가해 전체 1의 개수를 짝수로 만들어준다.
EX)
1101001이라는 데이터를 짝수 패리티 Even Parity 방식을 사용해 전송하려면,
➡ 11010010의 형태로 만들어 전송
🖥️ 오류 검출 방법
데이터 전송 과정에서 1비트 오류가 발생하면 1의 개수가 홀수개로 바뀐다.
예를 들어, 위의 데이터 전송 과정에서 세 번째 비트가 0에서 1로 바뀌면 수신 호스트는 11110010을 받는다.
[홀수 패리티 Odd Parity]
짝수 패리티와 반대로, 1의 개수를 홀수로 만드는 것이다. 
➡ 송신 호스트와 수신 호스트는 짝수 패리티나 홀수 패리티 중 동일한 한 가지 방식을 사용해야 한다.
블록 검사
[기존 방식의 문제]
패리티 방식을 이용한 오류 검출 기법은 1비트 오류에 간단히 적용할 수 있다.
그러나 짝수 개의 비트에서 오류가 발생하면 오류가 검출되지 않는다는 문제점이 있다.
예를 들어, 2비트의 데이터가 깨지면 1의 개수는 원래의 데이터와 같은 짝수나 홀수를 유지한다.
[블록 검사 Block Sum Check]
다수의 비트에서 오류가 발생할 때 오류를 검출하는 방법
이 방식은 같이 여러 개의 바이트를 하나의 블록 으로 구성한 후 교차 검사를 한다.
➡ 블록 데이터의 수평과 수직 방향에 모두 패리티 비트를 둠으로써 오류 검출 확률을 높인다.
그림에서 오른쪽에 표시한 패리티 비트는 수평 방향으로 짝수 패리티를,
아래쪽에 블록 검사 비트로 표시한 데이터는 수직 방향으로 짝수 패리티를 적용한 것이다.
➡ 수평 방향으로 짝수 개의 비트가 깨지면 수직 방향의 블록 검사 비트로 오류를 검출하고,
➡ 수직 방향으로 짝수 개의 비트가 깨지면 수평 방향의 패리티 비트로 오류를 검출한다.
[PORBLEM]
이 방식의 문제점은 전송되는 데이터의 양과 비교해 오류 검출을 위한 오버헤드가 크다
또 수평과 수직 방향에서 모두 사각형 형태로 짝수 개의 데이터 오류가 발생하면 이를 검출하지 못한다.
다항 코드
[CRC Cyclic Redundancy Code]
다항 코드 Polynomial Code 방식은 현재의 통신 프로토콜 에서 가장 많이 사용하는 오류 검출 기법이다.
특히 일반 네트워크에서 발생하는 오류는 특정 위치에서 집중적으로 발생하는 버스트 에러 Burst Error 형태인 경우가 많은데, 다항 코드 방식은 이런 오류를 검출하는 확률이 높다.
생성 다항식
다항 코드 방식은 계수가 0과 1인 다항식 형태를 기반으로 한다.
다항 코드 방식을 이용한 오류 검사의 동작 원리는 아래 그림과 같다.
m비트의 M(x): 송신 호스트가 전송할 데이터
➡ 데이터 전송 과정에서 n+1비트의 생성 다항식 G(x) 를 사용해 오류 검출 코드를 생성함으로써 오류 제어 기능을 수행함
1) M(x) 준비: m비트의 송신 호스트가 전송할 데이터
2) G(x) 준비: n+1비트의 생성 다항식 3) 체크썸 정보를 위한 나누기 연산을 위해 전송 데이터 M(x) 뒤에 나머지를 보관할 n비트의 공간을 확보하고 이 자리를 모두 0으로 채움
4) 송신 호스트는 전송 데이터 M(x)를 생성 다항식 G(x)로 나누어 체크섬 Checksum 정보를 얻음.
➡ 연산에서 얻은 나머지 값을 체크섬이라 정의
5) 체크섬을 전송 데이터의 뒤에 추가해 수신 호스트에 전달해야 함
[체크섬 계산인 나누기 과정]
발생하는 다항 연산은 모듈로-2 방식으로 이루어짐.
➡ 덧셈의 자리 올림이나 뺄셈의 자리 빌림 과정이 이루어지지 않으므로 덧셈과 뺄셈은 배타적 논리합 Exclusive OR 연산과 동일한 결과를 얻는다.
➡ 즉 한쪽이 1일때만 1 출력
[오류 판단]
수신 호스트는 전송 오류가 발생했는지를 판단하기 위해 수신한 m +n비트의 데이터를 생성 다항식 G(x)로 나누는 연산을 수행한다.
➡ 연결 결과로 얻은 나머지가 0: 전송 오류가 없다고 판단
➡ 연결 결과로 얻은 나머지가 0이 아님: 오류가 발생했다고 판단
체크섬 예시
예를 들어, 생성 다항식 G(x) = x 5 +x 2 + 1이 주어지고, 전송 데이터가 101101001인 경우의 체크섬 계산 과정 앞이 계속 0이 되어 뒤로 나아가야 한다.
계산을 통해 얻은 나머지는 00010이므로, 송신 데이터는 10110100100010이 된다.
수신 호스트는 수신 데이터 10110100100010을 생성 다항식 100101로 나누기 연산을 수행한다.
이때 나머지가 0이면 전송 오류가 없고, 0이 아니면 오류가 발생한 것으로 판단할 수 있다.
다음은 현재 국제 표준으로 널리 이용되는 생성 다항식의 일부이다.
- CRC-12 : \(x^{12} +x^{11} +x^{3} +x^{2} +x^1 +1\)
- CRC-16 : \(x^{16} +x^{15} +x^{2} +1\)
- CRC-CCITT : \(x^{16} +x^{12} +x^{5} +1\)