[DCN] Ep 8. Data Link Control(DLC)

Data Communications and Networking, 5th Edition By Behrouz .A Forouzan, McGraw-Hill Education

데이터 링크 레이어는 2가지 부계층으로 나뉜다. 이 챕터에서는, 데이터-링크 계층의 상위 부계층(DLC)에 대해서 설명한다. 하위 부계층인 다중 접속 제어(MAC)는 12장에서 설명한다.
이번 챕터는 4가지 섹션으로 나뉜다.

• 첫 번째 섹션에서는 DLC 계층에 의해 제공되는 일반적인 서비스를 설명한다.
  먼저 해당 계층에서 사용되는 프레이밍(Framing)과 프레이밍의 2가지 유형에 대해서 설명한다.
  이후, 흐름(Flow)과 에러 제어(Error control)에 대해서 설명한다.
  마지막으로 DLC 프로토콜이 비연결적(Connectionless)인지 연결 지향적(Connection-oriented)인지에 대해서 설명한다.

• 두 번째 섹션에서는 몇 가지 단순하고 흔한 데이터-링크 프로토콜을 설명한다.
  해당 섹션은 Simple Protocol을 설명한 이후, Stop-and-Wait Protocol을 설명한다.

• 세번째 섹션에서는 PPP와 이더넷과 같은 모든 데이터-링크 프로토콜의 기반(Basis of)이 되는 프로토콜인 HDLC에 대해서 설명한다. 먼저, 구성 및 전송(Configurations and Transfer) 모드에 대해서 설명하고, 해당 프로토콜에서 사용되는 프레이밍과 3가지 다른 프레임 포맷을 설명한다.

• 네 번째 섹션에서는 점-대-점 연결에서 매우 흔하게 사용되는, PPP 프로토콜에 대해서 설명한다. 먼저, 해당 프로토콜이 제공하는 서비스를 소개하고 프레임의 포맷을 설명한다. 이후, FSM을 사용하여 프로토콜에서의 Transition mode를 설명한다. 마지막으로, PPP에서 다중화(Multiplexing)를 설명한다.

11.1 DLC 서비스

데이터 링크 제어(DLC, Data Link Control)는 두 인접 노드들(Node-to-Node) 간의 통신의 절차(Procedures)를 다룬다. 링크가 전용(dedicated)또는 브로드캐스트(Broadcast)인지와는 상관없이. 이 섹션에서는 물리 계층에 의해 전송되어지는 비트들을 어떻게 구성하는지에 대한 프레이밍에 대해서 설명한다. 이후, 흐름과 에러 제어를 알아보자.

11.1.1 Framing

물리 계층에서의 데이터 전송은 신호 형태의 비트들이 송신지(Source)로부터 목적지(Destination)까지의 이동을 의미한다. 물리 계층은 송신자와 수신자가 같은 타이밍과 비트 시간을 사용하는 것을 보장하기 위해서 비트 동기화를 제공한다. (해당 내용은 Part2에서 알아본다.)

반면에, 데이터-링크 레이어에서는 비트들을 프레임으로 포장할 필요가 있다. 우리의 우편(postal) 시스템은 일종의 프레이밍을 수행한다.
봉투에 편지를 집어넣는 단순한 행위는 정보의 한 부분을 분리하는 것이다; 봉투는 구분자의 역할을 한다. 게다가 각각의 봉투는 송신자와 수신자의 주소를 구분한다. 이는 우편 시스템이 다-대-다(Many-to-Many) 운반 시설이기 때문에 필수적이다.

데이터-링크 계층의 프레이밍은 송신자와 수신자의 주소를 추가함으로써 송신지에서 목적지로 메시지를 구분한다. 목적지 주소는 패킷이 어디로 가는지를 결정한다; 송신지 주소는 수신자가 영수증을 확인 할 수 있도록 도와준다.

비록 모든 메시지를 하나의 프레임으로 감쌀 수 있지만, 일반적으론 그렇게 하지 않는다. 프레임은 매우 클 수 있기 때문에 플로우와 에러 제어를 매우 비효율적으로 만들기 때문이다. 메시지가 매우 큰 하나의 프레임으로 전달되면, 단지 하나의 비트 에러일지라도 전체 프레임을 다시 재전송 해야 한다. 메시지가 더 작은 프레임으로 분리된다면, 싱글-비트 에러는 해당 작은 프레임에만 영향을 미친다.

프레임 사이즈(Frame Size)

프레임들은 고정적이거나 다양한 크기가 될 수 있다. 고정-크기 프레이밍에서는 프레임의 경계선(Boundaries)를 결정할 필요가 없다; 그 크기 자체로 기준(Delimeter)으로써 사용된다.
cells라고 불리는 고정 크기의 프레임을 사용하는 ATM WAN이 그 예시이다. (14장에서 알아보자)

이번 챕터의 주요 관심사는 근거리 통신망에서 자주 사용되는 가변-길이 프레이밍이다. 가변-길이 프레이밍에서, 우리는 한 프레임의 끝과 다음 프레임의 시작 부분을 결정할 방법이 필요하다. 전통적으로, 2가지 방법들이 사용되어져 왔다: 문자 중심 방법(a character-oriented approach)과 비트 중심 방법(a bit-oriented approach).

문자 중심 프레이밍(Character-Oriented Framing)

문자 중심 프레이밍에서는, 전송되어지는 데이터는 ASCII와 같은 부호화 시스템의 8비트 문자이다.

일반적으로 송신지와 목적지의 주소와 다른 제어 정보를 담고 있는 헤더와 에러 탐지 비트를 담고 있는 트레일러 들은 복수개의 8비트들 이다. 다음 프레임으로부터 하나의 프레임을 구분하기 위해서, 8비트(1바이트) 플래그가 프레임의 시작과 끝 부분에 추가된다.

