3. Network Layer - 라우터, forwarding, IPv4

![[Network Layer - Figure 7.1 Communication at the network layer.png|center|400]] ## 1. 네트워크 계층 개요 - **네트워크 계층의 역할** - 네트워크 계층에서는 송신 호스트에서 수신 호스트로 세그먼트를 전달함 - sender : 세그먼트를 데이터그램에 캡슐화하여 data link 계층으로 전달 - receiver : 세그먼트를 수신하여 transport 계층으로 전달 - **서비스** 1. **Packetizing, 패킷화** - 네트워크 계층의 가장 중요한 임무 - packetizing = 출발지에서 payload를 네트워크 계층 패킷에 **캡슐화**하고 목적지에서 네트워크 계층 패킷에서 payload를 **디캡슐화**하는 것을 의미함 - payload를 변경하거나 사용하지 않고 출발지에서 목적지까지 운반해야 함 2. **Routing, 라우팅** - 또 다른 중요한 임무 중 하나인 routing과 forwarding - **forwarding** : 데이터그램을 라우터의 입력 포트에서 적절한 출력 포트로 이동시키는 것 - **routing** : source에서 목적지까지 데이터그램이 라우터 간 이동하는 경로를 설정하는 것 3. **Error Control** - error control을 네트워크 계층에서 구현할 수 있지만, 인터넷의 네트워크 계층 설계자들은 이를 무시함 - 각 라우터에서 패킷이 분할될 수 있기 때문에 이 계층에서 오류를 검사하는 건 비효율적임 - 헤더가 손상되는 경우를 다루기 위해 datagram에 checksum 필드를 추가했지만, 전체 datagram에 대한 checksum이 아님 4. **Flow Control** - 송신자가 수신자를 압도하지 않도록 송신할 수 있는 데이터의 양을 규제하는 것 - 송신 측이 수신 측이 처리할 수 있는 데이터의 양보다 더 빠르게 데이터를 전송하면 버퍼 오버플로우 등의 문제가 생길 수 있음 - 데이터의 흐름을 제어하기 위해 수신자는 송신자에게 현재 수신 상황을 알리는 피드백을 보내야 함 5. **Congestion Control** - congestion = 네트워크의 특정 영역에 너무 많은 datagram이 몰려 통신 장애가 발생한 상황 - 송신 측에서 보내는 datagram의 수가 네트워크나 라우터의 용량을 초과하면 발생할 수 있음 - flow control과 구분됨. 이게 좀 더 거시적인 개념 6. **Quality of Service(QoS)**, **서비스 품질** - 인터넷이 멀티미디어 통신(특히 실시간 오디오 및 비디오 통신)과 같은 새로운 응용 프로그램을 가능하게 하면서, 통신의 서비스 품질(QoS)이 점점 더 중요해지고 있음 - 네트워크 계층을 그대로 두기 위해, 이러한 QoS 제공은 대부분 상위 계층에서 구현됨 7. **Security** - 인터넷이 처음 설계될 당시에는 사용자 수가 적었기 때문에 보안은 문제가 되지 않았기 때문에 초기 네트워크 계층은 보안 조항 없이 설계됨 → 그러나 오늘날 보안은 큰 문제임 - connectionless 네트워크 계층에 보안을 제공하려면, connectionless 서비스를 connection-oriented 서비스로 변경하는 또 다른 가상 레벨이 필요함 - **네트워크 계층 구분** - **data plane**: local한 라우터 내부 기능, forwarding 방법을 결정함 - 전통적인 destination-based 포워딩(목적지 IP 주소만으로 포워딩)과 generalized 포워딩(데이터그램 헤더 필드 값들을 기반으로 포워딩) 방식이 있음 - **control plane**: network-wide logic, routing 방법을 결정함 - 전통적인 라우팅 알고리즘(라우터 내부에 각자의 라우팅 알고리즘 구현)과 SDN(원격 서버에서 forwarding table을 라우터에 설치) 방식이 있음 ## 2. data plane 개요 ![[Network Layer - high-level view of generic router architecture.png|center|550]] **라우터** - 라우터를 통과하는 모든 IP 데이터그램의 헤더 필드를 검사함 - 입력 포트에서 출력 포트로 데이터그램을 이동시켜 엔드-투-엔드 경로를 따라 데이터그램을 전송함 **input port function** ![[Network Layer - Input port functions.png|center|550]] - **분산 스위칭** - 헤더 필드 값과 입력 포트 메모리의 forwarding table을 기반으로 출력 포트를 조회함 - 최고 전송 속도(line speed)로 인풋 포트 프로세싱 과정을 완료하는 게 목표 - forwarding 속도보다 데이터그램이 빨리 도착하는 경우 queuing이 발생함 - **destination-based forwarding** - 라우터가 수신한 데이터그램의 **목적지 IP 주소**를 확인한 후, 이를 기준으로 forwarding table을 조회하여 적절한 출력 포트를 결정함 - 가장 일반적이고 널리 사용되는 방식 - **longest prefix matching**을 활용함 - 주어진 목적지 IP 주소에 대해 forwarding table을 검색할 때, 목적지 주소와 일치하는 가장 긴 주소 prefix를 선택하는 방법 - 빠른 매칭을 위해 주로 **TCAM**(ternary content addressable memories)을 사용함 - TCAM에 주소를 알려주면, 테이블 크기에 상관없이 한 클록 사이클 내에 주소를 검색할 수 있음 ![[Network Layer - Flow table abstraction.png|center|500]] - **generalized forwarding, SDN** - Software-Defined Networking - 각 router는 forwarding table을 가지고 있음 - match plus action 추상화 : 도착하는 패킷의 비트를 매칭해서 행동을 취함 - 기존 목적지 기반 포워딩과 달리 **여러 헤더 필드를 통해 행동을 결정할 수 있음** - 패킷 드롭, 복사, 수정, 기록 등 다양한 행동 가능 - **flow table abstraction** - flow는 링크 계층, 네트워크 계층, 전송 계층의 헤더 필드 값에 의해 정의됨 - 간단한 패킷 처리 규칙을 통해 처리함 - 매치 - 패킷 헤더 필드의 패턴 값과 매칭, 액션 - 매칭된 패킷에 대해 드롭, 포워드, 수정, 컨트롤러에 전송 등의 행동을 취함, priority - 겹치는 패턴 간 우선순위를 설정함, counter - 바이트와 패킷의 수를 셈 - **OpenFlow** - 네트워크 장비(스위치, 라우터 등)가 어떻게 패킷을 처리할지 소프트웨어로 정의할 수 있게 해주는 기술 - **OpenFlow를 사용하면 네트워크 장비가 소프트웨어 설계에 따라 라우터, 스위치, 방화벽 등으로 동작할 수 있음** - **네트워크 장비의 동작이 하드웨어가 아닌 소프트웨어에 의해 결정됨** - OpenFlow에서 네트워크 장비는 플로우 테이블을 사용함 - 네트워크의 동작이 정적인 설정에 의해 고정되는 것이 아니라, 필요에 따라 소프트웨어적으로 동적으로변경될 수 있음 → 네트워크의 유연성, 관리 효율성, 보안성 등이 크게 향상됨 - P4 같은 네트워크 장비 프로그래밍 language도 있음 **switching fabric** - 네트워크 스위치 내부에서 패킷이나 데이터그램을 입력 포트에서 적절한 출력 포트로 전달하는 내부 구조 - switching rate : 패킷이 입력에서 출력으로 전송되는 속도 - N개의 입력이 있을 때, switching rate이 input/ouput line rate의 N배가 되면 이상적인 속도 ![[Network Layer - three major types of switching fabrics.png]] 1. **memory를 통한 스위칭** - 초기 라우터 형태 : CPU의 직접적인 제어 하에 스위칭 수행 - 패킷을 시스템의 메모리에 복사 - 메모리 대역폭에 의해 속도가 제한됨 (데이터그램 당 2번의 버스 교차가 필요함) 2. **bus를 통한 스위칭** - 입력 포트 메모리에서 출력 포트 메모리로 공유 버스를 이용해 데이터그램 전송 - 공유되는 라인이라 한 순간에 한 놈만 사용 가능함 - 버스 대역폭에 의해 속도가 제한됨 (bus contention) ![[Network Layer - Switching via interconnection network.png|center|400]] 3. **interconnection network를 이용한 스위칭** - Crossbar, Clos networks 등등 : 멀티프로레서에서 프로세서를 연결하기 위해 처음 개발된 네트워크 - 병렬 처리와 멀티스테이지 구조를 활용해 고속 데이터 전송이 가능함 - multistage switch : 작은 스위치의 여러 단계로 구성된 nxn 스위치 (cross-point를 활용한 모듈) - 병렬 처리 : 입력 시 긴 데이터그램을 쪼개서 스위칭 과정을 거친 후 출력에서 재조립함 → 빠름 **Buffer Management** ![[Network Layer - Head-of-the-Line (HOL) blocking.png|center|500]] - **input port queuing** - 스위치 패브릭 속도가 각 입력 포트에서 들어오는 데이터 속도의 합보다 느린 경우, 입력 큐에서 큐잉 발생 가능 - 입력 버퍼 오버플로우로 인한 queuing delay 및 loss 발생 - **Head-of-the-Line(HOL) blocking** : 큐의 맨 앞에 있는 데이터그램이 나머지 데이터그램의 이동을 방해함 - 그림에서 동시에 한 목적지로 가는 게 허용되지 않는다면, 빨강 패킷 경쟁에 초록 패킷은 충돌이 없으나 기다려야 함 ![[Network Layer - Output port queuing 1.png|center|400]] - **output port queuing** - 데이터그램이 스위치 패브릭을 통해 출력 포트에 도착하는 속도가 출력 포트의 전송 속도보다 빠를 때 발생 - 나가는 속도보다 들어오는 속도가 빨라서 생기는 문제 - 출력 버퍼 오버플로우로 인한 queuing delay 및 loss 발생 - **버퍼링의 적정량** - 네트워크 장치에서 버퍼링은 일시적인 데이터 저장을 통해 패킷 손실을 방지하고 네트워크 성능을 최적화하는 데 중요함 - 그러나 버퍼링이 너무 많으면 지연이 발생할 수 있어 적정량을 유지하는 것이 중요함 - 최근 권장 사항 : N개의 플로우가 있을 때, 버퍼링은 $\frac{RTT \times C}{\sqrt{N}}$ 와 같아야 함 - **버퍼 관리** - 사용 가능한 버퍼가 없을 경우 어떤 데이터그램을 드롭할 지 정책이 필요함 - **drop** : 버퍼가 가득찼을 때 어떤 패킷을 드롭할지 결정함 - tail drop : 들어오는 패킷을 드롭함 - priority : 우선순위가 낮은 패킷부터 드롭함 - random : 아무 패킷이나 드롭함 - **marking** : congestion 상황을 알리기 위해 특정 패킷을 표시하는 과정, congestion이 발생할 가능성이 있을 때 처음에는 패킷을 드롭하지 않고 마킹하여 이를 알리지만 congestion이 심화되면 패킷을 드롭함 - ECN : IP 헤더에 congestion 상태를 알리는 비트를 설정해서 송신자와 수신자에게 정보를 전달함 - RED : congestion이 발생하기 전에 임의의 패킷을 선택해서 드롭하거나 마킹함 - **스케줄링 정책** - 스케줄링 정책을 통해 버퍼에 있는 데이터그램에 우선순위를 두고 먼저 내보낼 데이터그램을 결정함 - **FCFS** : 도착 순서대로 전송함 (=FIFO) - **priority** : 도착하는 트래픽을 헤더 필드를 사용해 클래스로 분류하고 큐에 저장함 - 버퍼링된 패킷 중 가장 높은 우선순위 큐에서 패킷을 전송함 - 우선순위 클래스 내에서는 FCFS 방식으로 처리 - 우선순위가 높은 패킷이 계속 들어오면 낮은 패킷은 계속 기다려야 함 (=starvation 발생) - **round robin** : 도착하는 트래픽을 헤더 필드를 사용해 클래스로 분류하고 큐에 저장함 - 서버가 클래스 큐를 순환하며, 각 클래스에서 하나의 완전한 패킷을 순서대로 전송함 - **weighted fair queuing** : generalized 라운드 로빈 방식 - 각 클래스 $i$는 가중치 $w_i$를 가지며, 각 주기마다 가중치에 비례한 서비스량을 할당받음 - $\frac{w_i}{\sum_j w_j}$ 의 비율로 서비스 제공 - 트래픽 클래스별로 가중치를 부여해서 공정하게 대역폭을 할당함 - 각 트래픽 클래스는 최소한의 대역폭을 보장받음 - 이는 네트워크가 혼잡하더라도 각 클래스가 일정 수준의 서비스를 유지할 수 있도록 함 > **Network Neutrality (네트워크 중립성)** > - ISP가 자원을 어떻게 공유/할당해야 하는지에 관한 것 > - 패킷 스케줄링, 버퍼 관리가 주요 메커니즘 > - 각국마다 네트워크 중립성에 대한 접근 방식이 다름 > - 합법적인 콘텐츠, 애플리케이션 blocking 금지, 속도 저하 금지, 유료 우선순위 지정 금지 ## 3. IPv4 - 인터넷 네트워크 계층에는 여러 버전이 있었지만, 현재는 IPv4와 IPv6만 널리 사용되고 있음 - IPv4 주소가 거의 고갈된 상태지만, 여전히 일부 지역에서는 사용되고 있고 IPv6의 기초가 되기 때문에 2개 다 사용중임 ### 3-1. Addressing - TCP/IP 프로토콜의 IP layer(=network layer)에서 각 장치의 인터넷 연결을 식별할 때 사용하는 identifier를 **IP address** 혹은 Internet address 라고 부름 - IPv4 주소는 32비트 주소로, 호스트나 라우터의 인터넷 연결을 보편적이고 고유하게 정의함 - 디바이스마다 할당되는 게 아니고 **연결마다 IP 주소가 할당됨** - 장치가 다른 네트워크로 이동하면 IP 주소가 변경될 수 있기 때문 - **인터페이스(interface)** : 호스트/라우터와 물리적 링크 간의 연결 - 라우터는 일반적으로 여러 인터페이스를 가지고, 호스트는 하나 또는 두 개의 인터페이스를 가짐 **Address Space, 주소 공간** - **프로토콜이 사용하는 전체 주소의 수** - 프로토콜이 주소를 정의하는 데 b 비트를 사용하면, 주소 공간은 2^b (0,1 이진수의 값을 가지니까) - IPv4는 **32비트 주소 체계**를 사용함 - 즉 address space가 $2^{32}$ = $4,294,967,296$(약 42억)임 - 제약이 없다면 42억 개 이상의 장치가 인터넷에 연결될 수 있음 **Notation, 표기법** ![[Network Layer - Figure 7.4 Three different notations in IPv4 addressing.png|center|400]] - 3가지 표현 방법이 있음 - binary notation (base 2) - dotted-decimal notation (base 256) : 가장 많이 쓰임 - hexadecimal notation (base 16) **주소 체계의 계층 구조** ![[Network Layer - Figure 7.5 Hierarchy in addressing.png|center|400]] - **서브넷** : 중간에 라우터를 거치지 않고 물리적으로 서로 도달할 수 있는 장치 인터페이스 - **IP 주소의 구조** : subnet(같은 서브넷에 있는 장치들이 공통으로 가지는 상위 비트) + host(나머지 하위 비트) - 32비트 IPv4 주소는 계층적 구조를 가지고 있으며, 두 부분으로 나뉨 - 네트워크를 정의하는 **prefix** - 노드를 정의하는 **suffix** **주소 체계 1. Classful Addressing** ![[Network Layer - Figure 7.6 Occupation of the address space in classful addressing.png]] - 인터넷 초기에는 **고정 길이의 prefix**를 사용해서 IPv4 주소를 설계했음 - 소규모 및 대규모 네트워크를 수용하기 위해 하나의 fixed-length prefix 대신 세 가지 fixed-length prefix(n = 8, n = 16, n = 24)를 설계함 - 전체 주소 공간이 5개의 클래스(A, B, C, D, E)로 나뉘어짐 **주소 체계 2. Classless Addressing** ![[Network Layer - Figure 7.8 Slash notation (CIDR).png|center|500]] - 인터넷의 성장으로 더 큰 주소 공간이 필요해짐 - 장기적인 해결책은 더 큰 주소 공간을 가진 IPv6지만, IPv4 주소 내에서 해결하기 위한 단기적인 해결책은 Classless Addressing임 - 이는 동일한 주소 공간을 사용하지만, 각 조직에 공평한 분배를 제공하기 위해 **주소 분배 방식을 변경함** - **CIDR**(classless interdomain routing)은 **슬래시(/)를 사용하여 prefix 길이를 지정함** ![[Network Layer - Example 7.1.png|center|500]] - **Example 7.1** - Classless Address를 보고 해당 네트워크의 주소 수와 첫 주소·마지막 주소 구하기 - 주소 수 구하기 : $2^\text{32-prefix} = 2^5 = 32$개 - 첫 주소 구하기 : prefix 제외한 suffix 부분 bit를 다 0으로 바꾸기 - 마지막 주소 구하기 : prefix 제외한 suffix 부분 bit를 다 1로 바꾸기 **Address Mask, 주소 마스크** - address mask = n개의 왼쪽 비트가 1로 설정되고 나머지 비트(32 - n)가 0으로 설정된 32비트 숫자 - prefix는 다 1로, suffix는 다 0으로 설정하면 됨 - 주소 블록에서 첫 번째 및 마지막 주소를 찾는 또 다른 방법임 - address mask는 $(2^{32 - n} - 1)$의 보수이기 때문에 컴퓨터가 쉽게 찾을 수 있음 - address mask를 사용하는 방법 1. 블록 내 주소 수 ($N$): $N = \text{NOT(Mask)} + 1lt;/mark> - mask에 NOT 연산하고 + 1 2. 블록의 첫 번째 주소: $(\text{Any address in the block}) \text{ AND (Mask)}lt;/mark> - 임의의 주소랑 mask AND 연산 3. 블록의 마지막 주소: $(\text{Any address in the block}) \text{ OR } [\text{NOT (Mask)}]lt;/mark> - mask에 NOT 연산하고 임의의 주소랑 OR 연산 ![[Network Layer - Example 7.2.png|center|500]] - **Example 7.2** - mask를 활용해서 주소 수와 첫 주소·마지막 주소 구하기 ![[Network Layer - Example 7.3.png|center|500]] - **Example 7.3** - prefix 길이에 따라 첫 주소·마지막 주소 구하기 - classless addressing 체계에서는 단일 IP 주소만으로 해당 주소가 속한 블록을 정확히 알 수 없음 - 블록의 크기(prefix 길이)에 따라 여러 가능성이 존재함 - 예를 들어, 주소 230.8.24.56은 여러 블록에 속할 수 있음 - 230.0.0.0/8(230로 시작하는 모든 주소 포함), 230.8.0.0/16(230.8로 시작하는 모든 주소 포함), 230.8.24.0/24(230.8.24로 시작하는 모든 주소 포함), 230.8.24.56/32(230.8.24.56 하나의 주소만 포함) - address (230.8.24.56) = 1110 0110 0000 1000 0001 1000 0011 1000 **Network Address, 네트워크 주소** ![[Network Layer - Figure 7.9 Network address.png|center|500]] - 첫 번째 주소인 네트워크 주소는 특히 중요함 - 패킷을 목적지 네트워크로 라우팅하는 데 사용됨 **호스트가 IP 주소를 얻는 방법** - **autoconfiguration** : 네트워크에 연결된 장치가 스스로 IP 주소를 설정하는 방법 - **IPv4** : 네트워크 관리자에 의해 수동으로 설정되거나 동적 호스트 구성 프로토콜(DHCP)에 의해 자동으로 설정됨 - **DHCP (Dynamic Host Configuration Protocol)**을 통해 네트워크 서버에서 동적으로 주소를 얻음 - 호스트가 네트워크에 “가입”할 때 네트워크 서버에서 동적으로 IP 주소를 얻음 - 사용 중인 주소를 갱신할 수 있고, 연결된 동안에만 주소를 보유함으로써 주소 재사용이 가능하고, 네트워크에 가입하거나 떠나는 모바일 사용자를 지원함 - **DHCP 순서** 1. DHCP 발견 메시지 브로드캐스트 (선택 사항): 호스트가 네트워크에 자신의 존재를 알림 2. DHCP 제안 메시지 응답 (선택 사항): DHCP 서버가 IP 주소를 제안 3. DHCP 요청 메시지: 호스트가 IP 주소를 요청 4. DHCP 승인 메시지: DHCP 서버가 IP 주소를 할당 - DHCP는 서브넷에서 할당된 IP 주소 외에도 클라이언트의 첫 번째 홉 라우터의 주소, DNS 서버의 이름과 IP 주소, 네트워크 마스크 등의 정보를 반환할 수 있음 **Block Allocation, 블록 할당** - 블록 할당의 궁극적인 책임은 ICANN이라는 글로벌 기관에 있음 - 그러나 ICANN은 일반 인터넷 사용자에게 주소를 할당하지 않음 - 5개의 지역 레지스트리(RR) IP 주소를 할당하고, 지역 레지스트리는 각 지역의 ISP(Internet Service Providers)에게 대형 주소 블록을 할당함 - **요청된 주소 수(N)은 $n$이 정수 값을 가지기 위해 2의 거듭제곱이어야 함** - log 값 계산을 위해 N이 $2^n$ 형태여야 함 (남는 건 안 씀) - e.g. 건물에 IP 주소가 필요한 기기를 100개 신청하면, 128개를 할당하고 28개는 안 씀 - 요청된 블록은 주소 공간 내에 연속적으로 쭉 사용 가능한 주소가 있는 곳에 할당되어야 함 - 블록의 첫 번째 주소를 선택할 때 제한이 있음 - 첫 번째 주소는 블록 내의 주소 수로 나누어 떨어져야 함 - 첫 번째 주소가 prefix 뒤에 (32 - n)개의 0이 이어진 형태여야 하기 때문 - $\text{First address} = (\text{prefix in decimal}) \times 2^{32 - n} = (\text{prefix in decimal}) \times N$ - ISP는 이러한 주소 블록을 이용해 자체 네트워크와 고객 네트워크에 IP 주소를 할당함 ![[Network Layer - Example 7.4.png|center|500]] - **Example 7.4** - 블록 할당하고 첫번째 주소 찾기 - ISP가 1000개 주소 만큼의 블록을 요청하면 2의 n승을 만족하기 위해 1024개를 할당함 - suffix가 1024 = $2^{10}$ 이니까 prefix(네트워크 주소)는 $32 - 10 = 22$ 비트까지임 - 18.14.12.0/22 라는 가능한 블록이 ISP에 주어졌을 때 - 첫번째 주소는 suffix 부분을 0으로 모두 채운 302,910,464임 **(표현법 주의)** - 18.14.12.0 을 2진수로 변환하면 18 → 0001 0010, 14 → 0000 1110, 12 → 0000 1100, 0 → 0000 0000 - 2진수로 변환한 다음, suffix 부분은 0으로 설정함 ![[Network Layer - Example 7.5-1.png|center|500]] ![[Network Layer - Example 7.5-2.png|center|500]] ![[Network Layer - Example 7.5-3.png|center|500]] - **Example 7.5** - 3개의 subblock으로 나누는데 각 요청한 할당 IP 주소 수가 다름 (10, 60, 120) - prefix가 24비트 까지니까 해당 블록에는 $2^{32-24} = 2^8 = 256$ 개의 주소가 있음 - 첫 주소는 주어졌으니까, 마지막 주소는 suffix를 1로 채우면 나옴 - **제일 크게 요청한 애부터 할당해주면 됨** - 120 - 120을 요청했으니까 2의 거듭제곱에 맞게 128개를 할당해주면 됨 ($2^7$) - 이 경우 prefix는 $2^{25}$ , 즉 25 비트까지 prefix임 - 이때 첫 주소, 마지막 주소 구하면 됨 - 60 - 60을 요청했으니까 2의 거듭제곱에 맞게 64를 할당해주면 됨 ($2^6$) - 이 경우 26비트까지 prefix임 - 이때 첫 주소, 마지막 주소 구하면 됨 - 10 - 마찬가지로 2의 거듭제곱에 맞게 16 할당하고 나머지 연산은 같음 - **이 경우 208개의 주소를 사용하고 48개의 주소는 reserve 상태로 남음** **Address Aggregation, 주소 집계** - CIDR 전략의 장점 중 하나(= address summarization, route summarization) - 주소 블록이 결합되어 더 큰 블록을 생성할 때, 라우팅은 더 큰 블록의 prefix에 따라 수행될 수 있음 - ICANN은 ISP에 대형 주소 블록을 할당함 - 각 ISP는 할당된 블록을 더 작은 서브 블록으로 나누어 고객에게 서브 블록을 할당함 ![[Network Layer - Example 7.6.png|center|500]] - **Example 7.6** - 그림 7.11은 ISP가 네 개의 작은 주소 블록을 네 개의 조직에 할당하는 방법을 보여주고 있음 - ISP는 이 네 개의 블록을 하나의 큰 블록으로 결합하고, 더 큰 블록을 전 세계에 공시함 - 더 큰 블록을 대상으로 하는 패킷은 ISP로 보내지며, ISP는 이를 적절한 조직으로 전달함 - 예를 들어, 네 개의 작은 주소 블록이 각각 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24라고 하면, ISP는 이를 하나의 큰 주소 블록인 192.168.0.0/22로 합쳐서 광고할 수 있음 - 외국에서 오는 모든 소포는 먼저 수도로 보내지고, 그 다음에 해당 목적지로 배분되는 것과 비슷함 ### 3-2. 여러 프로토콜 **네트워크 계층의 프로토콜** ![[Network Layer - Main and Auxiliary Protocols.png|center|400]] - 메인 프로토콜 - **IPv4**: 패킷화, 포워딩, 패킷 전달을 담당함 - 보조 프로토콜 - **ICMPv4:** IPv4가 전달 중 발생할 수 있는 일부 오류를 처리하는 데 도움을 줌, error control - **IGMP:** IPv4가 멀티캐스팅을 수행하는 데 도움을 줌 - **ARP:** IP - MAC 주소 매핑에 사용됨 #### IP **Datagram 포맷 (헤더 필드)** ![[Network Layer - Figure 7.13 IP datagram.png|center|500]] ![[Network Layer - Figure 7.13 IP datagram protocol.png|center|500]] - **VER (Version):** 4-bit 버전 정보 필드로, IPv4 프로토콜 버전(4가지)을 정의함 - **HLEN (Header Length):** 4-bit 헤더 길이 필드로, 헤더의 총 길이를 4-byte 단위로 정의함 - **Service Type:** 서비스 유형 필드로, 1990년대 후반에 IETF가 이 필드를 DiffServ를 제공하도록 재정의하여, 애플리케이션을 우선 순위에 따라 다른 클래스로 나누는 데 사용함 - **Total Length:** 16-bit 필드로, IP 데이터그램의 전체 길이(헤더 + 데이터)를 byte 단위로 정의함 - $\text{Length of data} = \text{Toal length} - \text{(HLEN)} \times 4$ - **Identification, Flags, Fragmentation Offset:** 이 세 필드는 데이터그램의 크기가 하위 네트워크에서 전송할 수 있는 크기보다 클 때 IP 데이터그램의 fragmentation과 관련있음 - **Time-to-Live (TTL):** 데이터그램이 인터넷에서 순환하며 목적지에 도달하지 못할 때, 데이터그램이 방문하는 최대 hop(라우터) 수를 제어함. 각 라우터는 이 값을 1씩 감소시키며, 값이 0이 되면 데이터그램을 폐기함 - 네트워크에 데이터그램이 무한히 돌아다니는 일을 방지하고자 하는 값 - **Protocol:** 데이터그램이 UDP 또는 TCP와 같은 전송 계층 프로토콜의 패킷을 carry 할 수 있음. IP 서비스를 사용하는 다른 프로토콜의 패킷도 전송할 수 있음. 인터넷 당국은 IP 서비스를 사용하는 모든 프로토콜에 고유의 8-bits 번호를 부여하고, payload가 출발지 IP에서 데이터그램에 캡슐화될 때 해당 프로토콜 번호가 이 필드에 삽입됨 - **Header Checksum:** IP는 신뢰할 수 있는 프로토콜이 아니므로 데이터그램이 전송 중 손상되었는지 확인하지 않고, payload의 오류 검사를 payload를 소유한 프로토콜(예: UDP 또는 TCP)에 맡김. heder checksum 필드는 payload가 아닌 헤더만 검사함 - **Source and Destination Address:** 32-bits 출발지 및 목적지 주소 필드로, 각각 출발지와 목적지의 IP 주소를 정의함. 목적지 IP 주소는 DNS에 의해 제공됨 - **Options:** 추가적인 옵션 필드 - **Payload:** 전송되는 실제 데이터 ![[Network Layer - Example 7.7.png|center|500]] - **Example 7.7** - packet을 버리는 이유 - 헤더 길이가 최소 길이인 20보다 작기 때문에 패킷이 손상되었다고 간주하고 해당 패킷은 버림 - 헤더 길이는 4 byte 단위니까 2에 4를 곱했음 ![[Network Layer - Example 7.8.png|center|500]] - **Example 7.8** - 헤더 길이가 주어졌을 때 Option 필드의 크기는? - 헤더 길이 32바이트에서 첫 20바이트는 base 헤더이기 때문에, 나머지 12 바이트가 옵션임 ![[Network Layer - Example 7.9.png|center|500]] - **Example 7.9** - 헤더 길이와 전체 길이가 주어졌을 때 payload의 길이는? - HLEN = 5면 헤더 길이는 $5 \times 4 = 20$ bytes - 전체 길이는 40 bytes (16진수 계산 주의) - 따라서 payload는 $40 - 20 = 20$ bytes ![[Network Layer - Example 7.10.png|center|500]] - **Example 7.10** - 주소보고 남은 hop 수 찾기 (=TTL 필드) + 프로토콜 종류 찾기 - 헤더의 각 필드 비트 수를 잘 기억해야 함 - TTL 필드의 값은 $(01)_{16}$ 즉, 1번의 hop만 남음 - 프로토콜 필드의 값은 $(02)_{16}$ 즉, IGMP ![[Network Layer - Example 7.11.png|center|500]] - **Example 7.11** - IPv4 헤더에서 옵션이 없는 경우 checksum 계산 - 헤더는 16비트 섹션으로 나누어져 있음 - 4, 5, 0 - 28 - 49,153 (패킷 ID) - 0, 0 - 4, 17 - 0, 0 - 10.12.14.5 (출발지 IP 주소) - 12.6.7.9 (목적지 IP 주소) - **모든 섹션을 더한 후 가장 왼쪽 자릿수를 래핑하여 합산한 후, 합산 결과를 보수(complement)하여 checksum 필드에 삽입하면 됨** - 표에 나와있는 각 섹션을 16진수로 표현하면 표와 같이 정리됨 - 4500 ~ 0709 - 각 섹션의 16진수를 더하는데, 이 때 발생하는 carry over은 합산 후에 처리됨 - wrapped sum으로 carry over 처리 - 합산 결과 1344E에서 왼쪽 자릿수를 더하면 됨 - 1344E → 1 + 344E = 344F - 보수 구하기 - 보수는 전체 1비트 값을 0으로 만들어야 하므로, FFFF에서 합산된 값을 빼야 함 (NOT 연산) - NOT(344F) = **CBB0** **Fragmentation** - 데이터그램은 다양한 네트워크를 통해 이동할 수 있음 - 각 라우터는 수신된 프레임에서 IP 데이터그램을 디캡슐화하고, 이를 처리한 후 다른 프레임에 캡슐화 함. - 수신된 프레임의 형식과 크기는 프레임이 이동한 물리적 네트워크의 프로토콜에 따라 다름 - 송신되는 프레임의 형식과 크기도 프레임이 이동할 물리적 네트워크의 프로토콜에 따라 다름 **Maximum Transfer Unit (MTU)** > fragmentation이 필요한 이유 ![[Network Layer - Figure 7.16 Maximum transfer unit (MTU).png|center|500]] - 각 링크 계층 프로토콜은 고유한 프레임 포맷을 가지고 있음 - 각 포맷의 특징 중 하나는캡슐화 할 수 있는 payload의 최대 크기임 - **데이터그램이 프레임에 캡슐화될 때, 데이터그램의 총 크기는 최대 크기보다 작아야 함** - MTU 값은 physical network protocol에 따라 다름 - LAN에서는 보통 1500바이트이며, WAN에서는 LAN보다 크거나 작을 수 있음) - IP 프로토콜을 물리적인 네트워크로부터 독립시키기 위해, IP 데이터그램의 최대 길이는 65,535바이트로 설정됨 - physical 계층이 더 작은 MTU를 사용하면 데이터그램은 fragmentation 되어야 함 - 데이터그램이 쪼개지면, **각 조각은 자체 헤더를 가지며 대부분의 필드는 그대로고 일부가 변경됨** - 데이터그램이 더 작은 MTU를 가진 네트워크를 만나면 조각이 또 쪼개질 수도 있음 - 데이터그램은 최종 목적지에 도달하기 전에 여러 번 fragmentation 될 수 있음 - 변하는 필드 : **flags, fragmentation offset, total length, checksum** - 나머지는 그대로임 - checksum은 헤더가 바뀌니까 당연히 새로 계산해야 함 - 데이터그램의 **재조립은 목적지 호스트에서만 이루어지고,** fragmentation은 출발지 호스트나 경로상의 어느 라우터에서든 이루어질 수 있음 - 쪼개진 조각이 어떤 경로를 거칠지는 제어하거나 보장할 수 없음 **Fragmentation과 관련된 필드 3가지 (Identification, Flags, Fragmentation Offset)** 1. **identification** (16-bit) - 이 필드는 source 호스트에서 생성된 데이터그램을 식별함 - IP 프로토콜은 counter의 현재 값을 identification 필드에 복사하고, counter를 1씩 증가시켜 고유성( uniqueness)을 보장함 - 데이터그램이 쪼개질 때, identification 필드의 값은 모든 조각에 복사됨 - 동일한 identification 값을 가진 조각들은 하나의 데이터그램으로 재조립되어야 함 2. **flags** (3-bit) - 해당 필드는 3가지 flag를 정의함 - **첫 번째 비트** : reserved(사용되지 않음) - **두 번째 비트 (D bit, Do Not Fragment bit)** - 값이 1이면 데이터그램을 쪼갤 수 없음 - 데이터그램이 어떤 물리적 네트워크를 통해서도 전달될 수 없으면, 데이터그램을 폐기하고 ICMP 오류 메시지를 source 호스트에 보냄 - 값이 0이면 필요시 데이터그램을 쪼갤 수 있음 - **세 번째 비트 (M bit, More Fragment bit)** - 값이 1이면 데이터그램이 마지막 조각이 아님을 의미함 - 이후에 더 많은 조각이 있음을 나타냄 - 값이 0이면 이것이 마지막 또는 유일한 조각임을 의미함 ![[Network Layer - Figure 7.17 Fragmentation example.png|center|500]] 3. **fragmentation offset** (13-bit) - 해당 필드는 **데이터그램 내에서** 이 조각의 상대적인 위치를 나타냄 - 기존 데이터그램에서 **8 bytes 단위로 측정됨** - **조각의 첫 시작 바이트 / 8 = offset 값** - 13-bit 크기의 이 필드는 8191 바이트보다 큰 시퀀스는 나타낼 수 없음 - Figure 7.17 을 참고하면 4000 bytes의 데이터그램이 3개의 조각으로 나뉨 - 첫 번째 조각은 바이트 0부터 1399까지 포함하므로, 이 데이터그램의 오프셋은 0000/8 = 0 임 - 두 번째 조각은 바이트 1400부터 2799까지 포함하므로, 이 단편의 오프셋 값은 1400/8 = 175 임 - 세 번째 조각은 바이트 2800부터 3999까지 포함하므로, 이 단편의 오프셋 값은 2800/8 = 350 임 **조각의 fragmentation 및 재조립에 헤더 필드를 활용하는 방법** - 조각들은 서버에서 재조립됨 - **모든 조각이 identification 필드가 동일함** - **flag 필드의 M bit는 마지막 조각을 제외하고는 다 1로 설정됨** - 조각이 다시 쪼개지는 경우 - offset 필드는 항상 **원래 데이터그램에 대한 상대적인 위치**를 나타냄 - 두 번째 조각이 800 바이트와 600 바이트의 두 조각으로 다시 나뉘더라도, offset은 원래 데이터에 대한 상대적인 위치를 나타냄 - 재조립 방법 - 첫 번째 조각의 offset 필드 값은 0 - 첫 번째 조각의 길이를 8로 나누면 두 번째 조각의 offset 값임 - 조각의 길이 = 헤더 20 빼고 payload 길이만 고려함 - 첫 번째와 두 번째 조각의 총 길이를 8로 나누면 세 번째 조각의 offset 값임 - 이 과정을 반복함. 마지막 조각의 M bit는 0으로 설정됨 ![[Network Layer - Figure 7.18 Detailed fragmentation example.png]] ![[Network Layer - Example 7.12.png|center|500]] - **Example 7.12** - M bit가 0이면, 마지막이거나 유일한 패킷임 - fragmentation 여부는 알 수 없음 ![[Network Layer - Example 7.13.png|center|500]] - **Example 7.13** - M bit가 1이면, fragmentation 되었고 아직 남은 조각이 있다는 걸 의미함 - 첫번째인지 여부는 알 수 없음 - 그건 offset 값 봐야함 ![[Network Layer - Example 7.14.png|center|500]] - **Example 7.14** - M bit가 1이고, offset이 0이면 첫번째 조각임 ![[Network Layer - Example 7.15.png|center|500]] - **Example 7.15** - offset이 100일 때 첫번째 바이트 숫자 구하기 - 첫번째 바이트는 offset * 8 bytes = 800 ![[Network Layer - Example 7.16.png|center|500]] - **Example 7.16** - HLEN이 5고, offset 값이 100, total length 값이 100일 때 첫번째 바이트 마지막 바이트 숫자 구하기 - 헤더 길이는 $5 \times 4 = 20$ - total length 가 100이면 payload는 100 - 20 = 80 - 첫번째 바이트는 offset * 8 bytes = 800 - **마지막 바이트는 879** - 800부터 세니까 #### ICMPv4 **ICMPv4의 배경 및 목적** - IPv4의 결점을 보완하기 위해 설계됨 - **오류 보고 및 수정** : IPv4 자체에는 오류 보고 또는 오류 수정 메커니즘이 없음 - **호스트 및 관리 쿼리:** IP 프로토콜에는 호스트 및 관리 쿼리를 위한 메커니즘도 부족함 **Messages** - error-reporting messages 과 query messages로 나눌 수 있음 - **error-reporting messages** - 라우터 또는 호스트(목적지)가 IP 패킷을 처리할 때 발생할 수 있는 문제를 보고함 - **query messages** - pair로 발생하여 호스트 또는 네트워크 관리자가 라우터나 다른 호스트로부터 특정 정보를 얻는 데 도움을 줌 - 노드는 이웃을 발견할 수 있으며, 호스트는 네트워크 상의 라우터를 발견하고 학습할 수 있음 - 라우터는 노드가 메시지를 리디렉션하는 데 도움을 줄 수 있음 ![[Network Layer - Figure 7.19 General format of ICMP messages.png|center|500]] - **ICMP 메세지의 구조** - 8-bytes의 헤더와 가변 크기의 데이터 섹션으로 구성됨 - **헤더** - 첫 4 바이트는 모든 메세지에 공통적으로 사용되는 필드 - Type : ICMP 메세지 유형 - Code : 특정 메세지 유형의 이유를 나타냄 - Checksum : 메세지의 무결성 검사 - 나머지 헤더는 각 메세지 유형에 따라 구체적인 필드가 있음 - **데이터** - 오류 메시지의 경우, 원래 오류가 발생한 패킷을 찾기 위한 정보를 포함함 **Error-Reporting Messages** - **역할 및 책임** - IP가 신뢰할 수 없는 프로토콜이기 때문에, ICMP의 주요 책임 중 하나는 에러를 보고하는 것 - ICMP는 에러를 수정하지 않고 **단순히 보고만 함** - 에러 수정은 상위 계층 프로토콜에 맡겨짐 - 에러 메시지는 항상 원래 **orignal source로 보내짐** - ICMP는 원본 IP 주소를 사용하여 에러 메시지를 보냄 - **에러 리포트 규칙** - 특별한 주소에 대한 에러 메시지는 생성 안함 - 멀티캐스트 주소나 특별한 주소(예: 호스트 자신이나 루프백 주소)를 가진 데이터그램에 대해 에러 메시지를 생성하지 않음 - 루프백 주소: 127.0.0.1 - 로컬 호스트의 IP 주소: 0.0.0.0 - ICMP 에러 메시지에 대한 새로운 ICMP 에러 메시지는 생성 안함 - 첫번째 조각이 아닌 데이터그램에 대한 에러 메시지는 생성 안함 ![[Network Layer - Figure 7.20 Contents of data field for error messages.png|center|400]] - **에러 메시지의 data section** - 원래 에러가 발생한 데이터그램에 대한 정보를 포함해서 원래 데이터그램의 source host가 문제를 파악하고 대응할 수 있도록 도움 - **원본 데이터그램의 IP 헤더** - 에러 메시지를 수신하는 orignal source가 데이터그램 자체에 대한 정보를 얻을 수 있도록 함 - 어떤 데이터그램에서 오류가 발생했는지 식별할 수 있게 - **데이터그램의 첫 8바이트 데이터** - 첫 8바이트는 포트 번호(UDP 및 TCP)와 시퀀스 번호(TCP)에 대한 정보를 제공하므로 포함됨 - 이 정보는 orignal source가 프로토콜(TCP 또는 UDP)에 에러를 알리는 데 필요함 - **주요 메세지** : **Destination Unreachable(type 3)** - 이 메시지는 다양한 코드를 사용하여 에러 메시지 유형과 데이터그램이 최종 목적지에 도달하지 못한 이유를 정의함 - 예시: 코드 0은 호스트에 도달할 수 없음을 원본 출발지에 알림 **Query Messages** - **역할 및 책임** - 쿼리 메시지는 데이터그램에 캡슐화되어 전송됨 - 인터넷 내의 호스트 또는 라우터의 생존 여부 확인 - 두 장치 간의 단방향 또는 왕복 시간(round-trip) 측정 - 두 장치의 시계가 동기화되었는지 확인 - **주요 메세지** - Echo-request (type 8) and Echo-reply (type 0) 메시지 - 호스트/라우터가 다른 호스트/라우터의 생존 여부를 테스트하는 데 사용됨 - **ping 및 traceroute** 디버깅 툴에서 사용됨 - Timestamp request (type 13) and timestamp reply (type 14) 메시지 - 두 장치 간의 왕복 시간(RTT) 측정 및 시계 동기화 확인에 사용 - 타임스탬프 요청 메시지: 메시지가 전송된 시간을 정의하는 32비트 숫자를 전송함 - 타임스탬프 응답 메시지: 요청 메시지의 타임스탬프와 함께 요청이 수신된 시간과 응답이 전송된 시간을 나타내는 두 개의 새로운 32비트 숫자를 포함함 - 계산: 모든 타임스탬프가 표준 시간(UTC)을 나타내는 경우, 송신자는 단방향 및 왕복 시간을 계산할 수 있음 **Debugging Tool : Ping, Traceroute** - ICMP를 사용하는 두 가지 주요 디버깅 툴 : ping 및 traceroute - **Ping** - 호스트가 살아 있고 응답하는지 확인하는 데 사용됨 - **작동 방식** - 출발지 호스트는 ICMP 에코 요청 메시지를 전송함 - 목적지 호스트가 살아 있으면 ICMP 에코 응답 메시지로 응답함 - ping 프로그램은 에코 요청 및 에코 응답 메시지에 identifier 필드를 설정하고 시퀀스 번호를 0부터 시작하여 새로운 메시지가 전송될 때마다 1씩 증가시킴 - ping을 통해 왕복 시간(RTT)을 계산할 수 있음 ![[Network Layer - Example 7.17.png|center|500]] - **Traceroute or Tracert** - 패킷이 출발지에서 목적지까지 가는 경로를 추적함 - UNIX에서는 traceroute, Windows에서는 tracert라는 응용 프로그램 계층 프로그램이 사용됨 - 경로를 따라 방문한 모든 라우터의 IP 주소를 찾을 수 있음 - 프로그램은 보통 최대 30 hop을 검사하도록 설정됨 - 보통 인터넷 hop 수가 30보다 작기 때문에 - **작동 방식** - 두종류의 error-reporting 메세지를 활용함 : **time exceeded and destination unreachable** - 목적지 호스트에서 응용 프로그램 계층에 도달하지 않기 때문에 클라이언트 프로그램만 필요함 - 서버 프로그램 불필요 - Traceroute는 UDP 유저 데이터그램에 캡슐화되지만, 의도적으로 목적지에서 사용 불가능한 포트 번호를 사용함 - 경로에 n개의 라우터가 있다면, Traceroute는 (n + 1)개의 메시지를 전송함 - 첫 n개의 메시지는 각 라우터에서 하나씩 버려지고, 마지막 메시지는 목적지 호스트에서 버려짐 ![[Network Layer - Figure 7.21 Example of traceroute program.png]] - **첫 번째 Traceroute 메시지:** - TTL 값을 1로 설정하여 전송됨 - 첫 번째 라우터가 이 메시지를 폐기하고 시간 초과 ICMP 오류 메시지를 전송함 - 이 메시지는 첫 번째 라우터의 IP 주소와 이름이 포함하고 있음 - **반복 과정:** - n번째 Traceroute 메시지는 TTL 값을 n으로 설정하여 전송됨 - n번째 라우터가 이 메시지를 폐기하고 시간 초과 ICMP 오류 메시지를 전송함 - 이 메시지는 n번째 라우터의 IP 주소와 이름이 포함하고 있음 - **최종 메시지:** - (n + 1)번째 메시지는 목적지 호스트에 도달함 - 이 메시지는 포트 번호를 찾을 수 없기 때문에 목적지 호스트에서 버려짐 - ICMP는 포트 번호를 찾을 수 없음을 나타내는 destination unreachable 메시지(코드 3)를 전송함 - Traceroute 프로그램은 이 ICMP 메시지를 수신하면 최종 목적지에 도달했음을 알 수 있음 **ICMP checksum** - ICMP에서는 전체 메시지(헤더+데이터)에 대해 checksum이 계산됨 ![[Network Layer - Example 7.18.png|center|500]] - **Example 7.18** - 간단한 에코 요청 메시지에 대한 checksum 계산 예제 - identifier를 1로, 시퀀스 번호를 9로 임의로 선택함 - 메세지는 16비트(2바이트) 단위로 나뉨 - 이를 더한 후에 합한 결과에 보수를 취하면 checksum 결과 뚝딱 #### Mobile IP - 모바일 IP는 노트북과 같은 모바일 및 개인용 컴퓨터가 점점 더 인기를 끌면서, 다양한 위치에서 인터넷에 연결할 수 있도록 IP 프로토콜을 확장한 것 - 고정된 네트워크에 묶이지 않고 이동 중에도 인터넷 연결을 유지할 수 있게 도와줌 **Addressing** - 모바일 호스트가 한 네트워크에서 다른 네트워크로 이동할 때, IP 주소 지정 구조를 수정해야 함 - IP 주소는 고정된 호스트와 네트워크에 맞춰 설계되었으나, 모바일 호스트의 경우 네트워크를 변경할 때마다 IP 주소도 변경되어야 함 ![[Network Layer - Figure 7.23 Home address and care-of address.png|center|500]] - 모바일 IP는 이를 해결하기 위해 2가지 주소를 사용함 : **Home address와 care-of address(CoA)** - **Home Address** - 영구적인 주소: 호스트가 원래 속한 네트워크와 연결된 영구 주소 - 호스트가 이동하더라도 이 주소는 변하지 않음 - **Care-of Address (CoA)** - **임시 주소:** 호스트가 네트워크를 이동할 때마다 변경되는 임시 주소 - 호스트가 방문하는 외부 네트워크와 연관됨 - **모바일 호스트가 외부 네트워크를 방문하면 에이전트 발견(agent discovery) 및 등록(Registration) 단계에서 CoA를 받음** **Agent** ![[Network Layer - Figure 7.24 Home agent and foreign agent.png|center|500]] - 에이전트(=대행사)의 역할 - 주소 변경을 인터넷의 나머지 부분에 투명하게 하기 위해 홈 에이전트(**Home Agent**, HA)와 외부 에이전트(**Foreign Agent**, FA)가 필요함 - agent는 각 네트워크를 물고 있는 라우터라고 생각하면 됨 - 홈 에이전트는 홈 네트워크에, 외부 에이전트는 외부 네트워크에 위치함 **모바일 호스트가 원격 호스트와 통신하는 방법** - 모바일 호스트가 원격 호스트와 통신하기 위해서는 세 가지 단계가 필요함 - **agent discovery, registration request, data transfer** - solicitation 메시지를 홈 에이전트에 보내서 존재를 알림 (등록) - 홈 에이전트가 해당 호스트가 네트워크에 속하는 걸 확인하면 advertisement 메시지를 보냄 - 그 후, 모바일 호스트가 먼 거리를 이동하면 그곳의 foreign 에이전트에 똑같은 과정을 거침 - foreign 에이전트는 해당 host가 지금 여기 있구나를 인지하게 됨 - registration 요청을 보내서 home에게도 이를 알려야 함 - foreign 에이전트에 요청을 보내면 걔가 홈 에이전트에 등록 요청을 전달해줌 - IP 주소 위치 파악 완. 이제 데이터 전송할 수 있음 ![[Network Layer - Figure 7.25 Remote host and mobile host communication.png|center|500]] 1. **Agent Discovery, 에이전트 발견** - 에이전트 발견 단계는 두 개의 하위 단계로 구성됨 - 모바일 호스트가 홈 네트워크를 떠나기 전에 홈 에이전트를 발견해야 함 - 모바일 호스트가 외부 네트워크로 이동한 후 외부 에이전트를 발견해야 함 - CoA(케어 오브 주소)와 외부 에이전트의 주소를 학습함 - 발견은 2가지 유형의 메시지를 포함함 : advertisement and solicitation - **advertisement** - 라우터가 네트워크에서 자신의 존재를 ICMP 광고 메시지를 사용하여 광고할 때, 에이전트 역할을 한다면 에이전트 광고를 패킷에 첨부할 수 있음 - **solicitation** - 모바일 호스트가 새로운 네트워크로 이동했지만 에이전트 advertisment 를 받지 못한 경우, 에이전트 solicitation(등록)을 시작할 수 있음 - advertisments는 브로드캐스팅 메시지임 - ICMP request 메시지를 활용해 에이전트에 지원이 필요함을 알림 2. **Registration, 등록** - **모바일 호스트가 외부 네트워크로 이동한 후 외부 에이전트를 발견하면 등록해야 함** - 모바일 호스트는 외부 에이전트, 홈 에이전트 둘 다 등록해야 하고 등록이 만료되면 갱신해야 함. 또한 홈 네트워크로 돌아오면 등록을 취소해야 함. - 등록 요청 메시지는 모바일 호스트에서 FA에 **CoA, Home 주소, HA 주소를 등록하기 위해 전달됨** - FA는 요청을 받은 후 HA에 메세지를 전달함 - 이때 HA는 등록 요청을 확인하거나 거부함 - 등록 요청이나 응답은 포트 434를 사용하는 **UDP**에 의해 전송됨 - 이때 HA도 받은 패킷을 통해 FA의 IP 주소를 알게됨 ![[Network Layer - Figure 7.29 Data transfer.png|center|500]] 3. **Data Transfer** - 에이전트 발견과 등록 후, 모바일 호스트는 원격 호스트와 통신할 수 있음 - **데이터 흐름 : 원격 호스트 → 홈 에이전트 → 외부 에이전트 → 모바일 호스트 → 원격 호스트** ![[Network Layer - Figure 7.30 Double crossing.png]] - 2가지 비효율적인 사례 : **Double crossing, Triangle crossing** - **Double crossing** - 원격 호스트가 모바일 호스트와 같은 네트워크로 이동했을 때 발생 - 원격 호스트가 모바일 호스트로 패킷을 보낼 때, 패킷이 인터넷을 두 번 건너게 됨 - **Triangle crossing** - 원격 호스트가 모바일 호스트와 다른 네트워크에 연결되어 있을 때 발생함 - 원격 호스트가 모바일 호스트로 패킷을 보낼 때, 패킷이 원격 호스트에서 홈 에이전트로, 홈 에이전트에서 모바일 호스트로 전송됨 - 패킷이 삼각형의 두 변을 따라 이동하게 되어, 비효율적임 ## 4. Forwarding **IP 주소의 역할 확장** - forwarding이란, 패킷을 목적지로 향하는 경로에 배치하는 것을 말함 - 인터넷이 다양한 다양한 링크(네트워크)의 조합으로 이루어져 있기 때문에, 전달은 다음 hop(최종 목적지 또는 중간 연결 장치)에 패킷을 전달하는 것을 의미함 **목적지 주소 기반 forwarding** ![[Network Layer - Figure 7.32 Simplified forwarding module in classless address.png|center|500]] - 현재도 널리 사용되고 있는 전통적인 접근 방법 - forwarding을 위해 호스트나 라우터는 **forwarding table**을 가지고 있어야 함 - 호스트나 라우터가 패킷을 전송할 때 또는 전달할 패킷을 수신했을 때, 전달 테이블을 참조하여 패킷을 전달할 다음 hop 을 찾음 - 패킷이 도착하면 라우터는 destination address를 확인함 - 본인이 가지고 있는 테이블에서 검색해서 어디로 보낼지 선택함 ![[Network Layer - Example 7.19.png|center|500]] ![[Network Layer - Example 7.20.png|center|500]] - **Example 7.19 / 20** - 주어진 네트워크 구성에 따라 forwarding table 작성하기 - mask = prefix 길이 - default의 경우 일치하는 게 없으면 여기로 보내라는 의미임 - 검정 글씨의 경우 링크 커넥션의 IP 주소, 파란 글씨의 경우 속해 있는 네트워크의 IP 주소임 - 테이블 7.3 대신 네트워크 주소/마스크가 비트로 주어진 테이블 7.4를 사용할 수도 있음 ![[Network Layer - Example 7.21.png|center|500]] - **Example 7.21** - 그림 7.33에서 목적지 주소 180.70.65.140을 가진 패킷이 R1에 도착하는 전달 과정 - 첫 번째 마스크 (/26)를 목적지 주소에 적용합니다. 결과는 180.70.65.128로, 해당 네트워크 주소와 일치하지 않습니다. - 두 번째 마스크 (/25)를 목적지 주소에 적용합니다. 결과는 180.70.65.128로, 해당 네트워크 주소와 일치합니다. 다음 홉 주소와 인터페이스 번호 m0가 추출되어 패킷이 전달됩니다. **Address Aggregation** ![[Network Layer - Figure 7.34 Address aggregation.png|center|400]] - classful addressing을 사용하면, 조직 외부의 각 사이트에 대해 forwarding table에 하나의 항목만 존재함 - 해당 사이트가 서브넷으로 나뉘어져 있어도 항목은 사이트를 정의함 - 패킷이 라우터에 도착하면, 라우터는 해당 항목을 확인하고 패킷을 전달함 - **classless addressing을 사용하면, forwarding table 항목의 수가 증가할 가능성이 있음** - forwarding table을 만들 때 엔트리가 늘어나는 문제를 줄이기 위해서 Address Aggregation 개념이 설계됨 - 서브넷마다 forwarding table을 유지하는 것보다 r1 하나로 묶어서 r1의 forwarding table만 관리하면 더 간단함 - 그림의 R2 입장에서는 140.24.7.0 인데 24비트만 네트워크 주소로 마스크를 씌워서 이걸 가지고 있는 애들이면 다 m0으로 보내게 함 - 그럼 그걸 R1이 알아서 나눔 ![[Network Layer - Figure 7.35 Longest mask addressing.png|center|500]] - Organization 4는 aggregation 대상이 아님 - 그래서 별도의 엘리먼트로 저장함 ![[Network Layer - Example 7.22.png|center|500]] - 지역 ISP가 120.14.64.0부터 시작하는 16,384개의 주소를 할당받음 - 지역 ISP는 이 블록을 4개의 서브블록으로 나누기로 했습니다. 각 서브블록은 4096개의 주소를 가짐 - 이 서브블록 중 세 개는 세 개의 로컬 ISP에 할당되고, 두 번째 서브블록은 미래 사용을 위해 예약됨 - 각 블록의 마스크는 /20임 - 이는 원래 블록이 /18 마스크로 4개의 블록으로 나누어졌기 때문 - 4개를 식별하기 위해 2비트가 더 필요하니까 - 거기서 또 8개로 쪼개지면, 이를 식별하기 위해 3이 더 필요해짐 - 밑에 건 128개나 식별해야 해서 7이 더 필요해짐 **Forwarding Table Search Algorithm** - classless addressing에서는 목적지 주소에는 네트워크 정보가 포함되지 않음 (어디까지가 네트워크 주소?) - 때문에 네트워크 정보를 포함한 전통적인 검색 방법을 사용할 수 없음 - **longest prefix match** - forwarding table을 각 프리픽스에 대해 버킷(bucket)으로 나눔 - 라우터는 먼저 가장 긴 프리픽스를 시도함 - 목적지 주소가 해당 버킷에서 발견되면 검색이 완료됨 - 주소가 발견되지 않으면 다음 프리픽스로 검색을 계속함 - 이 방법은 시간이 오래 걸릴수도 있음 ![[Network Layer - Example 7.23.png|center|500]] - x = destination IP address - x를 forwarding table에 두고 매칭함 - 긴 prefix 쓰는 거 부터 하나씩 매칭해보고 주소가 발견되지 않으면 넘어감 - 매칭되면 다음 hop으로 넘김 - destination address가 바뀌지는 않고 그냥 다음 hop address로 보내는거임 **Label 기반 Forwarding** - 배경 - 1980년도부터 IP를 연결지향 프로토콜처럼 동작하게 하려는 노력으로 라우팅을 스위칭으로 대체하려는 시도가 시작됨 - 라우팅 : 테이블에서 서칭하는거 - 마스크를 가지고 네트워크 어드레스가 매칭이 되는지 연산하느라 딜레이가 좀 있음 - **스위칭: 라벨, 인덱스를 사용해서 테이블에 바로 접근함** ![[Network Layer - Example 7.24.png|center|500]] - 4번 레이블은 인터페이스 2번을 통하고 다음 레이블은 12번임 - 목적지 주소 기반 방법에서는 패킷을 다음 hop에 전달하면서 IP 헤더를 바꾸지 않았는데, 여기서는 그때그때 다음에 필요한 어떤 레이블 값으로 바꿔줘야 함 - **라우팅 딜레이를 줄이는 게 핵심** - **백본을 돌아다니는 엄청난 양의 패킷을 일일이 테이블에 서칭하는 건 비효율적임** - **그래서 백본망은 레이블을 가지고 스위칭하는 방식으로 이미 경로를 다 세팅해둠** ![[Network Layer - Figure 7.39 MPLS header added to an IP packet.png|center|400]] - 이를 위해서는 새로운 헤더가 필요함 : **MPLS 헤더** - 기존의 IP만 가지고는 안됨 - 레이블이 쭉 리스트업 되어 있음 - 지나가면서 쌓인 레이블이 하나씩 사라짐 = **hierarchical switching** - 백본망을 거치며 MPLS 헤더가 붙고 스위칭될 때마다 쭉 리스트업됨 - 빠져나갈때는 다 떼버리고 다시 IP 라우팅 방식으로 동작함 **MPLS** ![[Network Layer - MPLS forwarding tables.png|center|400]] - **Multiprotocol label switching** - 네트워크 계층에서 데이터 전송을 효율화하기 위한 메커니즘 - 라우터와 스위치의 기능을 결합하여 패킷 전달 속도를 향상시킴 - **주요 특징** - **라벨 기반 포워딩**: IP 주소 대신 라벨(label)을 사용하여 패킷을 포워딩함 (빠른 라우팅 결정 가능) - **고속 전송**: 각 패킷이 통과할 때마다 라우터에서 전체 IP 헤더를 확인할 필요 없이 라벨을 기반으로 전송 경로를 빠르게 결정함 - **유연한 경로 설정**: 네트워크 운영자가 트래픽 흐름을 제어하고 최적화된 경로를 설정할 수 있도록 함 - **다양한 네트워크 프로토콜 지원**: IP 뿐만 아니라, 이더넷, 프레임 릴레이, ATM 등의 다양한 프로토콜과 호환 - **작동 방식** - 라벨 생성 및 패킷 헤더에 추가, 라벨 기반 포워딩(중간 라우터들은 IP 헤더를 검사하지 않고 라벨만을 사용하여 패킷을 포워딩함), 패킷이 목적지 네트워크에 도달하면 라벨이 제거되고 패킷은 일반 IP패킷으로 전송됨