6장 데이터 링크 계층💻

jarden·2022년 12월 28일
0

컴퓨터네트워크

목록 보기
6/7

01. 데이터 링크 계층 프로토콜의 기초


데이터 링크 계층에서 두 호스트가 통신하려면 (a)처럼 일대일 형식의 점대점 방식으로 연결해야 한다. 송신 호스트에서 전송한 프레임은 점대점으로 직접 연결된 수신 호스트에 라우팅 과정 없이 전달된다. 기본적으로 데이터 링크 계층 프로토콜은 (a)와 같은 직접 연결 구조에서 둘 사이의 전송 오류를 감지하고, 이를 복구하는 기능을 지원한다. (b)의 구조를 지원하려면 호스트 주소 개념이 추가로 필요하다.
(b)는 하나의 호스트가 다수의 호스트와 연결된 비대칭 형태로, 이러한 구조를 멀티 드롭 방식이라 한다. 멀티 드롭에서는 하나의 물리 매체를 여러 호스트가 공유하므로, 임의의 호스트에서 전송한 프레임은 물리적으로 다른 모든 호스트에 전달된다. (a)에서는 전송 선로에 두 개의 호스트만 연결되므로 호스트를 구분하기 위한 주소 개념이 필요없다. 그러나 (b)에서는 여러 수신 호스트 중에서 프레임의 목적지 호스트를 지칭하기 위한 주소 개념이 필요하다.
물리 계층을 통해 이루어지는 두 호스트 간의 데이터 전송 과정에서 물리적인 전송 오류가 발생할 수 있다. 이 같은 물리적인 오류를 복구하는 것은 데이터 링크 계층의 기본 역할이다. 따라서 데이터 링크 계층은 상위 계층에 신뢰성 있는 데이터 전송을 보장한다. 신뢰성 있는 논리 선로를 제공하기 위한 오류 제어 방식으로 재전송 기법을 사용한다. 재전송 기법은 송신 호스트가 전송한 프레임에 오류가 발생하면 송신 호스트가 전송 데이터를 재전송하여 오류를 복구하는 것이다.

1. 프레임의 종류

정보 프레임(I 프레임)

  • 상위 계층이 전송을 요구한 데이터를 수신 호스트에 전송하는 용도로 사용
  • 순서번호, 송수신 호스트 정보 등이 포함됨

긍정 응답 프레임(ACK 프레임)

  • 전송 데이터가 올바르게 도착했음을 회신하는 용도
  • 데이터를 수신한 호스트가 데이터를 송신한 호스트에게 전송

부정 응답 프레임(NAK 프레임)

  • 전송 과정에서 프레임 변형 오류가 발생했음을 회신하는 용도
  • 원래의 정보 프레임을 재전송하도록 요청
  • 송신 호스트는 오류가 발생한 프레임을 동일한 순서 번호로 다시 전송

정보 프레임뿐 아니라 긍정 응답, 부정 응답 프레임에도 회신하고자 하는 정보 프레임의 순서 번호가 포함된다. 따라서 정보 프레임의 송신 호스트는 몇 번 프레임이 제대로 도착하고 몇 번 프레임에서 오류가 발생했는지를 응답 프레임의 순서 번호로 판단할 수 있다.


2. 오류·흐름 제어가 없는 프로토콜

  • 가정 : 가장 이상적인 통신환경
    - 단방향 통신 : 데이터는 송신 호스트에서 수신 호스트로만(한쪽 방향으로만) 전달
    - 전송 오류 없는 물리 매체 : 통신 채널에서는 전송 오류가 발생하지 않음
    - 무한 개의 수신 버퍼 : 수신 호스트의 버퍼 수는 무한함
    송신 호스트가 전송한 프렝미은 수신 호스트에 항상 안전하게 도착하므로 송신 호스트가 프레임을 원하는 만큼 계속 전송할 수 있다.

오류 제어 측면

데이터 전송 과정에서 프레임 분실이나 변형과 같은 어떠한 형태의 오류도 발생할 가능성이 없다. 따라서 송신 호스트는 수신 호스트로부터 전송 프레임에 대한 응답을 받지 않아도 되므로, 단순히 정보 프레임을 전송하는 것만으로 송신 호스트의 역할은 완료된다.

흐름 제어 측면

수신 호스트의 버퍼 크기가 무한하므로 버퍼 용량 부족에 따른 프레임 분실 오류를 걱정할 필요가 없다. 따라서 송수신 호스트 사이의 흐름 제어 기능이 필요 없어 상위 계층이 요청한 데이터를 수신 호스트에 송신하는 과정만 필요하다.


3. 오류 제어가 없는 프로토콜

  • 가정 : 수신 호스트의 버퍼 개수가 유한(버퍼 개수 제한)
    - 단방향 통신 : 데이터는 송신 호스트에서 수신 호스트로만(한쪽 방향으로만) 전달
    - 전송 오류 없는 물리 매체 : 통신 채널에서는 전송 오류가 발생하지 않음