문자 중심 프레이밍은 오직 텍스트만 데이터-링크 레이어에 의해 교환되었을 때 인기 있다. 플래그는 텍스트 통신을 위해 사용되지 않는 어떠한 문자라도 선택될 수 있다. 하지만, 오늘날에는 그래프, 오디오, 비디오와 같은 다양한 정보의 유형을 보낸다. 플래그로 사용하는 패턴이 정보 자체에 들어 있을 수도 있다. 해당 상황이 발생한다면, 수신자는 데이터의 중간부분에서 이러한 패턴을 마주쳤을 때, 프레임의 끝에 도달했다고 생각하게 된다.
이러한 문제를 해결하기 위해서, byte-stuffing(문자 채우기 또는, 바이트 채우기) 전략이 문자 중심 프레이밍에 추가되었다.
바이트 스터핑(문자 스터핑)에서는, 플래그와 같은 패턴의 문자가 있다면, 특별한 바이트가 프레임의 데이터 섹션에 추가된다. 데이터 섹션은 추가 바이트로 채워진다. 이 바이트는 escape character (ESC)라고 불려지고 미리 정해진 비트 패턴을 가진다. 수신자가 ESC를 만나면, 데이터 섹션으로부터 그것을 제거하고 다음 문자를 구분 플래그가 아닌 데이터로 다룬다.

이스케이프 문자에 의한 바이트 스터핑은 프레임의 데이터 섹션에 플래그의 존재를 허락한다.
하지만, 이는 또 다른 문제를 야기한다.
텍스트가 하나 이상의 이스케이프 문자들을 포함하고 그 뒤에 플래그가 뒤따라온다면 어떻게 될까?
수신자는 이스케이프 문자를 제거하지만, 다음 바이트는 유지한다(플래그를 데이터로 오인한다). 이것은 프레임의 끝을 잘못 해석하게 한다.
이 문제를 해결하기 위해서, 이스케이프 문자는 또다른 이스케이프 문자에 의해서 표시되어져야만 한다. 다른 말로, 만약 이스케이프 문자가 텍스트의 일부라면, 이스케이프 문자를 하나 더 추가하여 두 번째는 텍스트의 일부라는 것을 보여주기 위해서 추가되어 진다.
문자 중심 프로토콜은 데이터 통신에서 또다른 문제가 존재한다. Unicode와 같은 오늘날 사용되는 부호화 시스템은 16비트와 32비트의 문자를 가지고 있다.
따라서, 다음에 얘기할 비트-중심 프로토콜로 변화하는 추세이다.

비트-중심 프레이밍(Bit-Oriented Framing)

비트 중심 프레임짜기(Bit-Oriented Framing)에서는 프레임의 데이터 부분은 상위 계층에서 문자열, 그래픽, 오디오, 화상 등의 데이터 중 하나로 인식되게 되는 단지 비트열일 뿐이다. 그러나 헤더(그리고 트레일러) 이외에도 프레임을 구분할 경계가 필요하다. 대부분 프로토콜은 01111110의 8비트 패턴의 플래그를 그림 11.3과 같이 프레임의 경계로 삼고 있다.

이 플래그는 앞에서 본 것과 동일한 문제를 일으킬 수 있다. 즉, 플래그 패턴이 데이터 속에 나타난다면 수신자에게 그것이 프레임의 끝이 아니라는 것을 알릴 필요가 있는 것이다. 이 경우에 1개의 단일 비트(1바이트 대신에)를 채워 넣어서 그 패턴이 플래그처럼 보이지 않도록 만든다. 이 전략을 비트 채우기(Bit stuffing)이라고 한다. 비트 채우기에서는 0과 그 뒤로 연속하는 5개의 1을 만나게 되면 추가로 0을 더해 넣는다. 이 추가로 채워진 비트는 궁극에는 수신자가 데이터에서 제거한다. 여기에서 0뒤에 5개의 1이 연속되면 그 뒤의 비트 값에 무관하게 0비트를 채운다는 것에 유의하라. 이렇게 하면 플래그 패턴은 데이터 속에서는 나타나지 않는다는 것을 보장한다.

비트 채우기는 0 뒤에 연속하는 5개의 1이 있게 되면 0을 추가로 채우는 과정이며, 따라서 수신자는 데이터 속의 01111110을 플래그로 오인하지 않도록 하는 것이다.

연속적인 5개의 1 뒤에 0이 오는 경우에도 무조건 0을 채운다는 것에 유의하라.
이 0은 수신자가 제거한다.

이는 플래그 같은 패턴 01111110이 데이터 속에 나타나면 011111010으로 바뀌는 것을 말하며, 따라서 수신자에 의해 플래그로 오인하지 않는다는 것을 말한다. 진짜 플래그 01111110은 송신자에 의해 비트가 채워지지 않으며 수신자는 플래그로 알아보게 된다.

11.1.2 흐름 제어와 오류 제어(Flow and Error Control)

흐름 제어 (Flow Control)

개체가 아이템을 생성하고 다른 개체가 그것을 소비할 때마다 생산과 소비 사이의 균형을 맞춰야 한다. 효율적인 시스템은 소비자 측에서 데이터 아이템의 손실을 예방할 필요가 있다. 흐름제어는 해당 문제와 관련 있다.

송신자와 수신자는 각 네트워크 및 데이터 링크층이라는 4가지 개체에 대해 다룬다. 하나 이상의 생산자 및 소비자와 복잡한 관계를 가질 수 있지만, 네트워크 및 데이터 링크층 사이의 관계를 무시하고 그림 11.5와 같이 두 데이터 링크층 사이에 집중한다.

그림은 송신 노드에서 데이터 링크층이 수신 노드의 데이터 링크층으로 프레임을 보내는 것을 보여준다. 수신 노드가 도착한 프레임과 같은 비율로 패킷을 처리하고 전달하지 못하면, 프레임이 넘쳐나게 된다. 이 경우에서 흐름 제어는 프레임을 보내는 것을 멈추거나 느리게 하도록 수신 노드에서 송신 노드로 피드백할 수 있다.

실제로 흐름 제어는 상대방으로부터 확인응답을 받기 전에 얼마나 많은 데이터를 보낼 수 있는지를 조정하는 것으로서 데이터 링크층의 가장 중요한 임무 중 하나이다. 대부분 프로토콜에서는 흐름 제어는 수신자로부터 확인응답을 받기 전까지 얼마나 많은 데이터를 전송할 수 있는지를 알려주는 일련의 절차이다. 한꺼번에 데이터를 너무 많이 보내서 수신자가 혼란스럽게 해서는 안 된다. 모든 수신장치는 입력되는 데이터를 처리할 수 있는 속도에 한계가 있으며, 입력되는 데이터를 저장하는 메모리에 한계가 있다. 수신자는 이러한 한계에 도달하기 전에 송신자에게 이것을 알리 수 있어야 하며 송신하는 장치가 프레임을 천천히 보내거나 잠시 전송하는 것을 멈추도록 할 수 있어야 한다.

