데이터 링크 계층

삼식이·2022년 10월 22일

네트워크 통신

컴퓨터 통신

목록 보기

9/11

본 자료 정리는 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크(개정판)' 원서에 출처합니다.
Copyright © 한빛 아카데미.

학습 목표

오류 제어, 흐름 제어의 원리와 동작 방식을 이해
통신 프로토콜에서 윈도우의 개념과 동작 방식을 이해
양방향 통신을 지원하는 슬라이딩 윈도우 프로토콜 이해
HDLC 프로토콜을 통해 프로토콜을 구현하는 원리 이해

내용

데이터 링크 계층의 프로토콜의 기초
슬라이딩 윈도우 프로토콜
HDLC 프로토콜

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

데이터 링크 계층에서 두 호스트가 통신하려면 일대일(1:1) 형식의 점대점 방식으로 연결해야함
점대점 연결 (Point-to-Point): 주소 개념 불필요
멀티드롭 연결 (Multi-Drop): 주소 개념 필요, 매체를 공유함으로 고유 주소가 필요
물리 계층에서 오류 발생 시 이를 극복하는 것은 데이터 링크 계층의 기본 역할, 오류 제어 방식으로 재전송(Retransimission) 기법을 사용

프레임의 종류: 아래 3가지 프레임을 사용하여 데이터링크 계층의 전송 프로토콜을 작성할 수 있음

정보 프레임 (Information Frame: I 프레임)
- 상위 계층이 전송을 요구한 데이터를 수신 호스트에 전송하는 용도로 사용
- 순서 번호(Sequence Number: 정보 프레임의 고유번호), 송수신 호스트 주소정보 등이 포함됨
긍정 응답 프레임 (Positive Acknowledgement Frame: ACK 프레임)
- 전송 데이터가 올바르게 도착했음을 회신하는 용도
- 데이터를 수신한 호스트가 데이터를 송신한 호스트에게 전송
부정 응답 프레임 (Negative Acknowledgement Frame: NAK 프레임)
- 전송 과정에서 프레임 변형 오류가 발생했음을 회신하는 용도
- 원래의 정보 프레임을 재전송하도록 요청
- 송신 호스트는 오류가 발생한 프레임을 동일한 순서 번호로 다시 전송

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

가정: 가장 이상적인 통신 환경
- 단방향 통신: 데이터는 송신 호스트에서 수신 호스트로만 (한쪽 방향으로만) 전달
- 전송 오류 없는 물리 매체: 통신 채널에서는 전송 오류가 발생하지 않음
- 무한 개의 수신 버퍼: 수신 호스트의 버퍼 수는 무한함
단순 프로토콜
- 송신 호스트는 원하는 만큼 자유롭게 프레임을 전송할 수 있음
- 오류 제어: 프레임 분실/ 변형 오류가 발생하지 않음
- 흐름 제어: 수신 버퍼가 무한이므로 분실 오류 없음

오류 제어가 없는 프로토콜

가정: 수신 호스트이 버퍼 개수가 유한 (버퍼 개수 제한 -> 흐름제어 필요)
- 단방향 통신: 데이터는 송신 호스트에서 수신 호스트로만 (한쪽 방향으로만) 전달
- 전송 오류 없는 물리 매체: 통신 채널에서는 전송 오류가 발생하지 않음
정지-대기 프로토콜 1
- 수신 호스트 버퍼 개수가 제한일 경우 흐름 제어 기능으로 송신 호스트의 전송 속도를 조절함
- ACK 프레임: 송신 호스트에 긍정 응답의 기능을 수행, 다음 프레임을 전송하도록 지시하는 흐름 제어 기능도 수행
- 정지-대기 (Stop-and-Wait) 방식: 수신 호스트가 회신하는 ACK 프레임이 도착해야 다음 프레임을 전송할 수 있는 프로토콜 방식
  
  -> 전송 효율이 매우 떨어지므로 일반 네트워크에서는 사용하지 않음

단방향 프로토콜

가정: 오류 제어와 흐름 제어 기능 지원
- 단방향 통신: 데이터는 송신 호스트에서 수신 호스트로만 (한쪽 방향으로만) 전달
오류 제어와 흐름 제어가 모두 필요
- 프레임 변형 오류를 해결하기 위한 수신 호스트의 NAK 기능 필요
- 프레임 분실 오류를 해결하기 위한 송신 호스트의 타임아웃 기능 필요

NAK가 없는 경우

정보 프레임 분실: 송신 호스트의 타임아웃 기능으로 오류 복구
원래는 송신 호스트가 ACK 프레임을 수신해야 다음 정보 프레임을 전송하는 프로토콜로 설계됨