수신 호스트의 버퍼가 유한 개로 제한되는 환경에서 송신 호스트가 너무 빨리 정보 프레임을 전송하면 버퍼 부족으로 프레임 분실 오류가 발생할 수 있다. 이를 방지하려면 프로토콜을 설계하는 과정에서 흐름 제어 기능을 제공하여 송신 호스트의 전송 속도를 조절해야 한다.

흐름 제어 측면

수신 호스트가 이전 프레임의 수신을 완료한 후에 다음 프레임을 전송하도록 송신 호스트에 지시하는 것이다. 이때 사용하는 프레임이 ACK 프레임이아. 결과적으로 ACK 프레임은 송신 호스트에 이전 프레임을 잘 받았다는 긍정 응답의 기능을 수행하는 동시에, 다음 프레임을 전송하도록 지시하는 흐름 제어 기능도 수행한다.

  • 정지-대기 프로토콜 1
    - 수신 호스트 버퍼 개수가 제한일 경우 흐름 제어 기능으로 송신 호스트의 전송 속도를 조절함
    - ACK 프레임 : 송신 호스트에 긍정 응답의 기능을 수행, 다음 프레임을 전송하도록 지시하는 흐름 제어 기능도 수행
    - 정지-대기Stop-and-Wait 방식 : 수신 호스트가 회신하는 ACK 프레임이 도착해야 다음 프레임을 전송할 수 있는 프로토콜 방식

4. 단방향 프로토콜

  • 가정 : 오류 제어와 흐름 제어 기능 지원
    - 단방향 통신 : 데이터는 송신 호스트에서 수신 호스트로만(한쪽 방향으로만) 전달

프레임 분실은 전송된 프레임이 수신 호스트에 도달하지 못하고 전송 도중에 사라지는 경우이다. 이때 수신 호스트는 정보 프레임이 도착하질 무한정 기다린다. 결과적으로 수신 호스트가 ACK 프레임을 회신할 수 없으므로 송신 호스트도 ACK 프레임의 도착을 무한정으로 기다린다.
이런 현상을 예방하려면 송신 호스트의 타임아웃 기능이 반드시 필요하다. 즉, 정보 프레임을 전송한 후에 특정 시간이 지날 때까지 수신 호스트의 ACK/NAK 프레임을 회신받지 못하면 송신 호스트는 프레임 분실이 발생한 것으로 간주한다. 프레임 분실 오류가 발생하면 송신 호스트의 타임아웃 기능이 동작하여 분실된 프레임을 재전송하는 방식으로 복구한다.

4.1 NAK가 없는 경우

송신 호스트가 정보 프레임을 전송한 후에 반드시 해당 프레임의 전송 시간을 고려한 제한 시간을 설정하여 타이머를 작동시켜야 한다. 송신 호스트는 정보 프레임 I(i)를 전송하면서 바로 타이머를 구동시키고, 임의의 시간까지 ACK 프레임이 도착되지 않으면 시간 초과에 따른 타이머 동작으로 정보 프레임 I(i)를 재전송한다.

NAK 프레임이 정의되지 않아 수신 호스트가 프레임 변형 오류에 응답할 방법이 없다. 따라서 송신 호스트의 타임아웃 기능에 의해 오류 복구 기능이 진행되어야 한다.

4.2 NAK가 있는 경우

(1) 변형된 프레임을 무시하는 것

분실 처리에 따른 타임아웃 기능을 거친다.

(2) NAK 프레임을 이용해 프레임 변형 사실을 송신 호스트에 통보

프레임 변형 오류와 프레임 분실 오류를 명확히 구분해 처리한다. 직관적으로 보면 NAK 프레임을 이용해 송신 호스트에 재전송을 요구하는 방식이 송신 호스트의 타이머 기능을 이용하는 것보다 효과적일 수 있다. 그러나 실제 네트워크 프로토콜에서는 정보 프레임에서 변형된 부분이 순서 번호처럼 중요한 정보일 수도 있고, 다른 네트워크 환경 요소에 의해 NAK 프레임을 이용하지 못할 수도 있다.

결론적으로 두 가지 원인리 발생했을 때 송신 호스트의 재전송 기능으로 오류 복구가 이루어진다. 하나는 정보 프레임에 대한 수신 호스트의 응답이 없을 때 송신 호스트의 타임아웃 기능에 의해 복구가 이루어지는 경우이고, 다른 하나는 수신 호스트가 회신한 부정 응답 프레임에 의해 복구가 이루어지는 경우이다.


02. 슬라이딩 윈도우 프로토콜

  • 양방향 통신을 지원
  • 오류 제어와 흐름 제어 기능을 모두 지원

📌 기본 절차

  • 송신 호스트는 정보 프레임(전송 데이터, 순서 번호, 오류 검출 코드)을 순서 번호에 따라 순차적으로 전송함
  • 정보 프레임을 수신한 수신 호스트가 응답하는 순서 번호는 정상적으로 수신한 번호가 아닌 다음에 수신하기를 기대하는 번호를 회신하는 것이 일반적임
  • 송신 호스트가 관리하는 송신 윈도우는 전송은 되었지만 긍정 응답이 회신되지 않은 프레임을 보관함
  • 수신 호스트가 관리하는 수신 윈도우는 프로토콜의 방식에 따라 크기가 다름
    - 선택적 재전송Selective Retransmission 방식에서는 송신 윈도우 크기와 같음
    - 고백 NGo-Back-N 방식에서는 크기가 1 임