버퍼(Buffer)

흐름 제어는 여러 가지 방법으로 구현할 수 있지만, 그 방법 중 하나는 보통 2개의 버퍼(Buffer)를 두어 하나는 송신 데이터 링크층에서, 다른 하나는 수신 데이터 링크층에서 사용하는 것이다. 버퍼는 송신자 및 수신자에서 패킷을 저장할 수 있는 메모리의 집합이다. 흐름 제어 통신은 소비자에서 생산자로 신호를 보내면 발생한다. 수신 데이터 링크층의 버퍼가 가득 차게 되면, 송신 데이터 링크층이 프레임 전송을 멈추도록 알릴 수 있어야 한다.

오류 제어 (Error Control)

물리층에서 기반 기술을 완전히 신뢰할 수 없어서, 네트워크층에서 손상된 패킷을 수신 노드로 전달하는 것을 방지하기 위해 데이터 링크층에서 오류 제어를 구현해야 한다. 데이터 링크층에서 오류 제어란 기본적으로 오류를 검출하여 재전송하는 것을 말한다. 데이터 링크층에서 오류 제어는 보통 단순하게 구현된다. 오류가 확인된 순간 해당 프레임을 재전송하는 것이다. 이 과정을 자동 반복 요구(ARQ, Automatic Repeat Request)라고 한다.

흐름 제어와 오류 제어의 조합 (Combination of Flow and Error Control)

흐름 제어와 오류 제어는 동시에 사용할 수 있다. 간단한 상황에서 흐름 제어를 위해 보내지는 확인 응답(Acknowledgement)은 손상되지 않은 패킷이 잘 도착했다고 송신자에게 알리기 위한 오류 제어에도 사용할 수 있다. 확인 응답이 없다는 것은 전송 프레임에 문제가 있다는 것을 의미한다. 다음 절에서 몇 가지 간단한 프로토콜을 논의하면서 이러한 상황을 보여줄 것이다. 확인 응답을 전달하는 프레임은 데이터 프레임과 구별하기 위해 일반적으로 ACK라고 부른다.

11.1.3 비연결형과 연결형(Connectionless and Connection-oriented)

비연결형(Connectionless)

비연결형 프로토콜에서 프레임은 프레임들 사이에 어떠한 관계도 없이(각 프레임은 독립적이다.) 하나의 노드에서 다음 노드로 보내진다. 비연결형이라는 말이 노드들 사이에 물리적인 연결(전송매체)이 없다는 것을 의미하지 않는다는 것에 유의하라. 이것은 프레임들 사이에 연결이 없다는 것을 의미한다. 프레임은 번호가 매겨지지 않으며 순서도 없다. LAN을 위한 대부분의 데이터 링크 프로토콜들은 비연결형 프로토콜이다.

연결형(Connection-oriented)

연결형 프로토콜에서 먼저 두 노드 사이에 논리적인 연결이 설정되어야 한다(연결 설정 단계).
서로 관련이 있는 모든 프레임이 전송된 후에(전송 단계), 논리적인 연결은 종료 된다(연결 해제 단계). 이 통신의 유형에서, 프레임은 번호가 매겨지고 순서대로 보내진다. 그들이 순서대로 수신되지 않는 경우, 수신자는 동일한 집합에 속하는 모든 프레임이 수신된 후 네트워크층에 순서대로 제공될 때까지 기다려야 한다. 유선 LAN에서 연결형 프로토콜은 드물다. 하지만 몇 가지 점-대-점 프로토콜, 무선 LAN 및 WAN에서 볼 수 있다.

11.2 데이터 링크층 프로토콜 (Data-Link Layer Protocols)

전통적으로 4개의 프로토콜이 흐름 제어와 오류 제어를 다루기 위해 데이터-링크 층을 위해 정의되었다. (Simple, Stop-and-Wait, Go-Back-N, and Selective-Repeat) 비록 처음 2개의 프로토콜은 데이터 링크 계층에서 여전히 사용되지만, 뒤 2개의 프로토콜은 그렇지 않다.
따라서 앞 2개의 프로토콜에 대해서 설명하고 나머지 2개는 23장에서 설명한다.

데이터-링크 계층 프로토콜이 하는 일은 FSM(Finite State Machine)으로 잘 나타낼 수 있다. FSM은 유한개의 상태로 나타내는 기계로 생각하면 된다.
기계는 이벤트가 발생할 때까지 항상 하나의 상태를 가진다. 각각의 이벤트는 2개의 반응으로 연관되어진다(실행 될 행동들의 리스트를 결정하는 것과 다음 상태를 결정하는 것). 상태들 중 하나는 반드시 초기 상태로써 설정되어야 한다. 그림 11.6은 FSM을 사용하는 기계의 예시를 보여준다.

둥근 모서리의 박스 : 상태
색상이 있는 문자 : 이벤트
검정색 문자 : 행동
수평선 : 행동으로부터 이벤트를 분리하기 위해 사용

해당 그림은 3개의 상태를 가지는 기계이다. 오직 3개의 가능한 이벤트와 행동들이 있다. 기계는 State 1에서 시작되고 event 1이 발생한다면, 기계는 action 1과 2를 수행하고 State 2로 변경된다.

11.2.1 단순 프로토콜(Simple Protocol)

우리의 첫 번째 프로토콜은 단순 프로토콜(Simple protocol)이다. 흐름 제어나 오류 제어를 하지 않는 프로토콜이다. 수신자는 즉시 패킷을 수신한다. 즉, 수신자는 유입되는 프레임으로 인해 절대로 넘쳐나지 않는다. 그림 11.7은 해당 프로토콜을 보여준다.

송신자의 데이터-링크 계층은 네트워크 계층으로부터 패킷을 받고 프레임을 보낸다. 수신자의 데이터-링크 계층은 링크로부터 프레임을 받고 네트워크 계층으로 패킷을 전달한다. 수신자와 송신자의 데이터-링크 계층은 그들의 네트워크 계층을 위한 전송(Transmission) 서비스를 제공한다.

FSMs

