[Network4] DLC Layer

DLC 는 Data Link Control 로, 2계층에서 어떻게 데이터의 에러를 검출하고 복구할 것인가이다.

DLC Basic

MAC에도 에러 검출이 일부 존재했었지만 Physical 에서 어떻게 노드들이 데이터를 주고 받을 지에 대한 내용이 메인이었다. DLC 에서는 에러 검출 및 복구를 제어하는 것을 주된 기능으로 삼는다!

2계층은 크게 Framing, Error Control, Flow Control 을 한다.

Framing

프레이밍은 보내고자하는 데이터에 추가적으로 DLC 가 넣어야할 정보를 넣거나 사이즈를 자르는 행위이다. 에러 검출을 위한 정보나 주소 등을 추가할 수 있다.

데이터를 주고받는다는 것은 송신단에서 수신단으로 실제 0과 1의 데이터 조합이 이동하는 것이다. 이때 보내는 정보를 Byte 단위로 처리할 수도 있고, Bit 단위로 처리할 수도 있다.

• character-oriented protocol 도 존재하는데, Char 단위로 데이터를 처리하겠다는 약속이다.
• Flag 는 데이터가 유의미한지 무의미한지 확인하기 위한 정보이다. 피지컬 레이어에서는 실제 데이터를 주고받을 때 이외에도 계속해서 신호가 흐른다. 이때 확실하게 지금의 신호는 유의미하다는 것을 알려주기 위해서 데이터의 시작과 끝에 Flag 를 보내는 것이다.

Byte stuffing and unstuffing

Flag 도 결국 0과 1의 패턴으로 이루어진 데이터이다. 만약 사용자가 보내는 데이터 속에 flag 와 동일한 패턴이 존재한다면 그때 데이터가 끝났다고 판단해버릴 수도 있다. 따라서 데이터 안에 있는 flag 패턴은 flag가 아님을 알려주기 위한 ESC 가 존재한다. 데이터 속에 ESC 가 존재할 수도 있으므로 ESC에 대해서도 똑같이 ESC를 앞에 붙여준다. \를 사용하거나 “ “ 속에서 “를 사용하는 것과 비슷하다고 볼 수 있다. 수신단에서는 ESC 를 다시 없애 기존의 데이터를 복원하는 것이 unstuffing 이다.

BIt stuffing and unstuffing

비트 단위에서는 flag 가 01111110 이라면 데이터 중 0으로 시작해서 1이 5개가 연속되면 무조건 뒤에 0을 추가한다. 과거 피지컬 레이어가 비싸 최대한 효율적으로 사용하기 위해서 다음과 같은 작업을 하였다.

Flow and Error Control

데이터를 일방적으로 보내는 것이 아니라 받는 쪽에서도 계속적으로 피드백을 해준다. 데이터가 에러났으니 다시 보내라, 데이터를 좀 천천히 보내라 등 피드백을 통해 flow, error control 이 이루어진다.

• Connectionless - 데이터를 마음대로 주고받는다. 대부분 흐름, 에러 제어를 하지 않는다.
• Connection-Oriented - 데이터를 주고받기 위해 연결을 하고, 데이터를 보내는 동안 유지한다. 데이터 전송이 끝나면 연결을 해제하는 순서를 가졌다. 흐름, 에러 제어가 원활하게 이루어진다.

Simple Protocol

Flow control, Error control 을 모두 하지 않는 경우이다. 수신자는 보내고 싶은 데이터가 있으면 바로 데이터를 보낸다.

빨간색이 이벤트를 칭한다. 이벤트가 발생하면 검은색이 실행된다. 처음 살아나서 Ready 중 패킷이 오면 프레임을 만들어 보내고 다시 ready 상태에서 기다린다.

레이어 사이에서는 시간 차이가 거의 없지만 프레임이 전송될때는 시간이 소요된다.

Stop-and-Wait Protocol