1. 흐름 제어

1.1 순서 번호

정보 프레임의 내용에는 프레임별로 고유하게 부여되는 순서 번호라는 일련번호가 부여된다. 이 번호는 0부터 임의의 최댓값까지 정의되는데, 최댓값 이후에는 다시 0번으로 되돌아오는 순환 방식으로 할당된다. 따라서 프로토콜을 설계할 때는 현재 처리되고 있는 서로 다른 프레임에 같은 순서 번호를 부여하지 않도록 주의해야 한다. 이런 원칙에 위배되지 않으려면 기본적으로 순서 번호의 최댓값이 송신 윈도우의 크기보다 더 커야 한다.
정보 프레임의 내용에는 순서 번호를 위한 공간이 확보되어 있는데, 할당된 공간의 크기가 n비트라고 가정하면 프로토콜에서 사용할 수 있는 순서 번호의 범위는 0~2^n-1이다. 정지-대기 방식의 프로토콜은 슬라이딩 윈도우 프로토콜에서 가장 지본이 되는 n 값이 1인 경우이다.

1.2 윈도우 크기

슬라이딩 윈도우 프로토콜은 원리상 흐름 제어를 지원하기 위해 제공하는 기능이다. 기본 원리는 임의의 시점에서 송신 호스트가 수신 호스트로부터 긍정 응답 프레임을 받지 않고도 전송할 수 있는 정보 프레임의 최대 개수, 즉 윈도우 크기를 규정하기 위함이다. 송신 호스트가 관리하는 송신 윈도우에 보관된 프레임은 수신 호스트에 전송되었으나 아직 긍정 응답 프레임을 받지 못한 프레임이다.
윈도우에 포함되는 정보 프레임의 관리는 순서 번호를 기반으로 이루어지는데, 이들 순서 번호의 묶음이 결과적으로 윈도우가 된다. 송신 윈도우에 보관된 프레임은 낮은 순서 번호부터 차례로 처리된다. 즉, 긍정 응답 프레임이 회신되고 오류 없이 수신 호스트에 전달되었음을 확인함에 따라 윈도우에 새로 추가될 정보 프레임의 순서 번호도 순차적으로 높은 번호로 이동한다.



2. 연속형 전송

송신 호스트와 수신 호스트 사이의 물리적 거리 차로 인해 프레임의 전송 시간이 상대적으로 오래 걸리는 환경에서 윈도우 크기가 1이면 전송 효율은 극단적으로 떨어진다. 이를 해결하려면 윈도우 크기를 늘려 ACK 프레임을 받지 않고도 여러 정보 프레임을 연속으로 전송할 수 있어야 하는데, 이러한 방식을 연속형 전송이라 한다.
전송된 정보 프레임에 대한 ACK 프레임의 회신이 이루어지지 않은 상태에서 다음 프레임을 전송하는 방식은 전송 오류가 발생할 가능성이 적은 환경에서는 상당히 효율적이다. 하지만 전송된 여러 정보 프레임의 일부에 오류가 발생하면 이를 해결하는 방법론에 따라서 전송 효율에 영향을 받는다. 연속형 전송 방식의 오류를 해결하는 방법에는 고백 N 방식과 선택적 재전송 방식이 있다.

2.1 고백 N 방식

  • 송신측은 연속한 여러 개의 데이터 프레임을 송신
  • 수신측이 받은 FRAME 3에서 오류가 검출되어 NAK 3 신호를 전송하면,
  • 송신측은 이를 받아 FRAME 3부터 이후의 모든 프레임(FRAME 4, 5)을 재전송
  • 수신측은 FRAME 4와 FRAME 5는 성공적으로 받았음에도 불구하고 먼저 받은 것은 무시
  • FRAME 8이 중간에 손실된 경우, 수신측은 이에 대한 재전송을 요청하는 NAK 8 신호를 전송하며, 이를 받은 송신측은 FRAME 8부터 이후의 모든 프레임을 재전송
  • 단점
    - 오류가 난 데이터 프레임부터 이후의 모든 프레임을 재전송하므로, 성공적으로 전송된 프레임까지도 재전송하는 비효율성이 있음.

2.2 선택적 재전송 방식


  • Go-Back-N ARQ의 단점을 개선
  • NAK 신호를 받은 데이터 프레임만을 선택적으로 재전송
  • FRAME 3에 오류가 발생한 경우 수신측은 NAK 3 신호를 보내고 이를 받은 송신측은 오류가 발생한 FRAME 3에 대해서만 재전송을 함.
    - 수신측에서는 프레임들을 순서가 바뀐 상태로 받게 되며, 이러한 경우에 수신측은 프레임들의 순서를 재조립해야 함.
  • 단점
    - 수신측에서 수신된 데이터 프레임들을 모아 원래의 순서대로 재조립해야 하므로 더 복잡한 논리회로와 더 큰 버퍼를 필요로 함.

3. 피기배킹



profile
늦더라도 한 발짝씩 나아가는 컴공생

0개의 댓글