송신자 측은 네트워크 레이어가 보낼 메시지를 가질 때 까지 프레임을 전송하지 않는다. 수신자측은 프레임이 도착할 때까지 네트워크 계층에게 메시지를 전달하지 않는다. 우리는 이 요구사항들을 2개의 FSMs를 이용하여 나타낼 수 있다. 각각의 FSM은 오직 하나의 상태만을 가진다(ready state). 네트워크 계층에서의 절차고 부터 요청이 올 때까지 송신자 기계는 준비 상태에 남아있다.
이벤트가 발생하면, 송신자 기계는 메시지를 캡슐화하여 프레임으로 만들고 그것을 수신자에게 보낸다. 수신자는 그 반대이다(역캡슐화 진행).

해당 그림에서는 송신자와 수신자 노드에서 각각 캡슐화와 역캡슐화가 진행됨을 알 수 있다.

11.2.2 정지-후-대기 프로토콜(Stop-and-Wait Protocol)

정지-후-대기 프로토콜(Stop-and-Wait Protocol)은 흐름 제어와 오류 제어 모두를 사용한다. 지금은 가장 기본 버전을 설명하지만, 슬라이딩 윈도우(Sliding window)에 대해서 배운 후 23장에서 더 정교한 버전을 설명한다.
해당 프로토콜에서 송신자는 동시에 하나의 프레임을 전송하고 다음 것을 보내기 전에 ACK를 기다린다.
오염된(Corrupted) 프레임을 탐지하기 위해서 우리는 CRC를 각 데이터 프레임을 추가할 필요가 있다. 수신자 측에 프레임이 도착하면, 검사되어진다. CRC가 불일치 할 경우에, 프레임은 오염되어졌고, 조용하게 폐기되어진다. 수신측의 침묵은 프레임이 오염되어졌거나 유실되었다는 것을 나타내는 송신자에게 보내는 신호이다. 송신자가 프레임을 전송할 때마다, 타이머를 실행시킨다. 만약 타이머가 만료되기 전에 ACK가 도착한다면, 타이머가 종료되고 다음 프레임을 전송한다. 만약 타이머가 만료되었다면, 송신자는 해당 프레임이 유실되었거나 오염되었다고 생각하고 이전 프레임을 재전송한다. 이는 곧 송신자는 ACK를 받을 때 까지 해당 프레임의 복사본을 가지고 있어야 함을 의미한다. ACK가 전달되면, 복사본을 폐기하고 다음 프레임을 전송한다.

FSMs

송신자 측(Sender States)

송신자는 준비 단계에서 시작한다. 하지만, 준비와 블로킹 상태 사이를 움직일 수 있다.
- 준비 상태
송신자가 준비 상태에 있을 때는 오직 네트워크 계층으로부터의 패킷만을 기다린다. 패킷이 전달되면, 송신자는 프레임을 생성하고, 해당 프레임의 복사본을 저장하고, 타이머를 시작하고, 프레임을 전송한다. 송신자는 이후 블로킹 상태로 이동한다.
- 블로킹 상태
해당 상태에서는 3가지 이벤트가 발생 할 수 있다.
1. 타임-아웃이 발생한다면, 송신자는 해당 프레임의 복사본을 재전송하고 타이머를 재시작한다.
2. 오염된 ACK가 도착했다면, 처분한다.
3. 정상(Error-free) ACK가 도착했다면, 송신자는 타이머를 정지시키고 저장된 프레임의 복사본을 폐기한다. 이후 준비 상태로 돌아간다.

수신자 측(Receiver)

수신자는 항상 준비 상태이다. 2가지 이벤트가 발생 할 수 있다.
1. 정상(Error-free) 프레임이 도착했다면, 프레임의 메시지는 네트워크 계층으로 전달되고 ACK를 전송한다.
2. 오염된 프레임이 도착한다면, 프레임은 처분된다.

Example 11.3

그림 11.12는 예시를 보여준다.
첫 번째 프레임이 보내졌고 ACK도 수신되어졌다.
두 번째 프레임은 보내졌지만, 유실되었다.
세 번째 프레임은 보내졌고 ACK도 수신되었다. 하지만, ACK가 유실되었고 프레임이 재전송되었다.
위 상황에서 수신자측의 네트워크 계층은 중복된 패킷을 받고 있다. 해당 문제는 sequence numbers와 acknowledgement numbers로 해결한다.

Seq#과 ACK#

중복 패킷은 피해야할 필요가 있다. 우리는 해당 문제를 해결하기 위해서 sequence numbers를 데이터 프레임에 추가하고 acknowledgement numbers를 ACK 프레임에 추가할 필요가 있다.
하지만, 해당 경우에서의 숫자 메기기는 너무 쉽다.
Sequence numbers는 0,1,0,1,...; 이고
Acknowledgement numbers는 1,0,1,0,...;이다.
즉, sequence numbers는 0으로 시작하고 Acknowledgement numbers는 1로 시작한다. Acknowledgement number는 항상 다음에 받을 프레임의 sequence number를 의미한다.

해당 그림은 중복을 피하고자 Seq#과 ACK#이 추가된 버전이다.
ACK1이 유실되었기 때문에 송신자는 프레임0가 유실되거나 오염된 줄 알고 프레임0를 재전송하였다. 하지만, 수신자 측에서는 ACK1을 보낸 상태이기 때문에 프레임1을 받을 준비를 하고 있음을 알 수 있다. 따라서 재전송된 프레임0를 폐기하고 ACK1을 다시 보낸다.

11.2.3 피기배킹(Piggybacking)

이번 섹션에서 설명한 2개의 프로토콜은 단방향 통신이다. ACK나 NAK 같은 제어 프레임과는 달리 데이터는 한 방향으로만 전달된다.
프로토콜들은 양 방향으로 흐르도록 설계되어졌지만, 효율적인 통신을 위해서, 피기배킹이라는 기법이 사용되어졌다. 즉, 노드 A가 노드 B로 데이터를 전송 할 때, 노드 A 또한 노드 B로부터 받는 데이터에 대한 ACK를 보낸다. 피기배킹은 데이터-링크 계층에서의 통신을 더욱 복잡하게 만들기 때문에, 흔하게 사용되지는 않는다. 23장에서 양방향 통신과 피키배킹을 더 자세히 설명한다.

11.3 HDLC (High-level Data Link Control)

고급 데이터 링크 제어는 점-대-점과 다중점 링크에서 사용하는 비트 중심 프로토콜이다. 이전에 설명했던 정지 후 대기(Stop-and-Wait) 프로토콜을 구현한다. 이 프로토콜이 실용적이긴 보다는 이론적인 문제가 있지만, 해당 프로토콜에 정의된 대부분의 개념은 PPP나 이더넷과 같은 다른 실용적인 프로토콜의 기초이다.

