데이터 링크 계층에서 두 호스트가 통신하려면 일대일(1:1)형식의 점대점 방식으로 연결해야한다.
송신 호스트에서 전송한 프레임은 점대점으로 직접 연결되어 수신 호스트에 라우팅 과정 없이 전달된다.
기본적으로 데이터 링크 계층 프로토콜은 직접 연결 구조에서 둘 사이의 전송 오류를 감지하고, 이를 복구 하는 기능을 지원한다. 멀티 드롭의 구조를 지원하려면 호스트 주소 개념이 추가로 필요하다.
- 하나의 호스트가 다수의 호스트와 연결된 비대칭 형태로, 이러한 구조를 멀티드롭 방식이라 한다.
- 멀티드롭에서는 하나의 물리 매체를 여러 호스트가 공유하므로, 임의의 호스트에서 전송한 프레임은 물리적으로 다른 호스트에 전달된다.
- 전송 선로에 두 개의 호스트만 연결되므로 호스트를 구분하기 위한 주소 개념이 필요 없다.
- 여러 수신 호스트 중에서 프레임의 목적지 호스트를 지칭하기 위한 주소 개념이 필요하다.
- 물리 계층을 통해 이루어지는 두 호스트 간의 데이터 전송 과정에서 물리적인 전송 오류가 발생할 수 있다. 이 같은 물리적인 오류를 복구하는 것은 데이터 링크 계층의 기본 역할이다.
- 데이터 링크 계층은 상위 계층에 신뢰성 있는 데이터 전송을 보장한다.
- 신뢰성 있는 논리 선로를 제공하기 위한 오류 제어 방식으로 재전송 기법을 사용한다.
- 재전송 기법은 송신 호스트가 전송한 프레임에 오류가 발생하면 송신 호스트가 전송 데이터를 재전송하여 오류를 복구하는 것이다.
프레임의 종류
데이터 링크 계층의 동작 원리를 이해하려면 프로토콜에서 자주 언급 되는 프레임을 먼저 이해해야 한다. 데이터 링크 계층에서 전송 오류를 해결하는 과정에서 사용하는 프레임에는 정보 프레임, 증정 응답 프레임, 부정 응답 프레임이 있다.
정보 프레임
- 정보 프레임은 상위 계층이 전송을 요구한 데이터를 수신하여 호스트에 전송하는 용도로 사용한다. 약칭하여 I프레임으로도 표기하며, 상위 계층에서 보낸 데이터와 함께 프레임의 순서 번호, 송수신 호스트의 주소 정보를 포함한다.
- 순서 번호는 각 정보 프레임에 부여되는 고유의 일련 번호로, 수신 호스트가 중복 프레임을 구분할 수 있도록 해준다.
긍정 응답 프레임
- 정보 프레임을 수신한 호스트는 맨 먼저 프레임의 내용이 깨졌는지 확인해야 한다. 프레임 변형 오류가 발생하지 않으면 송신 호스트에 해당 프레임을 올바르게 수신했다는 의미로 ACK 프레임, 즉 긍정 응답을 회신한다. 긍정 응답 프레임을 수신한 송신 호스트는 데이터가 제대로 도착했음을 확인할 수 있다.
부정 응답 프레임
- 정보 프레임의 전송 과정에서 프레임 변형 오류가 발생하면 수신 호스트는 송신 호스트에 NAK 프레임을 회신한다. 즉, 부정 응답을 전달하여 송신 호스트가 오류 발생을 인지하고 원래의 정보 프레임을 재전송하도록 요청하는 것이다.
- 재전송 요구를 받은 송신 호스트는 오류가 발생한 프레임을 동일한 순서 번호로 다시 재전송 해야 한다.
- 정보 프레임 뿐 아니라 긍정 응답, 부정 응답 프레임이도 회신하고자 하는 정보 프레임의 순서 번호가 포함된다.
- 정보 프레임의 송신 호스트는 몇 번 프레임이 제대로 도착하고, 몇 번 프레임에서 오류가 발생했는지 응답 프레임의 순서 번호를 판단할 수 있다.
3가지 프레임을 사용해 데이터 링크 계층의 전송 프로토콜을 작성할 수 있다.
프로토콜의 설게 과정에서 다루는 내용은 주로 오류 제어, 흐름 제어, 양방향, 단방향 전송 방식등이다.
오류, 흐름 제어가 없는 프로토콜
전송 프로토콜의 구조를 가장 단순화하기 위해 통신 환경을 다음과 같이 가정한다. 이는 매우 이상적인 경우를 가정한 것으로, 데이터 전송 과정에서 어떠한 오류도 발생하지 않기 때문에 오류 제어 기능이 필요 없다. 또한 수신 호스트의 버퍼 용량에 제한이 없으므로, 송수신 호스트 사이의 속도 차이로 인해 프레임을 분실할 염려가 없어 흐름 제어 기능도 필요 없다.
단방향 통신 : 데이터는 송신 호스트에서 수신호스트로만(한족 방향으로만)전달된다.
전송 오류가 없는 물리 매체: 통신 채널에서는 어떠한 형태의 전송 오류도 발생하지 않는다.
무한 개의 수신 버퍼 : 수신 호스트의 버퍼 수는 무한하다.
위의 가정을 적용한 통신 프로토콜에서 송수신 호스트 사이의 데이터 전송은 구조가 단순하다. 즉, 송신 호스트가 전송한 프레임은 수신 호스트에 항상 안전하게 도착하므로 송신 호스트가 프레임을 원하는 만큼 계속 전송할 수 있다.
오류 제어 측면을 살펴보면 데이터 전송 과정에서 프레임 분실이나 변형과 같은 어떠한 형태의 오류도 발생할 가능성이 없다. 따라서 송신 호스트는 수신 호스트로부터 전송 프레임에 대한 응답을 받지 않아도 되므로, 수신호스트로부터 전송 프레임에 대한 응답을 받지 않아도 되므로, 단순히 정보 프레임을 전송하는 것만으로 송신 호스트의 역할은 완료된다.
흐름 제어 측면에서는 수신 호스트의 버퍼 크기가 무한하므로 버퍼 용량 부족에 따른 프레임 분실 오류를 걱정할 필요가 없다. 따라서 송수신 호스트 사이의 흐름 제어 기능이 필요 없어 상위 계층이 요청한 데이터를 수신 호스트에 송신하는 과정만 필요하다.
I형태로 표시한 내용은 순서 번호가 I인 정보 프레임을 의미하는데, 이는 이해를 돕기 위한 것이지 순서 번호가 필요하다는 뜻은 아니다. 수신 호스트 입장에서는 프레임이 항상 오류 없이 도착하므로 송신 호스트에 별도의 응답 프레임을 전송할 필요가 없다. 또한 프레임이 중복해서 도착할 염려거 없으므로 순서 번호로 프레임을 구분하는 기능도 필요없다. 순서 번호를 생략해도 프로토콜의 동작에는 영향을 주지 않는다. 수신 호스트는 도착한 프레임을 상위 계층에 전달하는 작업을 통해 수신 작업을 완료할 수 있다.
오류제어가 없는 프로토콜
두 번째로 가정하는 통신 환경은 수신 호스트의 버퍼 개수가 유한하다. 버퍼 개수가 제한되면 송신 호스트가 전송한 정보 프레임의 수신 작업이 늦어질 때, 버퍼에 일시적으로 보관할 수 있는 프레임의 개수가 제한된다. 따라서 버퍼 용량 부족으로 프레임 분실 오류가 발생할 가능성이 있으므로 송수신 호스트 사이의 흐름 제어 기능이 필요하다.
단방향 통신
데이터는 송신 호스트에서 수신 호스트로만(한쪽 방향으로만)전달한다.
전송 오류가 없는 물리 매체 : 통신 채널에서는 어떠한 형태의 전송 오류도 발생하지 않는다.
수신 호스트의 버퍼가 유한 개로 제한되는 환경에서 송신 호스트가 너무 빨리 정보 프레임을 전송하면 버퍼 부족으로 프레임 분실 오류가 발생할 수 있다. 이를 방지하려면 프로토콜을 설계하는 과정에서 흐름 제어 기능을 제공하여 송신 호스트의 전송 속도를 조절해야 한다.
흐름 제어는 주로 수신 호스트가 송신 호스트의 프레임 전송 시점을 제어하는 형태로 이루어 진다.
가장 간단한 형태는 수신 호스트가 이전 프레임의 수신을 완료한 후에 다음 프레임을 전송하도록 소신 호스트에 지시하는 것이다. 이 때 사용하는 프레임이 ACK 프레임이다. 결과적으로 ACK 프레임은 송신 호스트에 이전 프레임을 잘 받았다는 긍정 응답 기능을 수행하는 동시에, 다음 프레임을 전송하도록 지시하는 흐름 제어 기능도 수행한다.
흐름 제어 기능을 제공하지 않으면, 버퍼 부족으로 프레임 분실 오류가 발생해 중복 프레임을 수신할 수 있다. 따라서 일반적인 관점에서는 수신 호스트가 중복 프레임을 구분할 수 있는 순서 번호 기능이 필요하다. 간단한 흐름 제어 환경에서는 분실 오류에 의한 중복 프레임이 발생할 가능성이 없기 때문에 순서 번호를 사용하지 않아도 된다.
송신 호스트가 정보 프레임을 전송하고 이어서 다음 정보 프레임을 전송하려면 ACK 프레임이 도착하기를 기다려야 한다. 이처럼 각 정보의 정보 프레임에 대한 수신 호스트가 회신하는 ACK프레임이 도착해야 다음 프레임을 전송할 수 있는 프로토콜 방식을 정지-대기 방식이라 한다. 정지-대기 프로토콜은 전송 효율이 매우 떨어지므로 일반 네트워크 환경에서는 사용하지 않는다.
단방향 프로토콜
단방향 통신 : 데이터는 송신 호스트에서 수신 호스트로만(한쪽 방향으로만)전달된다.
오류 제어와 흐름제어가 필요한 통신 환경에서 송신 호스트가 전송한 정보 프레임에 발생할 수 있는 오류에는 프레임 분실 오류와 프레임 변형 오류가 있다.
프레임 분실은 전송된 프레임이 수신 호스트에 도달하지 못하고 전송 도중에 사라지는 경우이다.
수신 호스트는 정보 프레임이 도착하길 무한정 기다린다. 결과적으로 수신 호스트가 ACK 프레임을 회신할 수 없으므로 송신 호스트도 ACK 프레임의 도착을 무한정 기다린다.
위의 현상 예방법
송신 호스트의 타임아웃 기능이 반드시 필요하다. 정보 프레임을 전송한 후에 특정 시간이 지날 때 까지 수신 호스트의 ACK/NAK 프레임을 회신받지 못하면 송신 호스트는 프레임 분실이 발생한 것으로 간주한다. 프레임 분실 오류가 발생하면 송신 호스트의 타임아웃 기능이 동작하여 분실된 프레임을 재전송하는 방식으로 복구한다. 오류 제어가 없는 프로토콜에서도 송신 호스트의 타임 아웃 기능이 필요할 수 있다.
NAK가 없는 경우
NAK 프레임이 정의되지 않은 프로토콜에서 오류를 복구하는 방법
- 송신 호스트가 전송한 정보 프레임을 분실한 경우, 수신 호스트는 받은 것이 없으므로 정보 프레임에 대한 응답 프레임을 회신할 수 없다.
- 문제는 송신 호스트가 ACK 프레임을 수신해야 다음 동작을 취할 수 있으므로 프로토콜이 설계된 경우이다. 송신 호스트는 ACK 프레임이 도착하기를 무한정 기다리고, 결과적으로 송수신 호스트 모두 상대방의 행동을 기다리면서 프로토콜의 진행이 멈추는 현상이 발생할 수 있다.
해결법
송신 호스트가 정보 프레임을 전송한 후에 반드시 해당 프레임의 전송 시간을 고려한 제한 시간을 설정하여 타이머를 작동시켜야 한다. 송신 호스트는 정보 프레임I(i)를 전송하면서 바로 타이머를 구동시키고, 임의으 시간까지 ACK 프레임이 도착하지 않으면 시간 초과에 따른 타이머 동작으로 정보 프레임I(i)를 재전송 한다.
프레임 분실 오류에 대한 설명이지만 프레임 변형 오류에도 동일하게 적용된다. NAK 프레임이 정의되지 않아 수신 호스트가 프레임 변형 오류에 응답할 방법이 없다.
수신 호스트가 정보 프레임을 오류 없이 제대로 수신하여 이 프레임에 대한 ACK 프레임을 올바르게 회신하였다. 그러나 ACK 프레임이 송신 호스트에 회신되는 과정에서 손실 혹은 변형되어 송신 호스트가 정보 프레임이 올바르게 전달되었다는 사실을 모르는 경우이다. 송신 호스트 입장에서는 타이머 동작에 의한 재전송 과정이 필요하다. 송신 호스트의 타임아웃 기능에 의해 오류 복구 기능이 진행되어야 한다.
NAK가 있는 경우
정보 프레임의 과정에서 프레임이 수신 호스트에 도착했으나 내용의 일부가 파손되거나 프레임 변형 오류가 발생할 수 있다. 내용은 변형됐지만 프레임을 제대로 수신한 경우에는 변형된 프레임을 무시하는 것으로 이는 프레임 분실 오류와 동일한 결과를 가져오기 때문에 분실 처리에 따른 타임아웃 기능을 거친다.
두 번째 방식은 NAK 프레임을 이용해 프레임 변형 사실을 송신 호스트에 통보하는 것이다. 프레임 변형 오류와 프레임 분실 오류를 명확히 구분해 처리한다. 직관적으로 보면 NAK 프레임을 이용해 송신 호스트에 재전송을 요구하는 방식이 호스트 타이머 기능을 이용하는 것보다 효과적일 수 있다.
실제 네트워크 프로토콜에서 정보 프레임에서 변형된 부분이 순서 번호처럼 주요한 정보일 수 있고, 다른 네트워크 환경 요소에 의해 NAK 프레임을 이용하지 못할 수 있다.
결론적으로 두 가지 원인이 발생했을 때 송신 호스트의 재전송 기능으로 오류 복구가 이루어진다.
1. 정보 프레임에 대한 수신 호스트의 응답이 없을 때 송신 호스트의 타임아웃 기능에 의해 복구가 이루어 지는 경우,
2. 수신 호스트가 회신한 부정 응답 프레임에 의해 복구가 이루어지는 경우이다.
Reference
쉽게 배우는 데이터 통신과 컴퓨터 네트워크
'CS > Network' 카테고리의 다른 글
[Chapter 6] 데이터 링크 계층(HDLC 프로토콜) (0) | 2025.02.13 |
---|---|
[Chapter 6] 데이터 링크 계층(슬라이딩 윈도우 프로토콜) (0) | 2025.02.12 |
[Chapter 5] MAC 계층(토큰 링) (0) | 2025.02.11 |
[Chapter 5] MAC 계층(토큰 버스) (0) | 2025.02.11 |
[Chapter 5] MAC 계층(이더넷) (0) | 2025.02.11 |