가장 최초의 에러 검출 및 흐름 제어이다. 일단 에러가 났다는 것을 알아야한다. 메세지가 왔는데 읽을 수 없는 경우, CRC 라는 기법을 사용한다. 데이터 이외의 추가적인 정보를 집어넣어 에러가 발생하면 추가적인 정보도 변형되었기에 데이터를 버린다. 만약 수신단에 메세지가 아예 오지 않았을 경우 이는 송신단에서만 알 수 있다. 따라서 응답이 오지 않는다면 메세지가 없어졌다고 판단하고 다시 보내게된다.

검정 부분이 CRC 라는 코드이다. 이 코드값이 계산되어 frame 에 붙는다. 수신단은 읽고 ACK를 stuffing 해서 CRC 값을 계산한다. 이때 받은 CRC 값과 동일하면 에러가 없기에 ACK 를 보내게된다.

• 데이터가 변질된 경우 CRC 계산을 통해 알 수 있고 변질된 데이터는 버린다. 그러면 송신단에서는 ACK 가 도착하지 않기 때문에 일정 시간을 기다렸다가 다시 재전송한다.
• 데이터가 유실된 경우 동일하게 송신단에게 ACK 가 전달되지 않아 재전송할 수 있다.

송신단은 타이머를 가지고 있다. 일정 시간동안 ACK 가 도착하지 않는다면 일정 횟수만큼 계속해서 재전송을 한다.

첫번째 패킷을 보낼 때는 정상 전송이 되었다. 두 번째 패킷은 메세지가 사라지고 일정 시간 후 같은 프레임을 카피해서 정상 전송되었다. 세 번째 패킷은 ACK가 사라졌다. 수신단은 패킷을 상위 레이어에 전달한 상황이다. 하지만 송신단은 ACK가 안와서 다시 전달하고 수신단이 다시 받아 상위 레이어에 올리게 되어 중복되는 것이 문제이다.

위와 같은 문제를 해결하기 위한 방법이다. frame 에 0 혹은 1의 번호를 붙이고 ACK 는 frame 보다 1 높은 값을 보낸다. 번호를 매겨 송수신하기 때문에 중복 수신한 경우 같은 패킷을 상위 레이어에 올리지 않아도 된다.

Piggybacking

현대에서는 메세지가 양방향으로 빈번하기 때문에 ACK 만 전송하는 것이 아니라 자신의 데이터에 ACK 를 함께 보낸다.

Go-Back-N Protocol

송신단에서 메세지를 하나가 아니라 미리 정한 숫자 만큼을 보낸다. 송신단에서는 수신단으로부터 ACK가 안오더라도 여러 개의 메세지를 보낼 수 있다.

윈도우 - 메세지를 여러 개 연결해놓은 것. 프레임 번호를 가지고 있다. Send window size - Ack가 없더라도 0에서 14까지는 보낼 수 있다. 2^4-1 = 15개. 주황색 박스 - 메세지는 보냈지만 ACK는 안옴. 응답을 기다려야하는 메세지의 번호를 기억할 필요가 있음. Sf라는 값으로 가르킴. Sn - 다음번에 보낼 때 쓸 숫자를 가르킴.

0~14를 쏠 수 있고 0~6은 이미 보냈다. 7~14는 다음에 보낼 수 있다.

ACK가 012 가 왔다고 하면 Sf는 3으로 바뀐다. window 사이즈는 그대로이므로 7~15, 0~1 까지 보낼 수 있다.

자료구조에서 Circular Ring과 비슷하다고 볼 수 있다. 윈도우를 이동하면서 해서 Sliding Window 라고 이야기한다.

맨 위는 버퍼. 맨 아래는 STD를 단순화한 것이다. 메세지가 여러개 지나가고 ACK가 여러개 왔다갔다 하는게 이전의 Stop-and-Wait 과 다른 점이다.

ACK가 다 깨졌을 경우를 나타낸 것이다. 2^2개를 쓸때의 문제점은 0을 재전송하는 것이다. 근데 리시버는 0123을 다 받았기 때문에 샌더가 재전송하는 Frame0를 3 다음 데이터이구나! 라고 생각하고 받는다. 2^2-1 이어야 에러로 재전송한거구나 라고 생각할 수 있다. 통신 속도가 빠를 수록 윈도우 사이즈가 커진다. 윈도우 사이즈가 커질수록 버퍼의 사이즈가 커지므로 잘 계산해서 늘려야한다!