11.3.1 구성 및 전송 모드 (Configurations and Transfer Modes)

HDLC는 서로 다른 구성을 가지는 2가지 흔한 전송 모드를 제공한다. 정규 응답 모드(NRM, normal respnose mode)과 비동기 균형 모드(ABM, Asynchronous Balanced Mode).

NRM에서는 지국(Station) 구성은 비균형적이다. 우리는 한 개의 주국과(Primary) 다수 개의 종국(Secondary Station)이 있다.
주국(Primary station)은 명령을 보낼 수 있는데, 종국(Secondary station)은 단지 그 명령에 응답 할 뿐이다.
그림 11.14에서 보듯이 NRM은 점-대-점 연결과 다중점 연결에서 사용된다.

ABM에서는 구성은 균형적이다. 링크는 점-대-점이며, 각 지국은 주국과 종국의 기능을 할 수 있다. 오늘날 사용되는 모드이다.

11.3.2 프레이밍(Framing)

통신 모드와 구성의 모든 가능한 선택사항을 지원하기 위한 융통성을 제공하기 위해서 HDLC는 3가지 유형의 프레임을 정의한다.
정보 프레임(I-frames, Information frames)
감시 프레임(S-frames, Supervisory frames)
비번호 프레임(U-frames, Unnumbered frames)
각 프레임 유형들은 다른 유형의 메시지 전송을 위한 봉투의 역할을 한다.

I-frames는 데이터-링크 유저 데이터와 유저 데이터(피기배킹)와 관련 있는 제어 정보들을 위해 사용된다.
S-frames는 오직 전송 제어 정보를 위해 사용된다.
U-frames는 시스템 관리를 위한 것으로, U-frames로 전송되는 정보는 링크 자체를 관리할 목적으로 쓰인다.

HDLC의 각 프레임은 그림 11.16과 같이 시작 플래그(Beginning flag), 주소 필드, 제어 필드, 정보 필드, 프레임 검사 순서 값(FCS, Frame Check Sequence) 필드, 종료 플래그(Ending flag)등 6개의 필드를 포함할 수 있다.
다중 프레임 전송에서 한 프레임의 종료 플래그는 다음 프레임의 시작 플래그를 겸할 수 있다.

• 플래그 필드

  이 플래그 필드는 프레임의 시작과 끝을 인식하고 동기화 패턴 01111110이 들어있다.

• 주소 필드

  이 필드는 종국의 주소를 가지고 있다. 만약 주국이 프레임을 만들었다면 이 프레임은 목적지 주소를 가지며, 종국이 프레임을 만들었다면 발신지 주소를 가지게 된다. 주소(address) 필드는 네트워크의 필요에 따라 1바이트 또는 몇 바이트의 길이를 가질 수 있다.

• 제어 필드

  제어(Control) 필드는 흐름과 오류 제어에 사용되는 1바이트 또는 2바이트이다. 비트의 설명은 다음에 논의 한다.

• 정보 필드

  정보(Informaion) 필드는 네트워크층의 사용자 데이터를 포함하거나 관리 정보를 포함한다. 이 필드의 길이는 네트워크마다 다를 수 있다.

• FCS 필드

  프레임 검사 순서 값(FCS, Frame Check Sequence)은 HDLC의 오류 검출(error detection) 필드이다. 이 필드는 2바이트나 4바이트 CRC를 포함한다.

제어 필드는 프레임의 유형과 기능을 규정한다. 그러므로 좀 더 자세히 이 필드를 살펴보자. 그 형식은 그림 11.17에서 보듯이 프레임의 유형에 따라 다르다.

I-frames에서 제어 필드 (Control Field for I-Frames)

I-frames는 네트워크 계층으로부터 유저 데이터를 전달하기 위해서 설계되었다. 게다가, 흐름 제어 및 오류 제어 정보(피기배킹)을 포함할 수 있다.
제어 필드의 부필드들은 이와 같은 기능들을 정의하기 위해 사용된다.

첫 번째 비트는 유형을 나타낸다. 제어 필드의 첫 번째 비트가 0이면 이는 프레임이 I-frames인 것을 의미한다.

그 다음 3개의 비트는 $N(S)$라고 불리는데 프레임의 순서 번호를 나타낸다. 3개의 비트로 0부터 7까지의 순서 번호를 정의할 수 있다는 것을 유의하라.

마지막 3비트는 $N(R)$이라 불리는데 피기배킹할 때 확인응답 번호에 해당한다.

$N(S)$와 $N(R)$사이의 단일 비트는 P/F 비트라 불린다.
P/F 필드는 두 가지 목적으로 쓰이는 단일 비트이다.
이 비트는 1로 설정되었을 때만 의미를 가지며 폴(Poll)또는 파이널(Final)을 의미할 수 있다.
이 비트는 프레임이 주국에서 종국으로 보낼 때(주소 필드가 수신기의 주소를 가지고 있을 때)에는 폴을 뜻하며, 프레임이 종국에서 주국으로 보낼 때(주소 필드가 송신기의 주소를 가지고 있을 때)에는 파이널을 의미한다.

S-frames에서 제어 필드 (Control Field for S-Frames)

피기배킹이 불가능하거나 부적절할 때 흐름 제어와 오류 제어를 위해 감시 프레임(S-frames, supervisory frames)이 사용된다.
S-frames에는 정보 필드가 없다. 제어 필드의 처음 2비트가 10이면 이 프레임은 S-frames이다.
$N(R)$로 불리는 마지막 3비트는 S-frames의 유형에 따라, ACK(Acknowledgement number)나 NAK(Negative Acknowledgement number)에 해당한다.
코드(Code)라고 불리는 2비트는 S-frames 자체의 유형을 정의하는 데 사용된다. 이 2비트로 다음의 4가지 유형의 S-frame을 규정한다.

• 수신 준비(RR, receive ready)

  코드 부필드의 값이 00이라면, RR S-frames이다. 이 유형의 프레임은 안전하고 온전히 전송된 프레임 또는 일련의 프레임에 대해 확인 응답을 한다.
  $N(R)$의 값은 확인 응답 번호이다.

