CH4 : Network Layer (1)

* 이 글에 관련된 모든 내용은 Computer Networking A Top-Down Approach 7th에서 가져온 내용이다. *

네트워크 레이어

 

---

목적지 IP를 base로 하여 host to host간의 패킷 전송을 담당한다.

 

 

네트워크 레이어에는 두가지 기능이 있다.

 

1. Data plane (데이터 전송 담당)

 - fowarding : 현재 라우터에서 적당한 라우터로 패킷을 어떻게 전송할 것인가?

 - Per-router fucntion : local의 하나의 라우터에서만 작동한다.

 

2. Control plane (전송 제어 담당)

 - routing : source로부터 destination까지 패킷의 route를 어떻게 결정할 것인가?

 - Network-wide function : Data plane과 달리 network상의 경로를 결정해야 하기 때문

 - control plane에는 두가지 approache가 있다.

     1. 전통적인 라우팅 알고리즘

        - 라우터에서 실행된다. 각 라우터에 라우팅 테이블을 가지고 있어 fowarding을 진행한다.

     2. SDN(Software-Defined networking)

       - 원격의 서버에서 실행된다. 즉, data plane은 라우터에서, control plane은 원 격서버에서 작동

 

 

네트워크 레이어에서의 중요한 issue는 네 가지 정도가 있다.

1. Addressing : 주소

2. Routing : 라우팅

3. Fragmentation : 각 네트워크마다 수용할 수 있는 패킷의 길이가 다르기 때문에 조각으로 쪼갠다.

4. Packetization : 상위 계층(Layer 4)에서 온 segment를 encapsulation한다.

 

 

인터넷 네트워크 레이어는 다음과 같은 구조를 띤다.

기본적으로 IP Protocol은 error recovery기능을 지원하지 않기 때문에 error를 reporting해주는 ICMP Protocol이 있다.

 

 

IPv4

---

IPv4는 Internet Protocl version 4이다. 여기선 IP라고 부르겠다. (나중에 IPv6에 대해 조금 다룰 예정)

 

IP는 Layer4에서의 UDP와 비슷하다.

- Datagram delivery : 비연결지향형 서비스를 제공한다.

- Best-effort service : 최선의 서비스를 제공해주려 노력하지만 unreliable한 특성을 갖는다.

     - No error recovery

     - No flow control

     - Lost, out-of order, duplication, or delayed delivery

- 오직 데이터 forwarding만을 담당한다. 위 그림에서 볼 수 있듯이 error reporting은 ICMP가 해주고 라우팅 프로토콜은 OSPF, RIP등의 프로토콜서 해준다.

 

그럼 IP는 할 수 있는게 뭐냐?

거의 없다. 네트워크 구조를 처음 만들 때 전쟁상황 같은 비상시에 어떻게 대처할 지를 많이 고민했다고 한다.

가장 중요한 패킷전송(실질적인 통신)을 담당하는 네트워크 레이어의 IP는 어느 네트워크가 고장나도 또 다른 네트워크에 붙여서 사용이 가능해야 했기 때문에 최대한 간단하고 하는 역할이 없도록 만든 것이다.

 

이러한 이유 때문에 Layer3(네트워크 레이어)는 모든 레이어중에 하는 일이 가장 없다.

그렇다면 그와중에 IP가 무엇을 할 수 있냐?

헤더를 보면 알 수 있다.

 

IPv4 Header Format

 

IPv4의 헤더는 20byte (옵션에 따라 60byte까지 가능)이다.

 

VER : IP의 버전을 나타낸다. IPv4에선 4

HLEN : 헤더의 길이를 나타낸다. 가변의 길이를 갖는 헤더는 무조건 필요.

Service : 거의 안쓴다고 한다. 어떻게 쓸지 많은 고민을 하고 있는데 대부분 local적이고, global하게는 못쓴다고 한다.

Total length : 토탈 길이

Identification, Flags, Fragmentation offset : 모두 framentation을 위해 존재한다.

TTL : Time을 재기 위함이다. 라우터를 지날때마다 1씩 감소하는데 중간 단계에서 0이 되어버리면 그냥 패킷을 버린다.

Protocol : 상위 레이어의 프로토콜을 나타낸다.

Checksum : 체크섬!

Source IP, Destination IP : IPv4에서는 32bit의 IP주소를 이용한다.

 

 

더 자세히 알아보자

Protocol

혼자선 아무것도 할 수 없는 응애 네트워크 레이어의 특성때문에 이를 도와주기 위한 많은 프로토콜들이 존재한다. 

ICMP(에러 체크), OSPF(라우팅)은 위에서 설명했고, IGMP는 멀티캐스트를 담당한다.

 

ICMP, IGMP, OSPF는 모두 네트워크 레이어에 존재하지만 IP를 도와주는 입장이고 페이로드에 들어가는 정보들이기 때문에 실질적으로는 TCP, UDP와 같이 Layer4의 프로토콜 기능을 수행한다.

 

Fragmentation and Reassembly

여러 네트워크가 감당할 수 있는 패킷의 길이가 다르기 때문에 잘게 쪼개는 기능과 합치는 기능이 필요하다.

 

우선 MTU(Maximum Transmission Unit)에 대해 이해해야 한다.

네트워크 레이어에서는 IP datagram을 하위레이어로 보낸다. 

이때 하위레이어에서 헤더와 트레일러의 사이즈는 고정이기 때문에 최대로 사용할 수 있는 길이가 정해지게 된다.

이 길이를 MTU라고 하는데, 따라서 네트워크 레이에에서는 이 MTU보다 작거나 같은 길이의 데이터를 보내야하는 것이다.

 