ACK 프레임 분실: 수신 호스트가 제대로 수신하였으나 수신 호스트가 전송한 ACK 프레임이 분실된 경우, 송신 호스트의 타임아웃 기능으로 오류 복구, 동일한 정보 프레임을 재전송함

프레임 변형 오류: 송신 호스트이 타임아웃 기능으로 오류 복구

NAK가 있는 경우

프레임 변형 오류: 수신 호스트의 NAK 프레임 응답으로 오류 복구

프레임 분실 오류: 송신 호스트이 타임아웃 기능으로 오류 복구

슬라이딩 윈도우 프로토콜

양방향 통신을 지원
오류 제어와 흐름 제어 기능을 모두 지원
기본절차
1. 송신 호스트는 정보 프레임(전송 데이터, 순서 번호, 오류 검출 코드 등을 포함)을 순서 번호에 따라 순차적으로 전송함
2. 정보 프레임을 수신한 수신 호스트가 응답 프레임을 회신함. 이때 응답하는 순서 번호는 정상적으로 수신한 번호가 아닌 다음에 수신하기를 기대한 번호를 회신하는 것이 일반적임
3. 송신 호스트는 송신한 정보 프레임을 자신의 내부 버퍼에 유지 -> 송신 윈도우라 함
  송신 호스트가 관리하는 송신 윈도우는 전송은 되었지만 긍정 응답이 회신되지 않은 프레임을 보관함
4. 수신 호스트과 관리하는 수신 윈도우는 프로토콜의 방식에 따라 크기가 다름
  
  -선택적 재전송 방식에서는 송신 윈도우 크기와 같음
  -고백 N(Go-Back-N) 방식에서는 크기가 1임 -> 바로 다음 프레임만을 기다림

흐름 제어

수신 호스트가 연속적으로 수신할 수 있는 정보 프레임의 개수: 윈도우의 크기로 지정 -> 송신 호스트의 전송 속도를 제어

순서 번호
- 프레임 별로 부여되는 일련 번호
- 0부터 임의의 최대값까지 순환 방식으로 사용
- 일반적으로 순서 번호의 최대값이 송신 윈도우 크기보다 커야 함
- 프레임에서 순서 번호 공간 크기 = n 비트: 순서 번호의 범위는 0~2n(2의 n승)-1
- 정지-대기 방식의 프로토콜의 경우, n=1
윈도우 크기
- 슬라이딩 윈도우 프로토콜의 원리는 임의의 시점에서 수신 호스트로부터 긍정 응답 프레임을 받지 않고 전송할 수 있는 정보 프레임의 최대 개수, 즉 윈도우의 크기를 규정하기 위함
슬라이딩 윈도우 프로토콜의 동작 과정 1 (송신 윈도우 크기=3)

a) 0,1,2,번 정보를 전송 후 ACK 프레임을 못받은 경우

b) 수신 호스트로부터 0번에 대한 ACK를 받으면 송신 윈도우에는 1, 2번만 존재

c) 이때 3번이 전송가능

d) 1번에 대한 ACK를 받음

e) 4번 프레임이 전송 가능

f) 2번과 3번이 ACK 프레임이 도착한 직후

제대로 수신됐는지 확인되기 전까진 송신 버퍼가 바뀌지 않는다.
(재전송해야될 수도 있기 때문)

슬라이딩 윈도우 프로토콜의 동작 과정 2 (송신 윈도우 크기=3)

연속형 전송

정지-대기 프로토콜은 송신 윈도우 크기가 1인 특수한 경우
송수신 호스트 간 거리가 먼 경우 즉, 전송 시간이 오래 걸리는 경우 윈도우 크기가 1이면 효율성이 극단적으로 떨어짐
-> 이에 대한 해결방안이 연속형 전송 (ACK를 받지 않고, 연속적으로 전송하는 방식)
연속형 전송(Pipelining)전송: ACK 프레임을 받지 않고 여러 프레임을 연속 전송
장점: 오류 가능성이 적은 환경에서 효율적임
오류 해결 방법
- 선택적 재전송: 오류가 발생한 프레임만 재전송
- 고백 N: 오류가 발생한 프레임 이후의 모든 프레임을 재전송

고백 N 방식
- 오류가 발생한 12번 프레임을 포함해 이후에 전송된 모든 정보 프레임을 재전송
- NAK(12)를 받는 경우, 12번 이후의 프레임을 재전송
- NAK이 없고, ACK만 사용하는 경우는 타임아웃에 의해 12번 이후를 재전송함