• 수신 불가(RNR, receive not ready)

  코드 부필드의 값이 10이라면, 이는 RNR S-frames이다. 이 유형의 프레임은 추가적인 기능을 갖는 RR 프레임이다. 이는 프레임 또는 여러 프레임을 수신한 것에 대해 확인 응답을 보내지만, 수신자가 바빠서 더 이상의 프레임을 받을 수 없다는 것을 알리는 것이다. 이는 송신자에게 속도를 늦추도록 하여 일종의 혼잡 제어를 수행한다.
  $N(R)$의 값은 확인 응답 번호이다.

• 거부(REJ, reject)

  코드 부필드의 값이 01이면, 이는 REJ S-frames이다. 이는 NAK 프레임이지만 선택적-거부 ARQ(Selective Repeat ARQ)에 사용되었던 것과는 다르다. 이는 N-프레임-후퇴 ARQ(Go-Back-N ARQ)에서 사용되어 송신자의 타이머가 다 되기 전에 직전의 프레임이 손실되었거나 손상된 것을 송신자에게 알려서 처리 효율을 높이는 데 사용된다.
  $N(R)$의 값은 NAK 번호이다.

• 선택적 거부(SREJ, selective reject)

  코드 부필드의 값이 11이면 이는 SREJ S-frames이다. 이는 SR ARQ에서 사용되는 NAK이다. HDLC 프로토콜에서는 선택적 반복(Selective Repeat)대신에 선택적 거부(Selective Reject)라고 한다.
  $N(R)$의 값은 NAK 번호이다.

U-frames에서 제어 필드 (Control Field for U-Frames)

비번호 프레임은 서로 연결된 장치들 간에 세션(session) 관리와 제어 정보를 교환하는 용도로 쓰인다.
S-frame과는 달리 U-frame은 정보 필드를 가지고 있으나, 이 정보 필드는 사용자 데이터가 아니라 시스템 관리 정보를 위해 쓰인다.
그러나 S-frame과 같이 U-frame도 제어 필드에 들어 있는 코드에 의해 많은 정보를 전달한다. U-frame의 코드는 P/F 비트 앞에 있는 2비트와 뒤에 있는 3비트로 구성되어 있다. 이 두 세그먼트(5비트)를 조합하여 총 32가지의 U-frame을 만들어 사용할 수 있다.

그림 11.18은 어떻게 U-frame을 사용하여 연결 설정과 해제를 하는지를 보여준다. 노드 A가 일련의 SABM(Set Asynchronous Balanced Mode) 프레임을 사용하여 설정을 요청하고 노드 B는 이에 UA(unnumbered acknowledgement)프레임을 사용하여 확인 응답을 보내는 것에 유의하라.
이 교환 후에 두 노드들 사이에 데이터 교환이 일어날 수 있다. 데이터 전달 이후에는 노드 A는 DISC(disconnect) 프레임을 보내 연결을 해제하며 노드 B는 UA(unnumbered acknowledgement)프레임을 보내 이에 응답한다.(비번호 확인 응답)

그림 11.19는 피키배킹을 이용한 두 가지 교환을 보여준다.
첫 번째 경우는 오류가 발생하지 않을 때이다.
두 번째 경우는 오류가 발생하고 일부 프레임이 폐기되었을 때이다.

11.4 점-대-점 프로토콜(PPP, Point-to-Point Protocol)

점-대-점 연결의 가장 널리 사용되는 프로토콜은 점-대-점 프로토콜(PPP)이다.
오늘날 수백만의 인터넷 사용자들은 인터넷 서비스 제공자의 서버에 자신들의 컴퓨터를 PPP를 통해 연결한다. 대부분 사용자는 전통적인 모뎀을 가지고 물리층 서비스를 제공하는 전화선을 통해 인터넷에 연결된다. 그러나 데이터 전송을 제어하고 관리하기 위해서는 데이터 링크층에서 점-대-점 프로토콜이 필요하다. PPP는 현재까지 가장 널리 사용되는 프로토콜이다.

11.4.1 서비스 (Services Provided by PPP)

PPP의 설계자는 PPP를 점-대-점 프로토콜에 적합하게 만들기 위해 여러 가지 서비스를 포함시켰다. 반면에 PPP를 간단히 하기 위해 몇 가지 전통적인 서비스는 무시했다.

PPP가 제공하는 서비스

PPP는 기기 간의 교환될 프레임의 프레임의 포맷을 정의한다. 또한, 두 장치가 어떻게 링크 설정을 교섭(Negotiate)하고 데이터를 교환할지를 정의한다. PPP는 여러 네트워크층으로부터 페이로드를 받도록 설계되었다(IP뿐만이 아닌). 인증 또한 프로토콜에 선택적으로 제공된다.
다중링크 PPP(Multilink PPP)로 불리는 PPP의 새 버전은 다중 링크로 연결을 제공한다. PPP의 한 가지 흥미로운 특징은 네트워크 주소 구성을 지원한다는 것이다. 이것은 가정 사용자(Home user)가 인터넷에 연결하기 위해 임시로 네트워크 주소가 필요할 때 특히 유용하다.

PPP가 제공하지 않는 서비스

PPP는 흐름 제어를 제공하지 않는다. 송신자는 수신자를 생각하지 않고 프레임을 계속 보낼 수 있다. PPP는 매우 간단한 오류 제어를 한다. CRC 필드가 오류 검출에 사용된다. 프레임이 손상되었으면 그냥 폐기하고 상위 계층 프로토콜이 이 문제를 해결해야 한다. 오류 제어를 하지 못하고 순서 번호가 없기 때문에 순서가 바뀌어 패킷이 도달할 수 있다. PPP는 다중점 링크에서 프레임을 다룰 수 있는 주소지정 방법이 없다.

11.4.2 Framing

PPP는 문자-중심(혹은 바이트-중심) 프레임을 사용한다. 그림 11.20은 PPP프레임의 형식을 보여 준다.

• 플래그(Flag)

  PPP프레임은 01111110 값을 가진 1바이트 플래그로 시작하고 끝난다.

• 주소 (Address)

  이 프로토콜에서 주소 필드는 일정한 값으로 11111111(브로드캐스트 주소)로 설정한다.

• 제어 (Control)

  이 제어 필드는 HDLC의 U-frame을 모방한 일정한 값 00000011로 설정한다. 뒤에 논의하겠지만, PPP는 어떤 흐름 제어도 제공하지 않는다. 오류 제어 또한 오류 검출을 위해 제한된다.

• 프로토콜 (Protocol)

  프로토콜 필드는 데이터 필드에 사용자 데이터 또는 다른 정보가 들어 있는 것을 정의한다. 이 필드는 기본 2바이트를 사용하지만 두 당사자는 단지 1바이트만 사용하도록 동의할 수 있다.

