데이터 링크 계층 프로토콜

데이터 링크 계층은 물리적으로 이웃하여 연결된 두 호스트 가의 신뢰성있는 데이터 전송을 지원함. 이를 위해서는 물리 계층에서 발생하는 전송 오류를 감지고, 복구하는 기능이 필요하다. 오류를 감지하면 송수신 호스트 사이의 오류 복구 과정이 이루어저야 하는데, 컴퓨터 네트워크에서는 주로 재전송 기법을 사용한다. 프로토콜은 네트워크에서 데이터 전송 기능을 수행한다. 이러한 프로토콜과 프레임, 오류 제어, 흐름 제어의 기능에 대해 알아보자. 오류제어(프레임 분실, 변형), 흐름 제어(버퍼 용량부족으로인한 프레임 분실)

 

흐름 제어 : 송신 호스트의 전송 속도를 조절
오류 제어 : 송신 호스트가 전송한 프레임이 분실 혹은 변형 된 상황을 제어

 

 

단방향 프로토콜 

호스트의 버퍼가 유한한 환경이라면 송신 호스트가 전송한 정보 프레임의 수신 작업이 늦어질 때, 버퍼에 일시적으로 보관할 수 있는 프레임의 수가 제한된다. 하여 버퍼 용량 부족으로 프레임 분실 오류가 발생할 가능성이 있다. 이러한 이유로 흐름 제어 기능이 필요하다.

흐름 제어는 주로수 수신 호스트가 송신 호스트의 프레임 전송 시점을 제어하는 형태로 이루어진다. 가장 기본적인 방법은 프레임을 보내고 난 뒤 수신 호스트가 응답 프레임(ACK)을 보내는 것이다.

 

ACK 프레임 : 송신 호스트에게 긍정 응답의 기능 수행, 다음 프레임을 전송하도록 지시하는 흐름 제어 기능도 수행
NAK 프레임 : 부정 응답 프레임으로 정보 프레임의 전송 과정에서 프레임 변형 오류가 발생하면 수신 호스트가 송싱 호스트에게 보내는 프레임

위와 같은 경우는 송신 호스트가 정보 프레임을 전송하고, 이어서 다음 저옵 프레임을 전송하려면 ACK 프레임이 도착하길 기다려야 한다. 이렇게 ACK 프레임이 올때까지 기다려야 하는 프로토콜 방식을 정지-대기 방식이라고 한다. 이러한 방식은 전송 효율이 매우 떨어져 실제로는 거의 사용하지 않는다.

 

송신 호스트가 전송한 프레임이 분실, 변형된 경우에는 아래와 같이 타임 아웃 혹은 NAK 프레임을 추가하여 오류제어와 흐름제어가 가능해진다.

 

아래 그림은 타임 아웃을 추가한 것이다. 송신 호스트는 프레임을 전송한 뒤 타임 아웃을 카운트하여 일정 시간 동안 ACK 응답이 오지 않으면 프레임이 분실되었다고 판단하여 다시 데이터를 재전송한다.

그런데 만약 아래와 같이 프레임은 수신 측에 제대로 도착했지만 수신 측이 회신한 ACK응답이 분실된 경우라면 송신 호스트는 타임 아웃되어 프레임을 재전송 할것이다.

 

아래 그림은 오류 제어를 NAK 프레임을 사용하여 해결하는 그림다.

 

 

---

 

 

슬라이딩 윈도우 프로토콜 (양방향 프로토콜)

실제 통신 환경에서는 대부분 양방향으로 통신이 이루어진다. 슬라이딩 윈도우 프로토콜은 두 호스트 간의 프레임 전송을 위한 일반적인 프로토콜로, 오류 제어와 흐름 제어 기능을 함께 지원한다. 해당 프로토콜은 현재 대부분의 통신 푸로토콜에서 사용하는 방식이다.

 

슬라이딩 윈도우 프로토콜은 아래와 같은 기본 절차를 따른다.

