우리가 5장에서는 데이터 링크 계층 중 MAC 계층에 대해서 이야기를 했다면
6장에서는 똑같은 데이터 링크 계층 중 LLC 계층에 대해서 이야기를 할 것이다.
LLC 계층은 주로 데이터 링크 계층의 주요 역할인 오류 제어와 흐름 제어를 진행한다.
데이터 링크 계층에서 통신을 위한 연결 방식에는
(a)와 같은 점대점 방식과
(b)와 같은 하나의 호스트에 다수 호스트가 연결되는 멀티 드롭 방식이 있다.
데이터 링크 계층에서 우리가 프레임을 구분할 때는 위와같이 3가지 프레임으로 구분한다.
- 정보 프레임
- 긍정 응답 프레임
- 부정 응답 프레임
이렇게 응답 프레임이 있는 이유는 데이터 링크 계층에서 오류를 제어하기 위해서이다.
응답을 통해 우리가 오류가 발생했는지 아닌지를 판단하며,
긍정 응답과 부정 응답은 우리가 이전에 배웠던 내용 그대로이다.
-
긍정 응답 프레임
= 송신 호스트에 해당 프레임을 올바르게 수신했다는 의미 -
부정 응답 프레임
= 전송 과정에서 프레임 변형 오류가 발생하여 수신 호스트가 부정 응답을 전달하고 송신 호스트가 이를 인지해 원래의 정보 프레임을 다시 재전송하도록 요청하는 것 -
정보 프레임
= 상위 계층이 전송을 요구한 데이터를 수신 호스트에 전송하는 용도
위 3가지 프레임을 사용해 데이터 링크 계층의 전송 프로토콜을 작성할 수 있고
프로토콜의 설계 과정에서 다루는 내용은 주로
- 오류 제어
- 흐름 제어
- 양방향, 단방향 전송 방식
등이 있다.
예를들어 위 내용과 같이
- 단방향 통신
- 전송 오류가 없는 물리 매체의 경우
- 무한개의 수신 버퍼
- 단방향 통신을 사용하며 - 송신 호스트에서 수신 호스트로만 데이터를 전달
- 전송 오류가 없는 물리 매체의 경우 - 통신 채널에는 어떠한 전송 오류도 발생하지 않음.
-> 오류 제어가 필요 없음
- 무한개의 수신 버퍼 = 수신 호스트의 버퍼는 무한임(송신 호스트로부터 데이터를 계속 받아 버퍼에 저장할 수 있음)
-> 분실이 일어나지 않아 흐름제어가 필요 없음
이러한 가정을 적용한 통신 프로토콜은 위 이미지와 같이 송수신 호스트 사이에 데이터 전송이 단순하다.
위와 같이 구성되어 있는 것을 확인할 수 있다.
그럼 2번째 예제로
- 단방향 통신,
- 전송 오류가 없는 물리 매체
- 수신 호스트의 버퍼가 유한개로 제한되는 상황의 경우
다음과 같은 문제가 발생할 수 있다.
단방향 통신과 전송 오류가 없는 물리 매체는 위와 같이 문제가 없지만
수신 호스트의 버퍼가 유한개로 제한되면 -> 송신 호스트가 너무 빨리 정보를 보내면 수신 호스트의 버퍼가 부족해져 프레임 분실 오류가 발생할 수 있다.
=> 이를 방지하기 위해서
우리는 설계 과정에서 흐름 제어 기능을 제공해 송신 호스트의 전송 속도를 조절할 수 있도록 해야 한다.
흐름 제어는 주로 수신 호스트가 송신 호스트의 프레임 전송 시간을 제어하는 형태로 이루어짐.
그 사진은 다음과 같음.
- 송신 호스트가 데이터를 보냄
- 수신 호스트가 데이터를 받고 송신 호스트에게 ACK 프레임이라는 이전 프레임을 잘 받았고 다음 프레임을 보내 달라는 의미의 흐름 제어 기능을 수행함.
- 송신 호스트는 ACK 프레임을 전달 받고 다시 데이터를 전달
=>
위 방식은 수신 호스트가 회신하는 ACK 프레임이 도착해야 다음 프레임을 전송할 수 있는 정지-대기 방식임
이 정지-대기 방식은 전송 효율이 매우 떨어지기 때문에 사용하지 않는 방식이다.
3번째로
- 단방향 통신
- 오류 제어 필요
- 흐름 제어 필요
- NAK가 없는 경우 (NAK = 부정 응답 프레임)
위와 같은 경우엔
송신 호스트가 전송한 정보 프레임에 발생할 수 있는 오류에는
- 프레임 분실 오류
- 프레임 변형 오류
2가지가 존재한다.
프레임 분실 오류는 위와 같은 상황으로 발생할 수 있다.
아래 예시는 NAK = 부정 응답 프레임이 없는 경우이다.
- (a)와 같이 송신 호스트가 전송한 정보 프레임을 분실한 경우
- (b)와 같이 수신 호스트가 정보를 잘 받았지만 이에 대해 수신 호스트가 회신한 ACK 프레임이 손실, 변형되는 경우(송신 호스트는 ACK 프레임을 제대로 받지 못해 올바르게 전달되었다는 것을 모름)
이런 프레임 분실 오류는 원래는 NAK라는 부정 응답 프레임을 수신 호스트가 전송해서 송신 호스트가 알지만
위 상황은 NAK가 없기 때문에 송신 호스트는 타임아웃이라는 기능을 사용한다.
이 타임아웃 기능은 송신 호스트가 데이터를 보낸 뒤 일정 시간이 지났음에도 수신 호스트로부터 응답이 없으면 송신 호스트가 재전송하는 방향으로 동작하게 되는 것이다.
위 사진에서 송신 호스트가 기다리는 응답은 NAK가 없기 때문에 ACK라는 긍정 응답을 기다리는 것이다.
방금 전에는 프레임 분실 오류에 대해서 봤는데
이번엔 프레임 변형 오류에 대해서 확인해보자.
프레임 변형 오류의 경우도 크게 다르지 않다.
프레임 변형에 대해서도 NAK = 부정 응답 프레임이 없기 때문에 수신 호스트는 송신 호스트에게 프레임 변형에 대한 응답할 방법이 없다.
따라서 이때도 타임아웃 기능을 동일하게 사용한다.
위 그림과 같이 송신 호스트의 타임아웃 기능에 의해서 오류 복구 기능이 진행되어 다시 프레임을 재전송하는 방식으로 프레임 변형 오류를 처리한다.
그럼 NAK가 있는 경우엔 어떻게 처리하냐?
왼쪽과 같이 프레임 변형이 일어난 경우에 NAK가 존재하면 다음과 같이 처리된다.
-
송신 호스트가 데이터를 보냈는데 변형이 발생한 경우
-
수신 호스트는 이에 대해서 NAK를 송신 호스트에게 전달해
-
송신 호스트가 데이터를 재전송 할 수 있도록 한다.
그러나 오른쪽과 같이 프레임 분실 오류가 일어난 경우에 NAK가 있어도 우리는 타임아웃 기능을 사용해야 한다.
-
송신 호스트가 데이터를 전달했지만 분실이 발생함
-
수신 호스트는 이런 사실을 알지 못하기 때문에 송신 호스트의 타임아웃 기능을 사용해야 함
-
송신 호스트는 일정 시간동안 수신 호스트로부터 응답이 없으면 타임아웃 기능을 통해 재전송을 진행
따라서 NAK가 있어도 분실 오류의 대해서는 송신 호스트의 타임아웃 기능을 사용해야 한다.
