네트워크 레이어는 Data Plane과 Control Plane으로 나눌 수 있다.
이 글에서 라우터~Middleboxes는 주로 데이터 플레인에 대한 내용이다.
그 이후는 주로 컨트롤 플레인에 대한 내용이다.
네트워크 레이어는 세그먼트(segment)를 송신호스트에서 수신호스트로 전달하는 역할을 담당한다. 두 호스트의 행동을 자세히 기술하면 다음과 같다.
네트워크 레이어 프로토콜은 모든 인터넷 장치(호스트, 라우터)에 존재한다. 특히 라우터는 네트워크 레이어를 동작시키는 핵심 요소이다. 라우터가 하는 일을 개략적으로 살펴보면
즉, 전통적인 라우터는 데이터플레인과 컨트롤플레인을 모두 내장하고 있다. 새로운 라우터는 이와 다르게 데이터플레인만 가질 수도 있다. (컨트롤플레인의 역할은 원격지의 컴퓨터가 담당하므로)
네트워크 레이어는 대표적으로 두 개 역할을 수행한다.
여기서 컨트롤 플레인이 라우팅 알고리즘을 돌려 경로를 결정하고 나면(라우팅) 그 내용은 forwarding table에 기록된다. 데이터 플레인은 포워딩 테이블 내용을 살펴보고 가장 적절한 포트로 패킷을 내보낸다(포워딩).
인터넷 서비스 모델로 세 가지가 있다.
이 중 Intserv Guaranteed는 IP로는 실현이 어렵다. 로컬에서는 가능할 수 있겠으나 글로벌에서는 지원이 어렵다.
best-effort가 일반적인데 아래 특징이 있어 좋다/나쁘다를 쉽게 판단할 수 없다.
라우터는 input port -- fabric -- output port
/ routing processor
로 나누어 살펴볼 수 있다. (패브릭은 데이터가 옮겨다니는 라우터 내부로 생각하면 된다. 이름이 저런건 특별한 이유가 없다. 그냥 레거시이다.)
인풋포트의 구조를 살펴보면 아래와 같다.
+------------+ +-------+ +-------+
| line | ----> | link | ----> | queue | ---> (fabric)
| termination| | layer | | |
+------------+ +-------+ +-------+
인풋포트랑 반대로 생겼다.
+--------+ +-------+ +-------------+
| queue | ----> | link | ----> | line | ---> 바깥
| | | layer | | termination |
+--------+ +-------+ +-------------+
스위칭 패브릭이 내보내는 속도가 link transmittion rate보다 빠르면 큐잉한다.
링크 레이어는 일반적으로 이더넷이다.
라인 터미네이션은 디지털신호를 아날로그로 바꾼다.
스위칭 패브릭은 인풋으로 들어온 패킷을 실제로 아웃풋으로 보내는 동작을 한다.
NR
패브릭은 대표적으로 아래 세 가지 종류가 있다. 아래로 갈 수록 빠르다.
(interconnection network - cross bar)
인풋포트 1 --------+-------+-------+
| | |
인풋포트 2 --------+-------+-------+
| | |
인풋포트 3 --------+-------+-------+
| | |
아웃풋1 아웃풋2 아웃풋3
포트 포트 포트
인풋포트 큐잉과 아웃풋포트 큐잉이 발생할 수 있다.
큐잉을 하면 자연히 큐잉딜레이와 버퍼오버플로우에 따른 손실이 발생할 수 있다.
버퍼 크기를 정하는 일도 중요하다. 너무 많은 버퍼링은 지연을 증가시키기 때문이다. (예 : 긴 RTT가 주어지는 경우 리얼타임 앱의 응답성이 떨어진다) 아래와 같은 크기 결정 방법이 있다.
버퍼 공간은 유한하기 때문에 관리가 필요하다. 관리한다는 것은 아래 두 가지를 포함한다.
어떤 패킷을 먼저 제공할지 결정하는 것을 스케쥴링 한다고 표현한다.
각 줄은 4바이트이다.
IP 데이터그램의 필수 항목은 5줄이므로 헤더로 20바이트를 잡아먹는다.
이 단계에서 오버헤드는 다음과 같이 계산된다.
( TCP의 20바이트 ) + ( IP의 20바이트 ) + ( APP의 오버헤드 )
아래 포맷에서 header length와 데이터그램의 length는 바이트 단위이다.
<--------------------- 32 bits ------------------------->
<------------ 16 bits ---------->
+---------------------------------------------------------+
| ver | head len | service type | length |
+---------------------------------------------------------+
| idenfier | flags | fragment offset |
+---------------------------------------------------------+
| TTL | Upper layer protocol | header checksum |
+---------------------------------------------------------+
| source IP address |
+---------------------------------------------------------+
| destination IP address |
+---------------------------------------------------------+
| option |
+---------------------------------------------------------+
| payload |
+---------------------------------------------------------+
IP주소는 호스트나 라우터 인터페이스의 (일반적으로) 32-bit 식별자이다.
여기서 인터페이스란 호스트/라우더/피지컬링크 사이의 연결부를 뜻한다.
컴퓨터로 예를 들면 유선랜카드, 무선랜카드가 각각 인터페이스이다.
각 인터페이스는 각각 IP주소를 부여받는다.
서브넷은 전체 망의 부분망이다. 라우터 없이 통신 가능한 섬과같은 단위를 서브넷이라 할 수 있다. 각 서브넷은 네트워크의 IP주소를 갖는다. 이를 알기 위해서는 IP주소의 구조를 살펴보아야 한다.
/24
는 앞에서 24개 비트는 서브넷을 나타내는 비트(=subnet part)임을 의미한다. 마지막 8비트는 서브넷 내의 호스트를 나타내는 비트(=host part)이다. 이런 IP주소를 표현하는 체계가 두 가지 있다.
먼저 클래스 체계를 살펴보면 다음과 같다.
32-bit IP는 5개 클래스로 분류할 수 있다.
외부와 분리된 서브넷을 사설망이라고 부른다. 이 안의 호스트에는 사설(Private) IP를 부여할 수 있다. 정해진 그 구간을 나열하면 다음과 같다.
CIDR는 클래스에 구애받지 않고 네트워크부와 호스트부를 분할해 사용하는 기법이다. 예를 들면 아래와 같다.
Dynamic Host Configuration Protocol
호스트가 어떤 네트워크에 참여하면 그 안의 DCHP서버로부터 동적으로 IP주소를 할당받는다. 그 과정을 살펴보면 아래와 같다.
자신의 IP주소 외에도 호스트가 DHCP 서버로부터 얻을 수 있는 정보가 있다.
IP주소 구간(블록)의 할당은 ICANN 아래의 IANA가 담당한다.
5개의 RR(Regional registries)에게 IP블록을 주면, RR은 다시 지역 Registry에게 할당한다. 이 주소는 다시 그 아래의 고객들에게로 할당된다.
네트워크가 자신의 IP를 부여받으려면 ISP로부터 주소 공간을 할당 받아야 한다. 망 자체가 계층적으로 구성되어 있기 때문이다. 그림으로 나타내보면 각 기관 네트워크는 사실상 ISP의 부분망이다.
기관이 ISP를 다른 회사로 바꾸는 경우가 발생할 수 있는데, 이 때 네트워크 IP주소는 일반적으로 그대로 들고 간다. 이 경우 옮겨온 ISP가 인터넷에 advertising하는 내용이 바뀐다.
Network Address Translation
공인IP주소(인터넷)와 사설IP주소(내부망)를 서로 변환시켜주는 기능이다.
예를 들어 사설망 내에 100억개 컴퓨터가 있다고 하면, 이 100억개의 컴퓨터 각각에 공인 IP주소를 주는 대신 하나의 공인IP만 주고 외부망과 통신을 시켜버리는 것이다. 이것이 가능하도록 하기 위해 NAT를 둔다. 이러면 IP주소도 아끼고 보안상 이점도 얻을 수 있다.
NAT는 구체적으로 아래와 같이 동작한다.
그러나 NAT은 IP주소 고갈에 대한 근본적인 해결책이 아니다. NAT는 3층에서 동작한다. 그런데도 4층의 할 일인 포트 지정을 뺏어와 자기가 해버린다. 또, NAT없이는 외부에서 내부망 호스트에 접근할 방법도 없다. 그렇지만 이미 많이 쓰이고 있어서 어쩔 수가 없다. 아직까진 쓸만하니까 쓴다.
32-bit IPv4의 주소는 이미 고갈되었다. 표현상 없다는게 아니고 정말로 없다. 텍스트 그대로 다 할당해버렸다.
그래서 표현 가능한 주소의 범위를 넓히면서 네트워크 성능을 개선하기 위한 목적으로 IPv6가 연구되고 사용되고 있다.
IPv4의 데이터그램 포멧과 비교해보면 checksum, fragmentation/reassembly 정보, option항목이 없다.
|<------------- 32 bits ------------>|
+------------------------------------+
| ver | priority | flow label |
+------------------------------------+
| payload len | next hdr | hop limit |
+------------------------------------+
| source address (128-bit) |
| |
+------------------------------------+
| destination address (128-bit) |
| |
+------------------------------------+
| payload |
+------------------------------------+
IPv6으로 언젠가 넘어가기는 해야하는데 당장 IPv4의 사용을 중단할 수다. IP는 수많은 네트워크 요소를 떠받치는 인프라와 같은 존재이기 때문이다. 그래서 전이 과정의 대응책으로 Tunneling을 사용한다. 터널링은 IPv4패킷의 페이로드에 IPv6패킷을 통째로 박아 전송하는 것이라 요약할 수 있다.
라우터는 크게 세 가지로 나누어볼 수 있다.
아래와 같이 라우터와 IPv4네트워크가 배치되어 있다고 하자.
라우터 1에서 4로 어떤 정보를 전달하고 싶다면 터널링이 필요하다.
1 2 3 4
IPv6만 -- 둘 다 ---( IPv4 네트워크 )--- 둘 다 -- IPv6만
ㄱㄴ ㄱㄴ ㄱㄴ ㄱㄴ
앞서 라우터의 input port 부분에서 두 가지 포워딩 방식이 있음을 살펴보았다.
포워딩 방식 중 destination-based forwarding의 경우 Longest prefix matching이라는 방법으로 IP주소를 이용해 나갈 포트(링크 인터페이스)를 결정한다.
포워딩 테이블은 아래와 같이 주소 범위에 대해 내보낼 포트 번호가 기록되어있다. (편의를 위해 8-bit IP를 쓴다고 가정하자)
도착지 주소 범위 | 아웃풋포트 번호 |
---|---|
0000 0000 ~ 0000 1111 | 0 |
1100 0000 ~ 1100 1111 | 1 |
1101 0000 ~ 1111 1111 | 2 |
위 테이블은 아래와 같이 주소 범위를 prefix로 다시 나타낼 수 있다.
*이 아닌 숫자 부분이 prefix이고, 이 부분을 도착지 IP주소와 비교한다.
도착지 주소 프리픽스 | 아웃풋포트 번호 |
---|---|
0000 **** | 0 |
1100 **** | 1 |
11** **** | 2 |
0000
와 비교되어 0번 포트로 나간다.1100
과 11
두 개이다. 하지만 더 긴(Longest) 1100
을 적용해 1번 포트로 나간다.longest prefix matching은 TCAMs(ternary content addressable memories) 를 사용해 수행되는데, 이 기술은 테이블 사이즈가 몇이든 1클럭사이클에 아웃풋 포트를 결정한다. TCAMs을 쓰는 시스코 제품으로 Cisco Catalyst가 있다.
match + action : 들어오는 패킷의 비트와 그에 대한 액션을 매칭시켜놓은 것. 프로그래밍 가능한 네트워크의 간단한 형태이다.
앞서 살펴본 forwarding table은 flow table이라고도 부른다.
일반화된 포워딩을 구성하는 packet-handling 규칙은 다음과 같다.
일반화된 포워딩의 대표적인 예시가 OpenFlow이다. 오픈플로우에서 flow table의 엔트리는 다음과 같이 구성되어있다.
여기서 OpenFlow는 match, action에 다른 값을 줌으로써 아래의 네 가지 역할을 모두 수행할 수 있다. match+action의 개념 자체가 추상적이기 때문이다.
RFC 3234 : any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host
NAT, 방화면, IDS, 로드 밸런서, 캐시서버 등은 모두 미들박스이다.
네트워크의 지능부는 중간보다는 끝단에 구현되는 것이 좋다고 말한다.
링크
The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)
3층 IP는 어느 곳에나 있으므로 간단하게 구현되어야 하지만 현대 네트워크는 3층에 많은 기능을 추가했다. (NAT, 방화벽, NFV, 캐싱, ...)
근본적으로는 모두 SDN으로 해결되어야 할 문제이다.
과거 전화만 있던 시절에는 네트워크의 지능이 중앙(전화국)에만 있엇다.
그러나 현재는 네트워크 그 자체도, 끝단도 지능을 가지고 있는 상황이다.
여기부터 Control Plane에 대한 내용을 주로 적는다.
라우팅 프로토콜의 목표는 라우터를 통해 송신 호스트에서 수신 호스트로 이르는 좋은 경로를 찾는 것이다. 좋은 경로는 판단 기준에 따라 달라진다. 어느 조직에서는 가장 비용이 적은 것이 좋을 수 있고, 어느 조직에서는 돈이 얼마가 들든 빠른 것이 좋은 경로일 수 있다. 이런 경로는 송신-수신 호스트 사이 라우터의 나열로 표현할 수 있다.
라우팅 알고리즘의 분류 기준
LS는 global, centralized 알고리즘이다. (Dijkstra)
DV는 local, decentralized 알고리즘이다. (Bellman-Ford)
벨만포드 방정식 에 기초한다.
라우터의 포워딩 테이블은 상기 두 분류의 라우팅 알고리즘에 의해 결정된다.
BGP(Border Gateway Protocol)는 사실상 Inter-domain routing의 표준 프로토콜이다.
BGP는 eBGP와 iBGP로 구성된다.
BGP 메시지의 종류는 아래와 같다.
BGP advertised routes는 아래 항목으로 구성된다.
BGP상의 라우터는 Policy-based routing을 한다.
AS의 내부 라우터는 Hot potato routing을 사용할 수 있다. 이는 전체 경로 거리에 관계없이 Domain내 비용이 가장 작은 로컬 게이트웨이를 선택하는 방법이다.
컨트롤러와 스위치 사이에서 동작하는 프로토콜. TCP로 메시지 교환.
OpenFlow메시지는 세 가지 종류가 있음
Internet Control Message Protocol
네트워크 레벨 정보를 주고받기 위해 호스트, 라우터가 사용.
3층이긴 한데 IP보다 위에 있다.
udp 세그먼트 셋을 전송한다.
1번째 셋은 TTL=1, 2번째 셋은 TTL=2, n번째 셋은 TTL=n
라우터는 TTL Expired이면 데이터그램을 버리고 source로 ICMP 메시지를 전송. 메시지를 받은 source는 RTT 기록.
TTL이 도착지까지 가기 충분해져서 도달 하면 동작을 멈춤.
Autonomous System(Network)는 수많은 장비의 집합.
네트워크를 관리한다는 것은 아래 내용을 포함
네트워크 관리자가 각 장비를 관리할 수 있는 접근법은 아래와 같음
SNMP는 프로토콜. MIB는 관리용 데이터베이스. SMI는 데이터 정의어.
NETCONF : SNMP의 단점 보완. NETCONF의 문법은 YANG이 정의
YANG : NETCONF와 함께 쓰이는 데이터 모델링 언어