1. 송신 호스트는 데이터와 프레임의 순서번호(Seq num), 오류 검출 코드(checksum)등을 프레임에 표기한 후에 정해진 순서 번호로 순차적으로 송신한다.

2. 수신 호스트의 응답 프레임에 포함되는 내용은 다음에 수신하길 기대하는 프레임의 번호를 표기한다. 이는 즉 긍정 응답 프레임에 기록된 순서 번호 이번까지의 프레임은 모두 정상적으로 수신했다는 의미이다. 

3. 송신 호스트는 송신한 정보 프레임을 내부 버퍼에 유지해야 하는데, 이를 송신 윈도우라고 한다. 송신 윈도우에서 대기중인 프레임은 송신 호스트가 수신 호스트에 프레임 전송을 완료했지만 아직 긍정 응답을 받지 못한 프레임들이다.

4. 수신 호스트는 내부에 수신한 정보 프레임을 보관하기 위해 내부 버퍼인 수신 윈도우를 가진다. 수신 윈도우에는 수신을 기대하는 프레임의 순서 번호가 있기 때문에 프로토콜에 따라 그 크기다 다르다. 선택적 재전송(Selective Retransmission)방식에서는 프레임의 도착이 비순서적일 수 있어 수신 윈도우크기와 송신 윈도우 크기다 동일하다. 그러나 고백N(go-back-n)방식에서는 수신 호스트가 항상 이전에 수신한 프레임의 바로 다음 프레임만을 기다리기 때문에 수신 윈도우의 크기는 1이면 충분하다.

 

슬라이딩 윈도우 프로토콜의 흐름제어:

슬라이딩 윈도우 프로토콜의 슬라이딩 윈도우는 '윈도우의 이동'을 의미한다. 즉 이는 흐름 제어 기능을 의미한다. 수신 호스트가 연속으로 수신할 수 있는 정보 프레임의 개수를 윈도우 크기로 지정함으로써, 송신 호스트의 프레임 전송 속도를 제어하는 것이다.

 

• 순서 번호

정보 프레임에는 프레임 별 고유의 순서 번호라는 일련 번호가 부여된다. 정보 프레임의 내용에는 순서 번호를 위한 공간이 확보되어 있는데, 할당된 공간의 크기가 n비트라고 가정하면 프로토콜에서 사용할 수 있는 순서 번호의 크기는 0 ~ 2^N - 1이다.

 

• 윈도우 크기

슬라이딩 윈도우 프로토콜은 흐름제어를 위해 제공하는 기능. 기본 원리는 임의의 시점에 송신 호스트가 수신 호스트로부터 긍정 응답을 받지 않고도 전송할 수 있는 정보 프레임의 최대 개수인 윈도우 크기를 규정하기 위함이다.

윈도우에 있는 정보 프레임의 관리는 순서 번호를 기반으로 이루어지는데, 이들 순서 번호의 묶음이 결과적으로 윈도우가 되는 것이다. 송신 윈도우에 보관된 프레임은 낮은 순서 번호부터 차례로 처리되는데, 긍정 응답 프레임이 회신되고 나서 오류 없이 전달됨을 확인하면 윈도우에 새로 추가될 정보 프레임의 순서 번호도 순차적으로 높은 번호로 이동할 것이다.

위 그림은 송신 호스트의 버퍼를 도식화한 그림이다. 0, 1, 2, 3...의 순서로 프레임에 번호가 있고, 윈도우의 크기는 3이다.

(a)에서 현재 0, 1, 2를 송신하고 ACK 프레임을 기다리는 상태이다. 그러다 (b)에서 ACK 0을 받고 송신 호스트는 0번 프레임이 수신된것을 확인하고 윈도우에 3번 프레임의 송신이 가능해지고, 송신한 뒤 윈도우에 추가한다.(c)

 

 

연속형 전송 :

정지-대기 방식의 프로토콜은 송신 윈도우의 크기가 1로 이는 전송 효율이 매우 떨어진다. 하여 이러한 상황을 해결하기 위해서는 윈도우 크기를 늘려 ACK 프레임을 받지 않고도 여러 정보 프레임을 연속으로 전송할 수 있어야 하는데, 이러한 방식을 연속형 전송이라고 한다.