만약 내가 가지고 있는 IP의 datagram이 MTU보다 크다면 fragmentation을 통해 MTU이하의 크기로 쪼개어 보낸다는 아이디어이다.

 

그런데 위에서 말했듯이 네트워크의 종류마다 이 MTU가 달라질 수 있다는 점이 문제이다.

해결책은 가장 작은 MTU를 찾아 그 사이즈대로 자르면 어느 네트워크에서나 보낼 수 있을 것이다.

이때 가장 작은 MTU를 Path MTU라고 한다.

 

또한 MTU는 네트워크 레이어에서 하위레어어로 보내는 전체 데이터의 길이기 때문에 헤더크기를 포함하고 있다. 

 

그러나 datagram을 쪼개고 또 합치고 하다보면 많은 overhead가 발생할 수 있다.

때문에 IPv6에서는 fragmentation을 지양할 수 있는 헤더정보를 가지고 있다고 한다.

 

Fragmentation을 위해 헤더에서는 다음과 같은 정보를 사용한다고 했다.

 

1. IDENTIFICATION : 데이터그램이 하나씩 추가될 때마다 1씩 증가한다. 즉 잘라진 데이터그램은 unique하게 표시된다.

2. FLAGS : 두가지 bit를 사용한다.

    - DF(Do not Fragment) bit : fragment를 진행하지 말라는 것이다. 이때 MTU보다 현재 datagram크기가 큰데 DF가 활성화 되어있다면 보낼수가 없으므로 ICMP 에러메시지를 보낸다. 이는 Path MTU를 찾을 때 사용가능하다.

    - MF(More Fragment) bit : 마지막 datagram을 알 수 있게 해준다. 1이면 뒤에 더있다, 0이면 끝이다.

3. FRAGMENT OFFSET : 어디에서 합쳐야 할지를 알려준다. 근데 자세히 보면 오프셋을 위한 bit는 13bit인데 total length는 16bit까지 가능하기 때문에 어디서 합쳐져야 할지를 제대로 나타내지 못할 수 있다. (3bit를 FLAGS에게 줘서 그렇다) 때문에 offset*8(FLAGS에게 준 비트 수)이 실제로 합쳐져야 할 위치이다. 
예를 들어 offset이 5라면 40이 실제로 Fragmentation이 일어난 위치라는 것이다.

 

 

이제 fragmentation에 대한 예제를 한번 보자.

4000byte의 데이터그램을 라우터 R1에서 MTU가 1500인 Net2를 통해 전달하려고 한다.

이때의 과정을 한번 살펴보자.

 

First fragment

1. length : MTU가 1500이기 때문에 1500만큼의 길이로 자를 수 있다. 이때 이 datagram에도 역시 헤더가 포함되어 있기 때문에 헤더사이즈 20을 뺀 1480만큼의 데이터가 페이로드에 저장되어 있다.

2. ID : ID는 그 전의 데이터 (4000짜리)의 ID인 x이다.

3. moreflag : 아직 4000짜리의 데이터가 다 오지 못했으므로 1이다.

4. offset : 처음 데이터이므로 0이다.

 

Second fragment

1. length : MTU가 1500이기 때문에 1500만큼의 길이로 자를 수 있다. 이때 이 datagram에도 역시 헤더가 포함되어 있기 때문에 헤더사이즈 20을 뺀 1480만큼의 데이터가 페이로드에 저장되어 있다.

2. ID : ID는 그 전의 데이터 (4000짜리)의 ID인 x이다.

3. moreflag : 아직 4000짜리의 데이터가 다 오지 못했으므로 1이다.

4. offset : 이전까지 (first fragment까지) 페이로드에 올려보낸 데이터는 1480이기 때문에 1480의 위치에서 잘라야 한다. 그러나 위에서 말했듯이 부족한 offset에 할당된 비트수로 인해 offset*8이 실제 데이터가 잘린 위치기 때문에 1480/8인 185가 저장된다.

 

Third fragment

1. length : 지금까지 페이로드에 올려 보낸 데이터는 1480+1480 = 2960이다. 또한 원래 보낼 패킷 길이는 4000인데  여기에는 헤더의 사이즈(20)가 포함되어 있기 때문에 실제 데이터는 3980이다. 때문에 현재 남을 보낼 데이터의 길이는 3980-2960 = 1020이다. 또한 헤더도 붙여서 보내야하기 때문에 총 length는 1040이다.

2. ID : ID는 그 전의 데이터 (4000짜리)의 ID인 x이다.

3. moreflag : 마지막 조각이기 때문에 0으로 한다.

4. offset : 이전까지 (first fragment까지) 페이로드에 올려보낸 데이터는 2960이기 때문에 2960의 위치에서 잘라야 한다. 때문에 2960/8인 370이 저장된다.

 

결과적으로 총 4000짜리의 데이터를 보내기 위해 fragmentation을 진행한 결과 4040의 데이터를 보내는 현상이 생겼다. (2번째와 3번째에서 헤더가 추가된 길이) fragmentation을 많이하는 것은 좋지않다는 증거이다.

 

그렇다면 Reassembly는 언제할까?

보통 두가지 방식이 있다.

1. 한 라우터가 이전 라우터에서 framentation된 패킷들을 받았을 때 바로 합친다.

2. 종착지까지 라우터를 거칠때마다 fragmentation을 진행한 뒤 종착지에서 다 합친다.

 

1번 방식은 효율이 가장 좋겠지만 각 라우터의 부담이 너무 커질 수 있다.

때문에 실제로는 효율이 조금 떨어지더라도 라우터의 부담을 덜어주는 2번방식을 사용한다.

물론 몇가지 문제점은 있다. (비효율적, 중간의 fragment가 로스되면 모두 버려야함, reassembly 타이머 필요 등)

 

항상 모든 것엔 장단점이 있다.