선택적 재전송 방식: 오류가 발생한 프레임만 선택적으로 복구하는 방식
- 부정 응답 프레임을 사용해 오류가 발생한 정보 프레임을 처리하는 경우
- NAK(12)프레임을 전송한 이후에는 I(12)를 처리 완료할 때까지 다음 정보 프레임에 대한 긍정 응답 프레임을 전송하지 않도록 주의
- 오류없이 수신된 정보 프레임을 수신 윈도우에 보관해야 하기 때문에 수신 윈도우의 크기가 송신 윈도우의 크기와 동일, 도착 순서가 송신 순서와 일치하지 않음
피키배킹(Piggybacking)
- 양방향 전송기능을 갖춘 채널방식: 양방향 교차 전송 가능(정보+응답)
- 정보 프레임을 전송하면서 응답 프레임까지 함께 수행, 전송 효율 높임
```
- 피기배킹을 사용하지 않는 경우
(개별 정보 프레임에 대해 긍정 응답 혹은 부정 응답 프레임이 순서 번호와 함께 별도 처리)
```
피기배킹을 사용하는 경우
- 정보 프레임의 표기 방식은 I(i,j)로 재정의
- i는 자신이 전송하는 데이터의 순서 번호, j는 제대로 수신한 프레임의 순서 번호를 의미

HDLC 프로토콜

HDLC와 부리가 같은 프로토콜들:
IBM의 SDLC, CCITT의 LAP와 LAPB
HDLC (High-Level Data Link Control) 프로토콜
- 일대일 혹은 일대다로 연결된 환경에서 데이터의 송수신 기능 제공
호스트 종류
- 주국(Primary Station)과 종국(Secondary Station)으로 구분됨
  (*주국-데이터를 주는 쪽, 종국-데이터를 받는 쪽)
- 혼합국(Combined Station): 주국과 종국 기능을 모두 지닌 호스트
  (서로 주고 받음, 두 호스트가 동등)
- 주국에서 전송되는 메세지를 명령이라 정의
- 종국의 회신을 응답이라 함

프레임 구조

HDLC 프레임 구조
- 상단의 숫자는 비트 수
- 프레임의 좌우에 위치한 01111110 플래그는 프레임의 시작과 끝을 구분
- Address(주소): 일대다 환경에서 특정 호스트를 구분, 지칭하는 목적으로 사용
- Control(제어): 프레임의 종류를 구분
- Data(데이터): 가변 크기의 전송 데이터가 포함
- Checksum(체크섬): CR-CCITT를 생성 다항식으로 하는 오류 검출 용도로 사용

프레임 종류

정보 프레임 (Information Frame)
- 네트워크 계층의 데이터 전송을 위해 정의
- 3비트의 순서 번호를 이용한 슬라이딩 윈도우 프로토콜을 사용
- 순서 번호는 0~7의 순서 번호 8개를 순환하여 사용
- Seq: 정보 프레임의 송신용 순서 번호로 사용
- Next: 피기배킹을 이용한 응답 기능으로 사용
- P/F: 값이 1로 지정되어 잇을 경우에 한하여 Poll(주국 명령) 혹은 Final(종국 응답)의 의미를 가짐

감독 프레임 (Supervisor Frame)
- 정보 프레임에 대한 응답 기능을 수행하는 프레임
- 긍정 응답 프레임과 부정 응답 프레임으로 구분
- Type 0: RR로 정의된 긍정 응답 프레임
- Type 1: REJ로 정의된 부정 응답 프레임
- Type 2: RNR로 정의된 긍정 응답 프레임과 흐름 제어 기능까지 제공
- Type 3: SREJ로 정의된 프레임, 선택적 재전송 방식에서 부정 응답 기능을 지원

비번호 프레임 (Unnumbered Frame): 순서 번호가 없는 프레임을 정의
- 프레임 종류
  - SABM(Set ABM): 비동기 균형 모드의 연결 설정을 요구
  - SNRM(Set NRM): 정규 응답 모드의 연결 설정을 요구
  - SARM(Set ARM): 비동기 응답 모드의 연결 설정을 요구
  - DISC(DISConnect): 연결 설정 해제를 요구
  - RSET(ReSET): 비정상적인 프로토콜의 동작에 따른 리셋 기능을 수행
  - FRMR(FRaMe Reject): 비정상적인 프레임의 수신을 거부
  - UA(Unnumbered ACK): 비번호 프레임에 대한 응답 기능을 수행

LAP 프로토콜

LAP(Link Access Protocol): 비동기 응답 모드인 ARM으로 동작하는 프로토콜
- 주국에서 전송된 SARM 명령에 대하여 종국에서 UA 응답을 전송함으로써 완료
- 종국에서 주국으로 SARM 응답을 전송하며 연결 설정을 요구
- 종국에서 시작된 연결 설정은 3단계로 이루어지는 효과가 발생