• 페이로드 필드 (Payload field)

  이 페이로드 필드는 곧 논의할 사용자 데이터나 그 밖의 정보들을 전달한다. 데이터 필드는 기본적으로 최대 1,500바이트를 갖는 바이트의 순서이다.
  하지만 이는 교섭하는 동안 바뀔 수 있다. 데이터 필드는 이 필드에 플래그 바이트 패턴이 나타나면 바이트 채우기가 된다. 왜냐하면, 데이터 필드의 크기를 정의하는 필드가 없어서, 크기가 최대 기본값 또는 최대 교섭 값보다 작으면 패딩이 필요하다.

• FCS

  프레임 검사 순서 값은 간단히 2바이트 또는 4바이트 표준 CRC이다.

바이트 채우기 (Byte Stuffing)

PPP는 바이트 중심 프로토콜이기 때문에, PPP의 플래그가 프레임의 데이터 부분에 나타나면 ESC문자를 사용하여 표시해야 한다. ESC 바이트는 01111101이며 이는 데이터에 플래그와 같은 패턴이 나타날 때마다 이 추가 바이트를 더하여 수신자가 다음 바이트가 플래그가 아닌 것을 알 수 있게 해주어야 한다. 즉 ESC 바이트는 또 다른 ESC 바이트로 채우는 것이다.

천이 단계 (Transition Phases)

하나의 PPP 연결이 겪는 단계들은 그림 11.21과 같이 천이 단계 다이어그램으로 보여줄 수 있다. FSM(유한상태모델)에서 천이 다이어그램은 정지(Dead) 상태로 시작한다. 이 상태에서는 (물리층에서) 전송 활동은 없으며 회선이 아무도 사용하지 않는 경우이다. 두 노드 중 하나가 통신을 시작하게 되면 연결은 설정(Establish) 상태로 들어간다. 이 상태에서는 양 끝의 단말 간에 옵션에 대해 협상을 한다. 만약 두 단말이 인증(Authentication)이 필요하다고 동의하면(예를 들어, 서로 모른다면), 시스템은 인증을 필요로 한다(추가 단계). 그렇지 않으면 단말은 간단히 통신을 시작할 수 있다. 곧 논의될 링크 제어 프로토콜 패킷은 이 목적을 위해 사용된다. 여러 패킷이 여기서 교환된다.
데이터 전송은 열린(Open) 상태에서 일어난다. 연결에서 이 상태는 데이터 교환이 진행된다. 연결은 어느 한 쪽이 연결을 종료하기 전에는 이 상태로 유지된다. 연결이 종료되면 시스템은 해제(Terminate) 상태로 간다. 시스템은 전송(물리층 신호)이 끝날 때까지 이 상태로 남아 있고 후에 시스템은 다시 정지 상태로 이동한다.

다중화 (Multiplexing)

PPP가 비록 데이터 링크층 프로토콜이지만 PPP는 링크를 설정하고 관련 당사자를 인증하며 네트워크층 데이터를 전달하는 등 일련의 다른 프로토콜도 사용한다. 세 종류의 프로토콜이 정의되어 있는데 링크 제어 프로토콜(LCP, Link Control Protocol)과 2개의 인증 프로토콜(APs, Authentication Protocols)과 몇 개의 네트워크 제어 프로토콜(NCPs, Network Control Protocols)이 있다.
임의의 순간에 PPP 패킷은 그림 11.22에 보인 것처럼 각 데이터 필드에 데이터를 전달할 수 있다. 오직 하나의 LCP와 2개의 AP, 그리고 여러 개의 NCP가 있는 것에 유의하라. 데이터는 몇 개의 다른 네트워크 층에서 들어올 수 있다.

링크 제어 프로토콜(Link Control Protocol)

링크 제어 프로토콜(LCP, Link Control Protocol)은 링크의 설정, 유지, 구성과 해제를 담당한다.
또한, 두 단말 간의 선택사항을 결정하기 위한 협상 기능을 제공한다. 링크의 양 단말은 링크가 설정되기 전에 선택사항에 대해 일치해야 한다.
(그림 11.21 참고)

모든 LCP 패킷은 16진수 C021로 설정된 프로토콜 필드를 가진 PPP 프레임의 페이로드 필드를 이용하여 전송된다. (그림 11.23 참고)

Code 필드는 LCP 패킷의 유형을 정의한다. 표 11.1은 패킷의 11가지 유형을 보여준다.

세 범주의 패킷이 있다.
첫 번째 범주는 처음 4개의 패킷 종류를 구성하는데 설정 상태에서 회선 구성을 위해 사용된다.
두 번째 범주는 5번 및 6번 패킷 종류를 구성하는데 해제 상태에서 연결을 해제하는 데 사용된다.
남은 5개의 패킷은 회선 감시와 디버깅을 위해 사용된다.

ID 필드는 응답과 함께 요청에 부응하는 값을 가지고 있다. 한쪽에서 이 필드에 값을 삽입하면 다른 편의 응답에 그 값이 복제되어 온다. 길이 필드는 LCP 패킷의 전체 길이를 지정한다. 정보 필드는 선택사항 등과 같은 정보가 들어 있다.

두 단말 사이에는 협상이 이루어져야 하는 많은 선택사항이 있으며, 선택사항은 구성 패킷(Configuration Packet)의 정보 필드에 들어 있다. 이 경우 정보 필드는 선택사항 유형, 선택사항 길이 및 선택사항 데이터라는 세 가지 필드로 나뉜다. 표 11.2에 가장 일반적인 선택사항의 일부를 수록하였다.

인증 프로토콜 (Authentication Protocols)

PPP가 사용자의 인증이 필수적인 전화선 링크를 사용하도록 설계되었기 때문에 인증은 PPP에서 중요한 역할을 하고 있다. 인증(Authentication)이란 자원에 접근하기를 원하는 사용자의 신원을 증명하는 것이다.
PPP는 인증을 위해 패스워드 인증 프로토콜(Password Authentication Protocol)과 챌린지 핸드셰이크 인증 프로토콜(Challenge Handshake Authentication Protocol)을 만들었다. 이 프로토콜은 인증 단계 동안 사용된다는 것에 유의하라.

패스워드 인증 프로토콜 (PAP, Password Authentication Protocol)