물론 이러한 연속형 전송 방식은 전송에 오류가 발생할 수 있는 환경에서는 전송 효율이 떨어질 수 있다. 해서 연속형 전송 방식의 오류를 해결하는 방법에는 고백N 방식과 선택적 재전송 방식이 있다.

 

 

• 고백 N(Go-Back-N) 

 

예를 들어 윈도우 크기가 최대 8인 환경에서 송신 호스트가 10~17번 정보 프레임을 전송하는 경우를 가정했을 때, 12번 프레임에만 오류가 발생한 경우네 고백N방식은 12번 프레임을 포함하여 이후에 전송된 모든 정보 프레임을 재전송한다. 고백N 방식은 오류가 발생한 프레임 뿐 아니라, 정상적으로 수신한 프레임까지 재전송한다는 문제점이 있다. 하여 비효율적으로 보이지만 송수신 호스트 사이의 전송 지연 등에 따라서는 효과적일 수 있다.

위의 그림에서 12번 프레임에 대한 NAK 응답을 수신 호스트가 회신하면 송신 호스트는 12번 프레임부터 재전송한다. 추가적으로 ACK(17)은 17번 프레임이 제대로 도착했다는 의미가 아닌 17번 프레임을 포함하여 이전의 프레임이 모두 제대로 처리되었다는 의미이다.

 

 

 

 

• 선택적 재전송

 

선택적 재전송은 위에서 설명한 예에서 12번 프레임에 대한 NAK이 도착하면 12번 프레임에 대해서만 송신 호스트가 재전송하는 것이다.

이때 수신 호스트가 NAK(12) 응답을 보내기 전까지 수신 호스트는 12번 이후 프레임에 대한 ACK 응답을 보내지 말아야 함에 유의해야 한다.

 

 

 

• 피기배킹

 

양방향 전송 기능을 갖춘 채널 방식에서 송신 호스트와 수신 호스트으 구분 없이, 양방향으로 동시에 정보 프레임과 응답 프레임을 교차하여 전송하는 것이 가능하다. 이때 ACK과 NAK 프레임으로 구성된 응답 프레임의 목적은 상대방이 다음에 전송할 프레임을 지정하기 위함이다. 해서 반드시 응답 프레임을 사용하여 응답 기능을 수행해야하는 것은 아니다. 

정보 프레임의 구조를 적당히 재정의하면 정보 프레임을 전송하면서 응답 기능까지 함께 수행할 수 있다. 이러한 방식으로 프로토콜을 작성하면 응답 프레임 전송 횟수를 줄일 수 있어 전송 효율을 높일 수 있는데, 이것이 피기배킹이다.

 

먼저 피기배킹을 적용하지 않은 상태에서 송수신 호스트가 양방향 전송을 하는 과정을 그림으로 보자.

정보 프레임에 대한 긍정 응답 혹은 부정 응답 프레임이 순서 번호와 함께 별도로 처리되는 것을 볼 수 있다. 

 

아래 그림은 피기 배킹을 적용한 것이다.

A -----  I(0) ---->   B    : A가 B에게 0번째 정보 프레임 전송

A <---- I(0, 0)---   B    : B가 A에게 0번째 정보 프레임 전송과 함께 A로부터 0번째 까지 잘 받았다는 응답 프레임을 함께 보냄

A -----  I(1, 0) ---> B  : A가 B에게 1번째 정보 프레임 전송과 함께 B로부터 0번째 까지 잘 받았다는 응답 프레임을 함께 보냄

A <---- I(1, 0) ---   B  : B가 A에게 1번째 정보 프레임 전송과 함께 B로부터 1번째 까지 잘 받았다는 응답 프레임을 함께 보냄

 

 

 

 

 

 

---

참고 : 

쉽게 배우는 데이터 통신과 컴퓨터 네트워크 -박기현 저