ACK는 뒤에 ACK가 서포트 해주므로 큰의미를 가지고 있지 않는다. ACK 2가 깨지더라도 ACK 3 이 도착했다는 의미는 앞선 프레임까지 모두 잘 받았다는 이야기이다.

프레임 1이 없어졌을 경우. Frame1이 없으므로 Frame 2, 3 에 대한 데이터를 버려버린다. 그럼 당연히 ACK가 없으니 타이머는 터지고 ACK가 없는 Frame1 부터 재전송하기에 문제가 발생할 수 있다.

Selective Repeat Protocol

보내는 프레임에서 문제가 발생하면 그 뒤의 프레임음 모두 재전송해야하기에 버려지는 메세지가 많다. 이를 해결하기 위해서 송신단에서의 윈도우 크기는 2^(m-1)로 계산해야한다. 버퍼의 반 이하의 크기이다.

수신단이 복잡해졌다. 수신단이 버퍼를 여러 개 받을 수 있게 되었기 때문이다. 에러가 나면 비우고 잘받으면 채워 이를 통해 선택적 재전송을 할 수 있다. 수신단이 에러가 난 것만 재전송한다는 뜻이다.

다른 그림과 차이점은 수신단의 버퍼가 커졌다는 것이다. 1개가 아니라 4개가 존재하며 ACK 메세지 위에 NAK가 있다. 메세지가 안왔는데 다음 메세지가 왔거나 메세지가 왔는데 에러가 났다는 의미의 NAK 이다.

Window Size의 이유이다. 수신단에서 자신은 ACK를 보냈으니 버퍼를 다 넘겼고 Frame0이 오자 Frame 3 은 에러가 났고 새로운 Frame0 가 도착했다고 판단한다.

Selective Repeat Protocol의 흐름이다.

DLC Example - HDLC

High-level Data Link Control - bit-oriented protocol. 전화선을 통한 통신이다! I-frame - 앞에서 말한 데이터를 주고 받는 frame. CRC(Cycling Redundancy Check)와 상응하는 것이 FCS(Frame Check Sequence), Header (Address), 패킷의 Seqence num이 들어가는 Control. N(S), N(R) // Sending num, Receiving num 이 들어감. S-frame - Data는 없고 ACK같은 것을 보낼 때, Receiving num 이 들어감. U-frame - 연결 설정할 때 체킹하고 검사하는 것. 유지관리에 필요한 정보들.

연결 설정 및 데이터 송수신과 연결 해제. 에러 검출 및 복구를 위해 대부분 Connection-Oriented. SABM = 연결 요청. UA = 연결 요청에 대한 ACK // DISC = 연결 해제 요청, UA = 해제 ACK

데이터 전송 시 앞이 N(S), 뒤가 N(R) -> 2개의 데이터 전송, (<- N(R) = 2 ) == 두개 잘 보냈으니 다음에는 2번부터 보내고 이제 내가 보낸다. -> 마지막에 보낼 데이터가 없으니 ACK를 하나 만들어서 보내줌.

DLC Example - PPP

Point-to-Point Protocol : 이동통신에서 사용. 인터넷을 사용하는 경우 IP가 잘 돌아가도록 해줌, 사용자가 합법한지 돈을 지불했는지 등등 관리 기능. 에러검출에 대한 기능은 별로없음. 핸드폰으로 인터넷에 연결할 때 Point-to-Point로 줄을 하나 연결한다 프로토콜 필드가 있다? PPP는 상위 계층에 있는 것을 실어 나름. Payload에 넣고 무슨 프로토콜을 사용했는데 Protocol 필드에 명시. 연결은 LCP가. Auth에 대한 것은 PAP를 사용. CHAP: 사용자가 서버에 요청하면 합법성을 판별해줌. 가장 많이 쓰는 것은 IP. IP를 위한 환경은 IPCP.

Dead 상태에서 PPP가 동작을 하게되면 기본적으로 연결에 대한 작업. Carrier 가 발견됐다는 피지컬 레이어가 살아있다는 뜻. 확인 후 연결. 옵션을 주고 받음