PAP는 2단계의 처리 과정을 단순한 인증 절차이다.
1. 시스템에 접근하기를 원하는 사용자는 인증 식별자(보통은 사용자 이름)와 패스워드를 보낸다.
2. 시스템은 식별자와 패스워드의 유효성을 검사하여 연결을 설정하거나 거부한다.

그림 11.24는 PAP가 사용하는 패킷의 3가지 유형과 어떻게 이들이 실제적으로 교환되는지를 보여준다.
PPP프레임이 PAP 패킷을 전달하는 경우에는 프로토콜 필드의 값이 0xC023이다.
PAP 패킷에는 인증-요청(Authenticate-request), 인증-확인응답(Authenticate-ack)과 인증-부정응답(Authenticate-nak)이라는 3가지가 있다.
첫 번째 패킷은 사용자가 사용자 이름과 패스워드를 송신하는 데 사용된다.
두 번째는 시스템이 접근을 허용할 때 사용하며
세 번째는 접근을 거부할 때 사용한다.

챌린지 핸드셰이크 인증 프로토콜 (CHAP, Challenge Handshake Authentication Protocol)

CHAP는 PAP보다 높은 보안을 제공하는 3-방향 핸드셰이크(3-way handshake) 인증 프로토콜이다. 이 방법은 패스워드를 비밀로 하며 절대로 회선 상에 보내지 않는다.
1. 시스템이 보통 몇 개의 바이트인 챌린지 값이 들어 있는 챌린지 패킷을 사용자에게 보낸다.
2. 사용자는 챌린지 값과 사용자의 패스워드를 받아들이는 미리 정의된 함수를 적용하여 결과를 만들어낸다. 사용자는 이 결과를 응답 패킷에 넣고 시스템에게 보낸다.
3. 시스템도 같은 일을 수행한다. 시스템도 사용자의 패스워드(시스템에게 이미 알려진 것)와 챌리지 값을 같은 함수에 적용하여 결과값을 만든다. 만약 만들어진 결과가 응답 패킷으로 보내진 것과 같으면 접근이 허용되고 아니면 거부된다.

CHAP는 PAP보다 안전하며, 특히 시스템이 계속 챌린지 값을 변경하면 더욱 안전하다. 침입자가 챌린지 값과 결과값을 알게 되더라도 패스워드는 여전히 비밀이다. 그림 11.25는 CHAP 패킷과 어떻게 사용되는지를 보여준다.

CHAP 패킷은 16진수 프로토콜 값 C223을 가지고 PPP프레임에 캡슐화되어 있다. CHAP 패킷은 챌린지(Challenge), 응답(Response), 성공(Success), 실패(Failure)라는 4가지가 있다.
챌린지 패킷은 시스템이 챌린지 값을 송신하는 데 사용되며
응답 패킷은 사용자가 계산 결과를 돌려보낼 때 사용된다.
성공 패킷은 시스템이 시스템에 접근하는 것을 허용할 때 사용되며
실패 패킷은 접근을 거부할 때 사용된다.

네트워크 제어 프로토콜 (Network Control Protocols)

PPP는 다중 네트워크층 프로토콜이다. 인터넷, OSI, Xerox, DECnet, AppleTalk, Novel 등에 의해 정의된 프로토콜의 네트워크층 패킷을 전달할 수 있다. 이를 위해 각 네트워크 프로토콜에 대해 특정 NCP를 정의하고 있다. 예를 들면 IPCP(Internet Protocol Control Protocol)는 IP 패킷을 전달할 수 있도록 회선을 구성한다. Xerox CP는 Xerox 프로토콜 데이터 패킷 등과 동일하게 한다. 그 어떤 NCP 패킷도 네트워크층 데이터를 전달하지 않는 것에 유의하라. 대신 들어올 데이터를 위해 네트워크층의 회선을 구성할 뿐이다.

IPCP (Internet Protocol Control Protocol)

IP 패킷을 위한 네트워크층 연결을 설정 또는 종료하는 패킷의 집합을 IPCP이라고 한다. IPCP 패킷의 형식은 그림 11.26에 나타나 있다. 프로토콜 필드의 값(0x8021)이 IPCP 패킷으로 캡슐화된 패킷을 정의한다는 것에 주의하자.

IPCP 프로토콜은 코드 값으로 구별되는 7가지 패킷을 정의했으며, 이는 표 11.3에 나타나 있다.

기타 프로토콜

다른 네트워크층 프로토콜을 위해서 서로 다른 NCP 프로토콜이 있다. OSI 네트워크층 제어 프로토콜은 프로토콜 필드 값으로 8023을 사용하며 Xerox NS IDP 제어 프로토콜은 8025를 값으로 갖는다.

네트워크 층으로부터 데이터 (Data from the Network Layer)

특정 NCP 프로토콜에 의해 네트워크층 구성을 확인한 후에 사용자는 네트워크층으로부터 데이터 패킷을 교환할 수 있다. 여기에서 서로 다른 네트워크 프로토콜에 대해 서로 다른 프로토콜 필드가 있다. 예를 들면 만일 PPP가 IP 네트워크층으로부터 데이터를 전달하면 필드 값은 0021이다. 만일 PPP가 IP 네트워크층으로부터 데이터를 전달하면 필드 값은 0021이다. 만일 PPP가 OSI 네트워크층 프로토콜로부터 데이터를 전달하면 그 값은 0023이다. 그림 11.27은 IP에 대한 프레임을 보여주고 있다.

다중링크 PPP (Multilink PPP)

PPP는 원래 단일 채널 점-대-점 물리 링크를 위해 설계되었다. 단일 점-대-점 회선에서 다중 채널이 가능해짐에 따라 다중회선 PPP가 개발되었다. 이 경우에는 하나의 논리적인 PPP 프레임이 몇 개의 실제 PPP 프레임으로 나뉜다. 논리 프레임의 세그먼트는 그림 11.28에 나타난 것처럼 어떤 한 실제 PPP 프레임의 페이로드로 전달된다. 실제 프레임이 논리적 PPP프레임의 세그먼트를 전달하는 것을 보이기 위해 프로토콜 필드 값이 (003d)$_{16}$로 설정된다. 이 새로운 개발로 인해 복잡해졌다. 예를 들면 실제 PPP 프레임이 논리적 PPP 프레임의 몇 번째 세그먼트인지를 나타내기 위해 순서 번호가 필요해졌다.