3. Network Layer - 라우터, routing, IPv6

## 1. IPv4의 한계와 해결책 **IPv4의 한계** - **주소 공간의 한계** : 인터넷 사용자가 급격히 증가함에 따라 32비트 주소 체계가 부족해짐 - 패킷 우선순위 지정 및 대역폭 예약과 같은 QoS 기능을 효과적으로 지원하지 못함 ### 1-1. CIDR ![[Network Layer - Figure 7.8 Slash notation (CIDR).png|center|500]] - IP 주소를 네트워크 클래스에 따라 할당하는 대신, **필요한 만큼의 주소 블록을 유연하게 할당하는 방식** - 슬래시(/)를 사용하여 prefix 길이를 지정함 - **주소 효율성**: 필요한 만큼의 주소 블록을 할당하여 주소 공간을 더 효율적으로 사용함 - 라우팅 테이블 축소: 라우팅 테이블의 항목 수를 줄여 네트워크 성능을 향상시킴 ### 1-2. NAT: network address translation ![[Network Layer - NAT- network address translation.png|center|500]] - **네트워크 주소 변환 기술로, 로컬 네트워크의 모든 장치들이 하나의 IPv4 주소를 공유하여 외부와 통신할 수 있도록 하는 기술** - 로컬 네트워크를 떠나는 모든 패킷은 동일한 NAT IP 주소를 가지지만, 서로 다른 포트 번호를 가짐 - 로컬 네트워크의 모든 장치들은 “프라이빗” IP 주소 공간(10/8, 172.16/12, 192.168/16 prefixes)을 사용함 - **IP 주소 절약** : 모든 장치에 제공자 ISP로부터 단 하나의 IP 주소만 있으면 됨 - **주소 변경 유연성** : 로컬 네트워크 내 호스트의 주소를 외부 세계에 알리지 않고 변경할 수 있음 - **ISP 변경 용이성** : ISP를 변경해도 로컬 네트워크 내 장치의 주소를 변경할 필요가 없음 - **보안 강화** : 로컬 네트워크 내 장치는 외부 세계에서 직접 주소 지정이 불가능하고 가시적이지 않음 **구현 방법** - 모든 출발 데이터그램의 (출발지 IP 주소, 포트 번호)를 (NAT IP 주소, 새로운 포트 번호)로 대체함 - 원격 클라이언트/서버는 (NAT IP 주소, 새로운 포트 번호)를 목적지 주소로 사용하여 응답함 - **NAT 변환 테이블**에 각 (출발지 IP 주소, 포트 번호)와 (NAT IP 주소, 새로운 포트 번호) 변환 쌍을 기억함 - 도착 데이터그램의 목적지 필드에서 (NAT IP 주소, 새로운 포트 번호)를 NAT 테이블에 저장된 해당 (출발지 IP 주소, 포트 번호)로 대체함 **문제점** - 라우터는 오직 네트워크 계층(레이어 3)까지만 처리해야 한다는 관점이 있는데, NAT는 전송 계층(레이어 4)까지 영향을 미침 - IP 주소 부족 문제는 IPv6로 해결되어야 한다고 주장함 (더 많은 주소 공간을 통해 해결) - NAT는 네트워크 계층 장치가 포트 번호를 조작하기 때문에 종단 간 원칙(**end-to-end argument**)을 위반함 - 네트워크의 기능이 end 시스템에서만 구현되어야 한다는 개념 - NAT 테이블은 내부 네트워크 장치가 외부 네트워크로 데이터그램을 보낼 때 생성되므로 내부 네트워크 장치가 먼저 외부 네트워크로 데이터를 보내야만 테이블이 생성된다는 문제가 있음 - 외부에서의 접근 제한, 연결 초기화 문제 등등 - 이를 위해 포트 포워딩이나 UPnP 같은 기술을 써서 NAT 라우터에서 특정 포트를 미리 개방해 두는 방법이 있음 그럼에도 불구하고 NAT은 IP 주소 절약과 보안 측면에서 실질적인 장점을 제공하기 때문에 가정과 기관 네트워크, 4G/5G 셀룰러 네트워크에서 광범위하게 사용되고 있음 ### 1-3. IPv6 - 1990년대 초반, IPv4 주소 공간의 고갈과 기타 문제점 때문에 새로운 IP 프로토콜이 필요해짐 - **주소 공간 확장** : IPv6 주소 공간은 $2^{128}$개의 주소를 포함하고 있음 - 340, 282, 366, 920, 938, 463, 374, 607, 431, 768, 211, 456 - IPv4 주소 공간의 $2^{96}$배로, 사실상 주소 고갈이 없음 - **속도 향상** : 40바이트 고정 길이 헤더를 사용하여 처리와 전달 속도를 높임 - 특정 데이터 흐름에 대해 차별화된 처리가 가능해짐 **Representation, 표현 방법** - IPv6 주소는 128비트(16바이트)로, IPv4 주소 길이의 4배임 - 약어 사용 : IPv6 주소가 매우 긴 관계로 많은 숫자가 0으로 이루어짐 1. **선행 0 생략:** 섹션의 선행 0은 생략할 수 있음 - 0074 → 74, 000F → F, 0000 → 0, 3210 → 3210 2. **0 압축**: 연속된 0으로 이루어진 섹션은 모두 생략하고 이중 세미콜론(::)으로 대체할 수 있음 - zero compression은 주소당 한 번만 허용됨 (가장 긴 곳에 적용) - FDEC:0000:0000:0000:0000:BBFF:0000:FFFF → FDEC:0:0:0:0:BBFF:0:FFFF → FDEC::BBFF:0:FFFF **Address Space, 주소 공간** - IPv6 주소 공간은 $2^{128}$개의 주소를 포함하고 있음 - 340, 282, 366, 920, 938, 463, 374, 607, 431, 768, 211, 456 - IPv4 주소 공간의 $2^{96}$배로, 사실상 주소 고갈이 없음 - 세 가지 주소 유형 - **Unicast 주소:** 하나의 특정 장치에 대한 주소. - **Anycast 주소** - 하나의 주소를 공유하는 여러 컴퓨터 그룹을 정의함. - 패킷은 여러명 중에 가장 가까운 멤버 하나에게 전달됨 - inquiry에 응답할 수 있는 여러 서버가 있는 경우에 사용됨 - **Multicast 주소:** 여러 장치에게 동시에 전달되는 주소 **주소 공간 할당** - IPv6 주소 공간은 다양한 크기의 여러 블록으로 나뉘며, 각 블록은 특정 용도로 할당됨 - 많은 블록이 아직 할당되지 않았으며, 미래에 사용을 위해 예약되어 있음 - 아래 표는 할당된 블록만 보여줌 - 마지막 열은 전체 주소 공간에서 각 블록이 차지하는 비율을 나타냄 - 3비트만 봤을 때 2가 된다면 그건 Global unicast 주소다(?) ![[Network Layer - Table 7.5 Prefixes for assigned IPv6 addresses.png|center|400]] - **Global Unicast 주소 할당** - Global Unicast 주소 할당을 위한 **CIDR (Classless Inter-Domain Routing)** 주소 블록은 2000::/3 (크기: $2^{125}$ 비트)임 - Global Unicast 주소인 경우에는 세 부분으로 나눔 - global routing prefix (n bits) : 인터넷을 통해 패킷을 라우팅하는 데 사용됨 - ISP와 같은 조직이 이 블록을 소유함 - n = 48: 3 bits (001, fixed) + 45 bits (for $2^{45}$ sites) - Subnet identifier (m bits) - Interface identifier (q bits) - n=48, m=16, q=64 정도로 권장함 ![[Network Layer - Figure 7.41 Global unicast address.png|center|600]] - **link layer 주소와의 관계, interface identifier** - IPv6 주소 체계는 호스트 ID와 링크 계층 주소 간의 상관 관계를 허용함 - IPv4 주소 체계에서는 link layer 주소가 일반적으로 호스트 ID보다 훨씬 길기 때문에 이러한 관계가 존재하지 않음 - 길이가 64비트 이하인 link layer 주소는 전체 또는 일부가 interface identifier에 포함될 수 있음 - 64-bit extended unique identifier (EUI-64) defined by IEEE - 64비트 물리적 주소를 매핑하려면, 인터페이스 주소를 정의하기 위해 이 형식의 글로벌/로컬 비트를 **0에서 1로 변경해야 함** - 48-bit link-layer address defined by Ethernet - 48비트 Ethernet 주소를 64비트 인터페이스 식별자로 매핑하려면, **로컬/글로벌 비트를 1로 변경하고 추가로 16비트를 삽입해야 함** - 추가 비트는 15개의 1과 하나의 0으로 정의되며, 이는 $FFFE_{16}$으로 표시함 ![[Network Layer - Mapping EUI-64, Mapping Ethernet MAC Address.png|center|500]] ![[Network Layer - Example 7.25.png|center|500]] - **Example 7.25** - 조직이 블록을 할당받았을 때, 이 조직의 첫 번째와 두 번째 서브넷의 CIDR 표기법은? - IPv6 주소는 128비트이며, /48은 첫 48비트가 네트워크 부분임을 의미함 - 나머지 80비트는 서브넷 및 호스트 부분으로 사용할 수 있음 - 여기서 서브넷팅을 통해 서브넷을 구분함 - 서브넷 식별자를 추가하여 전체 64비트 네트워크 주소를 만들어야 함. 즉, /48에서 /64로 확장 - 첫 번째 서브넷은 서브넷 식별자 $0001_{16}$을 사용해야 하고, 두 번째 서브넷은 서브넷 식별자 $0002_{16}$을 사용해야 함 - 첫 번째 서브넷: 2000:1456:2474:0001/64 - 두 번째 서브넷: 2000:1456:2474:0002/64 ![[Network Layer - Example 7.26.png|center|500]] - **Example 7.26** - EUI의 물리적 주소가 있을 때, 이더넷 주소 형식을 사용하여 interface identifier 찾기 - 첫 8비트의 7번째 비트를 0에서 1로 바꾸고, colon hex notation으로 적으면 됨 - **notation 방법 주의하기** (이더넷 주소 표기법) ![[Network Layer - Example 7.27.png|center|500]] - **Example 7.27** - 이더넷 물리적 주소가 있을 때, 이더넷 주소 형식을 사용하여 interface identifier 찾기 - 첫 8비트의 7번째 비트를 0에서 1로 바꾸고, 첫 24비트 뒤에 $FFFE_{16}$ 추가하기 ![[Network Layer - Example 7.28.png|center|500]] - **Example 7.28** - 조직이 블록을 할당받았을 때 세 번째 서브넷의 IPv6 주소 구하기 - **Interface identifier 생성** - IEEE 물리 주소 $(F5-A9-23-14-7A-D2)_{16}$ - 이더넷 주소 형식에서는 48비트 주소를 64비트로 변환하기 위해, 중간에 FF:FE를 추가하고 첫 번째 옥텟의 7번째 비트를 0에서 1로 변경함 - 변환된 interface identifier는 F7A9:23FF:FE14:7AD2 - **global prefix 및 subnet identifier 할당** - 2000:1456:2474:0003 - **전체 IPv6 주소 조합** - 2000:1456:2474:0003:F7A9:23FF:FE14:7AD2**/128** - 꼭 끝에 어디까지 네트워크 주소인지 명시하기 **Special Addresses** ![[Network Layer - Table 7.5 Prefixes for assigned IPv6 addresses.png|center|400]] - prefix (0000::/128) 을 가지는 주소 1. **미지정 주소 (Unspecified Address)** - 주소: 0000::/128 (모두 0) - 용도: 호스트가 자신의 주소를 모를 때, 부트스트랩 과정 중 문의를 보내기 위해 사용함 2. **루프백 주소 (Loopback Address)** - 주소: 0000::1/128 - 용도: 호스트가 자신에게 패킷을 보낼 때 사용함 (IPv4에 있던 거. 디버깅용. 마지막 비트만 1) 3. **호환 주소 (Compatible Address)** - 주소: 0000::/96 (0000 0000으로 시작. 그 뒤로 96비트까지는 알아서 주소 설정) - 용도: IPv6를 사용하는 컴퓨터가 다른 IPv6 컴퓨터에 메시지를 보낼 때 사용함 4. **매핑된 주소 (Mapped Address)** - 주소: 0000::FFFF/96 - 용도: IPv6로 마이그레이션된 컴퓨터가 여전히 IPv4를 사용하는 컴퓨터에 메시지를 보낼 때 사용함 ![[Network Layer - Special Addresses.png|center|400]] **기타 할당된 블록들** ![[Network Layer - Other Assigned Blocks.png|center|600]] 1. **Unique Local Unicast Block** - 사이트가 자체적으로 생성하여 사용하는 사설 주소 - 이 주소를 목적지로 사용하는 패킷은 라우팅되지 않음 - 1111 110; 다음 비트는 0 또는 1로 설정되어 주소가 로컬에서 또는 기관에 의해 선택되었음을 정의. - 그 다음 40비트는 사이트에서 무작위로 생성됨 2. **Link Local Addresses** - 네트워크 내에서 사설 주소로 사용됨 - 10비트 블록 식별자 1111111010을 사용하고, 그 다음 54비트는 0으로 설정됨 - 마지막 64비트는 각 컴퓨터의 인터페이스를 정의하는 데 사용됨 3. **Multicast Addresses** - 호스트 그룹을 정의하는 데 사용됨 - 모든 멀티캐스트 주소는 프리픽스 11111111 (8비트)을 사용함 - flag는 그룹 주소를 영구적 또는 일시적으로 정의함 - **permanent** : 인터넷 당국에 의해 정의되며 항상 접근할 수 있음 - **transient** : 임시적으로 사용됨 **Autoconfiguration, 자동 구성** - autoconfiguration : 네트워크에 연결된 장치가 스스로 IP 주소를 설정하는 방법 - **IPv4** : 네트워크 관리자에 의해 수동으로 설정되거나 동적 호스트 구성 프로토콜(DHCP)에 의해 자동으로 설정됨 - **IPv6** : DHCP 프로토콜을 사용하여 IPv6 주소를 호스트에 할당할 수 있지만, 호스트가 스스로 주소를 구성할 수도 있음 1. 호스트가 **link local address**를 생성함 - 10-bit prefix (1111 1110 10) + 54 zeros + 64-bit interface identifier 2. **고유성 테스트** - 호스트는 link local address가 다른 호스트에 의해 사용되지 않는지 확인함 3. **고유성 테스트 통과 시** - 호스트는 이 주소를 link local address로 저장함 (사설 통신용) - 여전히 global unicast address가 필요하기에, 호스트는 로컬 라우터에 메시지를 보냄 - 네트워크에 라우터가 있으면, 호스트는 global unicast prefix와 subnet prefix를 포함하는 메시지를 수신함 - 이를 인터페이스 식별자에 추가하여 global unicast address를 생성함 ![[Example 7.29-1.png|center|500]] ![[Example 7.29-2.png|center|500]] - **Example 7.29** - 호스트의 글로벌 유니캐스트 주소 구하기 - **1단계: 인터페이스 식별자 생성** - **Ethernet 주소:** F5-A9-23-11-9B-E2 - **변환 규칙:** 첫 번째 옥텟의 7번째 비트를 0에서 1로 변경하고, FF:FE를 추가함 - **결과:** F7A9:23FF:FE11:9BE2 - **2단계: 링크 로컬 주소 생성** - **프리픽스:** FE80:: - **인터페이스 식별자**: F7A9:23FF:FE11:9BE2 - **링크 로컬 주소:** FE80::F7A9:23FF:FE11:9BE2 - **3단계: 라우터 광고 메시지 수신** - 호스트는 라우터로부터 글로벌 유니캐스트 프리픽스와 서브넷 식별자가 포함된 메시지를 수신함 - **프리픽스:** 3A21:1216:2165 - **서브넷 식별자:** A245 - **결합:** 3A21:1216:2165:A245 - **4단계: 글로벌 유니캐스트 주소 생성** - **프리픽스 및 서브넷 식별자:** 3A21:1216:2165:A245 - **인터페이스 식별자 추가:** F7A9:23FF:FE11:9BE2 - **글로벌 유니캐스트 주소:** 3A21:1216:2165:A245:F7A9:23FF:FE11:9BE2 **IPv6 Protocol** ![[Network Layer - Figure 7.46 IPv6 datagram.png|center|400]] **- 데이터그램 포맷** - **Version:** 4-bits 버전 정보 필드로, IPv6 프로토콜 버전(6가지)을 정의함 - **Traffic class:** 8-bits. 다른 전송 요구 사항을 가진 페이로드를 구분하기 위해 사용 - IPv4의 서비스 타입 필드와 비슷함 - **Flow Label:** 20-bits. 특정 데이터 흐름에 대한 특별한 처리를 제공하기 위해 설계됨 - **Payload Length:** 16-bits. 헤더를 제외한 IP 데이터그램의 길이를 정의함 - **Next Header:** 8-bits. 첫 번째 확장 헤더(있는 경우) 또는 기본 헤더 다음에 오는 데이터의 유형을 정의함 - **Hop Limit:** 8-bits. TTL(Time to Live) 필드와 동일한 목적을 수행 - **Concept of Flow and Priority in IPv6** - 초기 IP 프로토콜은 connectionless하게 설계됨 - 현재는 connection-oriented 프로토콜로 사용하는 경향이 있음 (ACK 줘잉) - MPLS 기술 : IPv4 패킷을 MPLS 헤더에 레이블 필드를 사용하여 캡슐화할 수 있음 - 버전 6에서는 플로우 레이블(flow label)이 직접 IPv6 데이터그램 형식에 추가되어 IPv6를 연결지향 프로토콜로 사용할 수 있게 함 - **Fragmentation and Reassembly** - **IPv6 데이터그램은 source(시작지)에서만 쪼개질 수 있고 라우터에서는 쪼개지지 않음** - 재조립은 마찬가지로 목적지에서 이루어짐 - **Extension Header** ![[Network Layer - Extension Header.png|center|400]] **ICMPv6 Protocol** - ICMPv4보다 더 복잡해짐 - 몇 가지 프로토콜이 추가되고 새로운 메시지들이 추가됨 - 이웃 탐색 (Neighbor-Discovery, ND) 프로토콜과 역방향 이웃 탐색 (Inverse-Neighbor-Discovery, IND) 프로토콜 - Membership-query 과 membership-report 메시지 **IPv4 to IPv6** - **Dual Stack** ![[Network Layer - Figure 7.51 Dual stack.png|center|500]] - 가장 많이 쓰이는 방법 - 인터넷의 모든 호스트가 IPv6를 사용할 때까지 스테이션은 IPv4와 IPv6를 동시에 실행함 - 호환성 유지 및 점진적 전환 지원 - **Tunneling** ![[Network Layer - Figure 7.52 Tunneling strategy.png|center|500]] - 두 대의 IPv6 컴퓨터가 서로 통신해야 하지만, 패킷이 IPv4를 사용하는 지역을 통과해야 하는 경우에 사용되는 전략 - IPv6 패킷이 IPv4 지역에 진입할 때 IPv4 패킷으로 캡슐화되었다가 이 지역을 벗어나면 캡슐화가 해제됨 - IPv4 패킷이 IPv6 패킷을 데이터로 운반하고 있음을 명확히 하기 위해 프로토콜 값이 41로 설정됨 - **Header Translation** ![[Network Layer - Figure 7.53 Header translation strategy.png|center|500]] - 인터넷의 대부분이 IPv6로 전환되었지만 일부 시스템이 여전히 IPv4를 사용하는 경우 필요함 - 송신자가 IPv6를 사용하고 싶지만 수신자가 IPv6를 이해하지 못할 때 - 헤더 변환을 통해 IPv6 패킷의 헤더가 IPv4 헤더로 완전히 변환됨 - IPv6와 IPv4 간의 호환성 유지 ## 2. 라우팅 프로토콜 - **라우팅 프로토콜의 목표** - 호스트에서 목적지 호스트로 데이터를 전달하는 “좋은” 경로를 찾는 것 - 경로 : 주어진 출발지 호스트에서 최종 목적지 호스트까지 데이터 패킷이 거치는 라우터들의 연속 - **“좋은” 경로**: 비용이 가장 적거나, 가장 빠르거나, 혼잡이 가장 적은 경로 - **그래프로 추상화** - 좋은 경로를 찾기 위해 네트워크를 그래프로 추상화하고, 링크 비용을 정의함 - $C_{a,b}$ = 노드 a와 b를 연결하는 직접 링크의 비용 e.g. $C_{u,z} = \infty$ 이면 u와 z 사이에 링크가 없음을 의미함 - 비용은 네트워크 운영자가 정의하며 상황에 따라 다름 - **라우팅 알고리즘 분류** - **global vs decentralized(분산)** - **global** : 모든 라우터가 네트워크의 전체 토폴로지와 링크 비용 정보를 가지고 있어서, 모든 라우터가 네트워크 전체를 보고 가장 좋은 경로를 계산함 **(e.g. link state 알고리즘)** - **decentralized** : 라우터가 자신의 이웃과만 정보를 교환하고, 이 정보를 바탕으로 최적의 경로를 점진적으로 계산함 **(e.g. distant vector 알고리즘)** - **static vs dynamic** - **static** : 경로가 잘 변하지 않으며, 초기 설정 후 큰 변경이 없을 때 유리함 - **dynamic** : 네트워크 상태 변화에 빠르게 반응하여 경로를 업데이트함. 네트워크의 실시간 상태에 따라 최적의 경로를 유지하는 데 유리함 (주기적인 업데이트 또는 링크 비용 변화에 즉각적으로 대응) **link state 알고리즘** ![[Network Layer - Dijkstra’s algorithm an example.png|center|600]] - **전체 그림과 정보 수집**\ - **centralized**: 네트워크 토폴로지와 링크 비용이 모든 노드에게 알려져 있음 - link state broadcast를 통해 이루어지며, 모든 노드가 동일한 정보를 가짐 - flooding : 링크 상태 정보를 받은 노드가 주변 노드에게 다시 보내고 중복된 정보는 무시함 - **Dijkstra’s algorithm**을 사용함 - 앞선 정보를 바탕으로 다익스트라 알고리즘을 써서 출발지에서 모든 목적지까지의 최소 비용 경로를 계산함 - **최소 비용 경로**를 한 노드(출발지)에서 연결된 다른 모든 노드로 계산하고, 이 정보를 바탕으로 해당 노드의 포워딩 테이블을 만듦 - 이 과정을 **반복**해서 모든 목적지에 대한 최소 비용 경로를 알게 됨 - **효율성 및 복잡도** - 다익스트라 알고리즘의 시간 복잡도는 일반적으로 $O(n^2)$ 이지만, 더 효율적인 구현으로 $O(n \log n)$이 가능함 - 메시지 복잡도는 각 라우터가 자신의 상태를 방송하는 횟수와 관련이 있음 - 한 소스에서 방송 메시지를 보내기 위해 $O(n)$ 의 링크를 교차함 - 각 라우터의 메시지는 $O(n)$ 의 링크를 교차하기 때문에 전체 메시지 복잡도는 $O(n^2)$ - **oscillations 문제** - link cost가 트래픽 양에 따라 변할 경우, 경로 선택이 변동될 수 있음 - 네트워크 안정성에 영향을 미침 **distance vector 알고리즘** ![[Network Layer - Bellman-Ford Example.png|center|600]] - **Bellman-Ford(BF) 방정식**에 기반한 동적 프로그래밍 - 각 노드는 주기적으로 자신의 거리 벡터($D_v$) 추정치를 이웃에게 보냄 - 노드 x가 이웃으로부터 새로운 $D_v$ 추정치를 받으면, Bellman-Ford 방정식을 사용해 자신의 $D_v$를 업데이트함 - $D_x(y) \leftarrow \min_v \{c_{x,v} + D_v(y)\}$ for each node $y \in N$ - $D_x(y)$: x에서 y까지의 최소 코스트 - 자연스러운 조건 하에서, $D_x(y)$ 의 추정치는 실제 최소 비용 $d_x(y)$ 로 수렴함 - **반복적이고 비동기적인 업데이트** - **지역 link cost 변화 혹은 이웃으로부터의 $D_v$ 업데이트 메시지를 받으면 이를 활용해 라우팅 정보를 업데이트하고, 지역 $D_v$ 를 재계산함** - **어떤 목적지로 가는 $D_v$가 변경되면 이웃에게 알림** - **distributed, self-stopping** : 변경 사항이 있으면 이웃에게 알림, 이웃도 필요한 경우에만 이웃에게 알림, 알림을 받지 않으면 아무런 행동도 취하지 않음 - 좋은 소식은 빠르게 전파되고, 나쁜 소식은 천천히 전파됨 - **긍정적인 변경**(좋은 소식)은 네트워크 상의 다른 노드들이 바로 수용하고 반영할 수 있음. 예를 들어, 새로운 경로가 더 저렴하거나 빠른 경우, 노드들은 이를 즉시 받아들여 업데이트함 - **부정적인 변경**(나쁜 소식)은 네트워크 상의 다른 노드들이 이전의 정보를 계속 사용하려는 경향이 있기 때문에 천천히 전파. 경로의 비용이 증가하거나 링크가 끊어지면, 노드들은 새로운 경로를 찾기 위해 더 많은 시간을 필요로 함. 이 과정에서 잘못된 정보가 여러 번 교환되며, 전체 네트워크에 반영되기까지 시간이 걸림 - **count-to-infinity 문제** : 네트워크에서 경로의 비용이 증가하거나 링크가 끊어지는 등의 부정적인 변경 사항이 전체 네트워크에 반영되는 데 시간이 오래 걸림 - **라우팅 루프 발생 가능** : 네트워크에서 패킷이 목적지에 도달하지 못하고 동일한 경로를 반복해서 순환하는 문제 ![[count-to-infinity 문제.png|center|500]] **link state vs distance vector** - **메시지 복잡도** - LS : n개의 라우터, $O(n^2)$ 메시지 전송 - DV : 이웃 간의 교환; 수렴 시간은 다양함 - **수렴 속도** - LS : $O(n^2)$ 알고리즘, $O(n^2)$ 메시지 - oscillations 문제 - DV : 수렴 시간 다양 - 라우팅 루프 가능성 - count-to-infinity 문제 - **견고성(robustness)** - LS : 라우터가 잘못된 링크 비용을 광고할 수 있음, 각 라우터는 자신의 테이블만 계산함 - DV : **DV 라우터가 잘못된 경로 비용을 광고할 수 있음** (“나한테 어디든지 매우 낮은 비용 경로가 있음” : black-holing), **각 라우터의 테이블이 다른 라우터에 사용됨: 오류가 네트워크 전체에 전파됨** ### 2-1. intra-ISP routing **라우팅을 확장 가능하게 만들기** - 지금까지는 모든 라우터가 동일하고 네트워크가 플랫하다는 이상적인 가정 하에 라우팅 방법을 고민함 - 실제로는 확장성과, 관리의 자율성 문제에 부딪힘 - scale : 모든 목적지를 라우팅 테이블에 저장할 수도 없고, 커질수록 저장 및 교환이 어려워짐 - administrative autonomy : 각 네트워크 관리자가 자신의 네트워크에서 라우팅을 제어하고 싶은 경우도 있을 수 있음 - **인터넷의 확장 가능한 라우팅을 위한 접근법** - 라우터(네트워크)를 AS, autonomous systems 또는 “도메인”으로 알려진 지역으로 나눠서 묶음 - **intra-AS(도메인 내)** : 같은 AS 내에서의 라우팅 - AS 내의 모든 라우터는 동일한 intra-domain 프로토콜을 실행해야 함 - 다른 AS의 라우터는 서로 다른 intra-domain 라우팅 프로토콜을 실행할 수 있음 - **gateway 라우터**: 자신의 AS 가장자리에 위치하며 다른 AS의 라우터와 연결됨 - **inter-AS(도메인 간)** : AS 간의 라우팅 - 게이트웨이는 내부 라우팅과 외부 라우팅을 모두 처리함 - 포워딩 테이블은 intra-AS 및 inter-AS 라우팅 알고리즘에 의해 구성됨 - intra-AS 라우팅은 AS 내 목적지, intra-AS&inter-AS 같이 외부 목적지에 대한 엔트리를 결정함 **Intra-AS routing** - **intra-domain 포워딩에서의 역할** - 주변 AS를 통해 어떤 목적지에 도달할 수 있는지 학습해야 함 - 이 도달 가능성 정보를 본인 AS의 모든 라우터에 전파함 - **가장 일반적인 intra-AS 라우팅 프로토콜** - **RIP**: 고전적인 DV(Distance Vector) 알고리즘, DVs는 30초마다 교환됨 - 오버헤드가 커서 더이상 사용되지 않음 - **EIGRP**: DV 기반, 시스코 내부에서 사용되는 프로토콜 (2013년에 개방형 표준이 됨) - **OSPF**: link-state 라우팅 사용 **OSPF (Open Shortest Path First) 라우팅** - 공개적으로 사용 가능한 프로토콜 - **클래식한 link state 라우팅 방법** - 각 라우터는 OSPF link-state advertisements(LSA)를 네트워크 내의 모든 다른 라우터에게 브로드캐스트함 (TCP/UDP 대신 직접 IP를 통해 이루어짐) - multiple link cost 지표가 가능함 (대역폭, 딜레이 등) - 각 라우터는 네트워크의 전체 토폴로지를 가지고 있으며, 다익스트라 알고리즘을 사용하여 포워딩 테이블을 계산함 - 모든 OSPF 메시지는 인증되어 악의적인 침입을 방할 수 있음 - **Hierarchical OSPF** - 네트워크가 커짐에 따라 모든 라우터가 전체 토폴로지를 알고 있는 것은 비효율적일 수 있음 - 따라서, OSPF는 **계층적 구조**를 도입하여 네트워크를 로컬 영역과 백본으로 나눔 - **각 로컬 영역 내에서만 LSA를 전파하고, Area Border Routers가 영역 간의 정보를 요약하여 백본을 통해 교환함** - LSA는 해당 영역이나 백본에서만 브로드캐스트됨 - 각 노드는 자신의 영역 내의 상세한 토폴로지를 가지고 있으며, 다른 목적지에 도달하기 위한 방향만 알고 있음 - **Area Border Routers** : 자신의 영역 내 정보를 요약하여 백본에 광고하고, 백본을 통해 다른 영역과의 경로 정보를 교환함 - **Local Routers** : 자신의 영역 내에서만 라우팅을 관리하며, 외부로의 패킷은 영역 경계 라우터를 통해 전달 ![[Network Layer - Hierarchical OSPF.png|center|600]] ### 2-2. Internet inter-AS routing - **Border Gateway Protocol** : 도메인 간 라우팅 프로토콜 (“인터넷을 묶어주는 접착제” 역할) - BGP는 서브넷이 자신의 존재와 도달 가능한 목적지를 인터넷에 광고할 수 있게 해줌 - **BGP가 각 AS에 제공하는 기능** - **eBGP** (외부 BGP): 이웃 AS로부터 서브넷 도달 가능 정보(reachability information) 획득 - **iBGP** (내부 BGP): 도달 가능 정보를 모든 AS 내부 라우터에 전파 - 도달 가능 정보와 정책에 기반하여 다른 네트워크로 가는 “좋은” 경로 결정 ![[Network Layer - BGP session.png]] - **BGP session** : 두 BGP 라우터(피어)가 반영구적 TCP 연결을 통해 BGP 메시지를 교환함 (물리적 연결이 아님) - 서로 다른 목적지 네트워크 프리픽스로 가는 경로를 광고함 (BGP는 **path vector 프로토콜**임) - e.g. AS3의 게이트웨이 3a가 AS2의 게이트웨이 2c에게 AS3,X 경로를 광고하면, AS3는 AS2에게 X로 가는 데이터그램을 전달할 것임을 약속함 - AS2의 라우터 2c가 AS3의 라우터 3a로부터 AS3,X 경로 광고를 수신하면, AS2의 정책에 따라 AS3,X 경로를 수락하고, 이를 AS2의 모든 라우터에 전파함(iBGP) - AS2의 라우터 2a는 AS2의 정책에 따라 AS2,AS3,X 경로를 AS1의 라우터 1c에게 광고함(eBGP) - **BGP 광고 경로** : prefix + attributes - prefix : 광고되는 목적지 - attributes : **AS-PATH**(prefix 광고가 통과한 AS들의 리스트), **NEXT-HOP**(다음 홉 AS로 가는 특정 내부 AS 라우터를 나타냄) 속성을 통해 경로를 정의함 - **경로 정보에 포함된 AS-PATH를 통해 경로 루프를 방지함** - **policy-based routing** - 정책 기반으로 경로 광고를 수락하거나 거부하며, 이를 다른 AS에 광고할지 여부를 결정함 - **BGP 메시지** - BFP 메시지는 TCP 연결을 통해 피어 간에 교환되고, 이를 통해 경로 정보를 관리하고 연결을 유지함 - e.g. OPEN(연결 열고 인증 수행), UPDATE(새로운 경로 광고 or 이전 광고 철회), KEEPALIVE(연결 유지, 요청 확인), NOTIFICATION(이전 메시지 오류 보고, 연결 종료) **왜 intra-AS와 inter-AS 구분할까?** - inter-AS는 정책에 따라 트래픽을 관리하며, intra-AS는 성능에 집중함 - 계층적 라우팅은 테이블 크기를 줄이고, 업데이트 트래픽을 감소시킴 (네트워크 확장성 유지) **Hot Potato Routing** ![[Network Layer - Hot potato routing.png|center|600]] - Hot potato routing은 **내부 도메인(intra-domain) 비용이 가장 적은 로컬 게이트웨이를 선택하는 방식**을 말함 - **예시**: 라우터 2d가 iBGP를 통해 목적지 X로 가는 경로를 2a 또는 2c를 통해 선택할 수 있다고 배운다고 가정함. 이때, 2d는 **inter-domain(도메인 간) 비용을 고려하지 않고**, intra-domain(도메인 내) 비용이 더 적은 2a를 선택함. 따라서 더 많은 AS 홉이 필요할지라도, 2d는 2a를 통해 라우팅함 **더 많은 정보** - 일반적으로 ISP는 자신의 고객 네트워크로의 트래픽만 라우팅하고, 다른 ISP들 간의 중계 트래픽을 처리하지 않기를 원함 - **BGP 경로 선택 기준** - 정책 결정에 기반한 로컬 선호도 값, AS-PATH가 가장 짧은 경로, 가장 가까운 NEXT-HOP 라우터(Hot potato routing) 등등 ### 2-3. 라우팅 알고리즘 비교 | **특징** | **Link State 라우팅** | **Distance Vector 라우팅** | **Path Vector 라우팅** | | -------------- | ------------------ | ----------------------- | ------------------- | | **대표 프로토콜** | OSPF, IS-IS | RIP, EIGRP | BGP | | **정보 교환 방식** | 네트워크 전체 상태 | 이웃 라우터와 거리 벡터 | AS 간 경로와 경로 속성 | | **정보 수집 범위** | 네트워크 전체 토폴로지 | 이웃 라우터로부터 | AS 경로(AS-PATH) | | **경로 계산 방식** | 다익스트라 알고리즘 | Bellman-Ford 알고리즘 | 정책 기반 경로 선택 | | **경로 갱신 빈도** | 이벤트 기반, 빠름 | 주기적 또는 이벤트 기반, 느림 | 이벤트 기반 | | **루프 방지 메커니즘** | 전체 토폴로지 인식 | 거리 벡터 비교 | AS-PATH를 통한 루프 방지 | | **장점** | 빠르고 정확한 경로 계산 | 구현이 간단, 계산이 용이 | 확장성, 정책 기반 경로 선택 | | **단점** | 높은 메모리 및 CPU 사용 | 느린 수렴 시간, 루프 가능성 | 복잡한 정책 설정 | | **확장성** | 제한적 | 제한적 | 매우 높음 | | **복잡성** | 높은 복잡성 | 낮은 복잡성 | 중간 복잡성 | | **사용 사례** | ISP 내부, 대규모 네트워크 | 소규모 네트워크, 역사적 사용 | 인터넷 전역, AS 간 라우팅 | **link state ** - **방법** - 각 라우터는 자신과 직접 연결된 모든 링크의 상태 정보를 수집하여 **네트워크 전체에 방송함** - 모든 라우터는 수집한 LSA 정보를 기반으로 네트워크의 전체 토폴로지를 나타내는 **데이터베이스를 구축**함 - 각 라우터는 네트워크 전체 토폴로지를 알고 있으므로, **다익스트라 알고리즘**을 사용하여 자신을 출발지로 하는 최단 경로 트리를 계산하고, 이를 바탕으로 포워딩 테이블을 생성함 - **특징** - **전체 네트워크 정보**: 각 라우터는 네트워크의 전체 구조를 알고 있음 - **정확하고 신속한 업데이트**: 링크 상태 변화가 발생하면 네트워크 전체에 신속하게 반영됨 **distant vector ** - **방법** - 각 라우터는 자신과 직접 연결된 이웃 라우터들에게 자신의 **거리 벡터**(각 목적지까지의 거리 정보)를 **주기적으로 전송**함 - 각 라우터는 이웃으로부터 받은 거리 벡터 정보를 사용하여 자신과 각 목적지 간의 최단 경로를 업데이트함. 이 과정에서 **Bellman-Ford 방정식**을 사용함 - 경로 정보가 변경되면 이웃 라우터들에게 다시 알림 - **특징** - **부분적인 네트워크 정보**: 각 라우터는 직접 연결된 이웃 라우터들과의 정보만 알고 있음 - **점진적 업데이트**: 네트워크 변화가 있을 때 정보가 점진적으로 전파되며, 전체 네트워크가 업데이트되기까지 시간이 걸릴 수 있음 **path vector ** - **방법** - 각 라우터는 목적지 네트워크까지의 경로와 해당 경로를 거치는 AS들의 목록(AS-PATH)을 유지함 - 라우터는 자신이 알고 있는 경로 정보를 이웃 AS에 광고함 - 정책에 따라 경로를 수신한 라우터는 AS-PATH에 자신을 추가한 후 다음 이웃 AS에 경로를 광고함 - **특징** - **확장성**: 경로 정보가 AS 단위로 요약되므로, 인터넷과 같은 대규모 네트워크에서 효과적으로 동작함 - **루프 방지**: AS-PATH를 통해 경로 루프를 방지할 수 있음 - **정책 유연성**: 각 AS는 자체 정책을 통해 경로 선택을 조절할 수 있음 ## 3. SDN control plane **전통적인 라우팅 vs SDN** - 전통적인 인터넷의 network layer는 분산된, 라우터별 제어 방식으로 구현됨 - monolithic 라우터는 스위칭 하드웨어와 독점 라우터 운영 체제를 실행함 - 방화벽, 로드 밸런서, NAT 박스 등 다양한 네트워크 계층 기능을 수행하는 서로 다른 미들박스가 존재함 - 각 라우터의 개별 라우팅 알고리즘 구성 요소들이 control plane(제어 평면)에서 상호작용하여 포워딩 테이블을 계산함 - **SDN에서는 원격 컨트롤러가 라우터의 포워딩 테이블을 계산하고 설치함** = logically centralized - 네트워크 관리가 더 쉬워짐 : 라우터의 잘못된 설정을 피하고, 트래픽 흐름의 유연성을 높임 - 테이블 기반 포워딩(OpenFlow API)을 통해 라우터를 “프로그래밍”할 수 있음 - 중앙 집중화된 프로그래밍이 더 쉬움 : 테이블을 중앙에서 계산하고 배포함 - 분산프로그래밍에서는 모든 라우터에서 구현된 분산 알고리즘(프로토콜)의 결과로 테이블을 계산해야 하기 때문에 어려움 - control plane의 개방형(비독점, non-proprietary) 구현: 혁신 촉진, 많은 새로운 아이디어들이 등장하도록 유도함 - SDN은 수직 통합된 폐쇄적, 독점적, 혁신이 느린 소규모 산업(특화된 OS, 앱 등등)에서 수평적인 개방형 인터페이스로 변화, 빠른 혁신, 거대한 산업으로 이어짐 **전통적인 라우팅 방법에서는 어려운 Traffic engineering** ![[Network Layer - 전통적인 라우팅 방법에서는 어려운 Traffic engineering.png|center|400]] - **네트워크가 특정 경로를 따라 흐르기를 원하는 경우**, 링크 가중치를 재정의하여 트래픽 라우팅 알고리즘이 경로를 계산하도록 해야 함. 아니면 새로운 라우팅 알고리즘이 필요함 - 링크 가중치가 유일한 제어 방법임: 제어할 것이 많지 않음 - 네트워크 운영자가 u에서 z로의 **트래픽**을 uvwz와 uxyz로 **분할**하고 싶어도 방법이 없음. 아니면 새로운 라우팅 알고리즘이 필요함 - w가 z로 가는 트래픽을 다르게 라우팅하고 싶어도 할 수 없음 (목적지 기반 포워딩과 LS, DV 라우팅에서는 불가능) → generalized forwarding and SDN을 사용하면 모두 해결 가능! **SDN** ![[Network Layer - Software defined networking (SDN).png|center|500]] - **특징** - generalized “flow-based” 포워딩(e.g. OpenFlow) 사용 - control plane과 data plane의 분리 - control plane 스위치 외부에 control plane function이 존재함 - 프로그래머블한 제어 애플리케이션 ![[Network Layer - Software defined networking (SDN) layer.png|center|250]] - **SDN 컨트롤러의 동작 방식** - **Data-plane switches** - 빠르고 간단한 상용 스위치, 하드웨어에서 일반화된 data plane 포워딩 구현 - 컨트롤러 감독 하에 계산되고 설치된 플로우(포워딩) 테이블 - 테이블 기반 스위치 제어를 위한 API, 컨트롤러와 통신하기 위한 프로토콜 (e.g. OpenFlow) - **SDN controller (network OS)** - 네트워크 state 정보 유지 - 위쪽 API를 통해 네트워크 제어 애플리케이션과 상호작용 - 아래쪽 API를 통해 네트워크 스위치와 상호작용 - 성능, 확장성, 오류 내성을 위한 분산 시스템으로 구현 - **network-control apps**\ - 제어의 “두뇌”: SDN 컨트롤러가 제공하는 하위 서비스와 API를 사용하여 제어 기능 구현 - 분리되어 있음: 제3자에 의해 제공 가능, 라우팅 벤더나 SDN 컨트롤러와 독립적임 ![[Network Layer - Components of SDN controller.png|center|500]] - **SDN 컨트롤러의 구성 요소** - **네트워크 제어 애플리케이션을 위한 인터페이스 계층**: - **네트워크 전체 상태 관리**: 네트워크 링크, 스위치, 서비스의 상태를 관리하는 분산 데이터베이스로 구성됨 - **통신**: SDN 컨트롤러와 제어되는 스위치 간의 통신을 담당함 - **OpenFlow 프로토콜** - TCP를 통해 컨트롤러와 스위치 간의 통신을 담당함, 선택적으로 암호화를 사용함 - 세가지 클래스의 메시지를 사용함 - **controller-to-switch 메시지** - 스위치 기능 조회, 구성 설정, 플로우 엔트리 수정, 특정 포트로 패킷 전송 - **비동기 메시지 (switch to controller)** - 패킷 전송, 플로우 엔트리 삭제, 포트 상태 변경 알림 - 네트워크 운영자는 직접 OpenFlow 메시지를 생성하거나 전송하지 않고, 컨트롤러에서 더 높은 수준의 추상화를 사용함 - **대칭 메시지** - OpenFlow API와 구별됨: API는 일반화된 포워딩 동작을 지정하는 데 사용됨 ![[Network Layer - SDN control,data plane interaction example.png|center|300]] - **control/data plane 상호작용 예시** : 링크 장애 시 컨트롤러가 새로운 경로를 계산하고, 필요한 스위치에 업데이트된 테이블을 설치함 1. S1에서 링크 장애 발생 시 OpenFlow 포트 상태 메시지를 사용하여 컨트롤러에 알림 2. SDN 컨트롤러가 OpenFlow 메시지를 수신하고 링크 상태 정보를 업데이트함 3. 이전에 링크 상태 변경 시 호출되도록 등록된 다익스트라 라우팅 알고리즘 애플리케이션이 호출됨 4. 다익스트라 라우팅 알고리즘이 컨트롤러의 네트워크 그래프 정보와 링크 상태 정보를 사용하여 새로운 경로를 계산함 5. 링크 상태 라우팅 애플리케이션이 SDN 컨트롤러 내의 플로우 테이블 계산 구성 요소와 상호작용하여 필요한 새로운 플로우 테이블을 계산함 6. 컨트롤러가 OpenFlow를 사용하여 업데이트가 필요한 스위치에 새로운 테이블을 설치함 - **OpenDaylight 및 ONOS 컨트롤러**: 내부 및 외부 애플리케이션과 서비스를 연결, 고수준의 서비스 사양 제공, 분산 코어 중점 - **SDN의 주요 과제** - 제어 평면 강화, 신뢰성 및 보안성 내재화, 특정 요구 사항 충족, 인터넷 확장성, 5G에서의 중요성 ## 4. Performance - 상위 계층 레이어가 기대한 만큼 네트워크 레이어가 완벽하지는 않음 - 네트워크의 성능은 **delay(지연 시간), throughput(처리량), packet loss(패킷 손실)**를 지표로 평가할 수 있음 - 성능 향상을 위해 congestion control은 아주 중요한 문제임 ### 4-1. delay, 지연 시간 **Transmission Delay** - 패킷을 송신자가 송신 매체로 전송하는 데 걸리는 시간 - 송신자가 패킷의 비트를 하나씩 라인(transmission media)에 올리는 데 필요한 시간 - 패킷의 첫 번째 비트를 시간 ${t}_{1}$에 라인에 올리고 마지막 비트를 시간 ${t}_{1}$에 올린다면, 패킷의 전송 지연은 $({t}_{2} - {t}_{1})$ - **패킷의 길이와 링크의 전송 속도**에 따라 결정됨 - $\text{Delay}_{tr} = \frac{\text{packet length}}{\text{transmission rate}}lt;/mark>   즉, 패킷 길이 / 전송 속도 - $\text{Delay}_{tr}$ 단위는 sec - $\text{packet length}$ 단위는 bits - $\text{transmission rate}$ 단위는 bits/sec **Propagation delay** - 패킷이 송신지에서 수신지로 이동하는 데 걸리는 시간 - 진공에서의 전파 속도는 $3×10^8 \text{m/sec}$ 이며, 유선 매체에서는 일반적으로 이보다 낮음 - 신호가 물리적 매체(예: 광섬유, 구리선)를 통해 이동하는 속도(**전파 속도**)와 **전송 거리**에 따라 결정됨 - $\text{Delay}_{pg} = \frac{\text{distance}}{\text{propagation speed}}lt;/mark>   즉, 거리 / 전파 속도 - $\text{Delay}_{pg}$ 단위는 sec - $\text{distance}$ 단위는 m(미터) - $\text{propagation speed}$ 단위는 m/sec **Processing delay** - 라우터나 스위치가 패킷을 처리하고 다음 hop으로 전송하기 전에 내부적으로 처리하는 데 걸리는 시간 - 패킷의 헤더를 검사하고, 오류를 확인하고, 라우팅 경로를 결정하는 데 걸리는 시간 - 일반적으로 이 시간은 매우 짧아서 평균값이나 작은 상수 값으로 두고 계산함 - $\text{Delay}_{pr} = \text{time required to process a packet in a router or a destination host}$ **Queuing delay** - 패킷이 라우터나 스위치의 출력 큐에서 대기하는 데 걸리는 시간 - 네트워크 트래픽이 많아지면 패킷이 큐에 쌓이고, 이로 인해 패킷이 전송되기 전에 대기하는 시간이 발생함 - 네트워크 혼잡도에 크게 영향을 받음 - 가장 예측하기 어려운 delay - $\text{Delay}_{qu} = \text{time a packet waits in input and output queues in a router}$ **Total delay** - 송신자, 라우터, 수신자의 지연이 동일하다고 가정하면, 패킷이 출발지에서 목적지까지 도달하는 총 지연 시간을 계산할 수 있음 - 전체 경로에 있는 라우터의 수를 n이라고 하면, 전체 경로에는 n개의 라우터와 n+1개의 링크가 있음 - $\text{Total delay} = (n + 1) (\text{Delay}_{tr} + \text{Delay}_{pg} + \text{Delay}_{pr}) + (n) (\text{Delay}_{qu})lt;/mark> ### 4-2. throughput, 처리량 - 네트워크의 특정 지점에서의 처리량은 **해당 지점을 통과하는 초당 비트 수**로 정의됨 - 이는 해당 지점에서의 데이터 전송 속도를 의미함 - 출발지에서 목적지까지의 경로에서 패킷은 여러 링크를 통과할 수 있으며, 각 링크는 서로 다른 전송 속도를 가질 수 있음 - 전체 경로의 처리량은 **각 링크의 전송 속도 중 가장 낮은 값**을 경로의 처리량으로 간주함 - 이는 병목 지점이 전체 경로의 처리량을 결정하기 때문 - $\text{Throughput} = \min \{\text{TR}_{1}, \text{TR}_{2}, …, \text{TR}_{n} \}lt;/mark> ![[Network Layer - Figure 7.3 A path through the Internet backbone.png|center|600]] - 실제 인터넷 상황에서 데이터는 일반적으로 두 개의 액세스 네트워크와 인터넷 backbone을 통과함 - backbone = 여러 하위 네트워크를 서로 연결하는 중심적인 고속 네트워크 - 각 구간의 전송 속도는 다를 수 있으며, 전체 경로의 처리량은 이들 중 가장 낮은 전송 속도에 의해 결정됨 ### 4-3. packet loss, 패킷 손실 - 전송 중 손실되는 패킷의 수는 통신 성능에 영향을 미침 - **오버플로우**로 인한 packet loss, packet drop 발생 - 라우터가 다른 패킷을 처리하는 동안 새로운 패킷을 받으면, 그 받은 패킷은 입력 버퍼에 저장되어 자신의 순서를 기다려야 함 - 이때 버퍼의 크기는 제한적이라 버퍼가 가득 차면 새로운 패킷을 저장할 수 없고, 이 패킷은 버려지게 됨 - 손실된 packet을 재전송하는 과정에서 네트워크에 추가적인 부하가 걸리게 되고, 결과적으로 더 많은 패킷 손실이 발생할 수 있음