3.라우팅(포워딩, 링크상태 라우팅, Autonomous System, OSPF, 도메인간 라우팅, 도메인내 라우팅, BGP, CIDR, 방송형라우팅, 멀티캐스트 , MBONE, Mobile 네트워크의 라우팅, AD HOC 네트워크의 라우팅, 혼잡제..

3.라우팅

인터넷의 확장성

등장 배경은 인터넷 속도의 확장성이다.
TCP/IP 프로토콜은 1960년대에 만들어진 오래된 기술이다. 당시의 네트워크 속도에 비해 현재 인터넷은 수백 Gbps으로 동작하며 접속된 컴퓨터 수도 수억대에 이른다.
그러나 지금까지도 TCP/IP가 잘 동작하고 있으며 확장성이 좋은 핵심 이유는 두 가지를 들 수 있는데, 첫 번째는 IP 프로토콜이 단순하다는 것과 라우팅 프로토콜이 확장성이 매우 좋다는 것이다.
통신 전송 속도가 빨라져서 효과적으로 처리 속도가 길어졌지만 인터넷은 잘 동작하고 있다.
또한 인터넷에 연결된 라우터의 수가 급격히 늘어나도 안정적으로 인터넷이 동작하고 있다.
더불어 통신 링크가 끊어지거나 라우터가 고장이 나더라도 전체 인터넷은 중단 없이 동작할 수 있게 되었다.
이와 같이 네트워크의 확장성(scalability)과 안정성(robustness)에 대하여 좋은 이유가 바로 단순한 IP 프로토콜이다.

라우팅 개요

라우팅이란 패킷을 목적지까지 전달하는 빠른 경로를 찾아주는 직업이다.
경로란 중간에 거치는 노드(라우터)들의 연속적인 집합이다. 빠른 거리는 물리적인 Km로 표현되는 거리 또는 시간을 말하는 것이 아니라 중간에 경유하는 라우터의 개수 즉, 홉 수로 표현한다.
이렇게 단순히 홉 수만 측정하느 이유는 실제 전송되는 시간을 측정하기가 어렵기 때문이다. 또 다른 이유는 전파 지연에 가장 큰 영향을 주는 것이 경유하느 라우터의 수이기 때문이다.

라우팅 동작

먼저 라우팅 동작을 간단히 살펴보겠다. 아래에 가상의 네트워크를 나타냈는데 A, B..F는 라우터를 나타내고 라우터를 연결하는 링크에 기록된 숫자는 이 링크를 지나가는데 소요되는 코스트를 나타낸다.

링크의 코스트란 패킷이 이 링크를 지나가는데 걸리는 시간을 말하며 위에서는 임의의 값을 배정하였다.
예를 들어 라우터 C에서 라우터 F로 전송한 패킷이 가장 빨리 전달될 수 있는 경로를 찾아보자. 그림을 보면 라우터 B와 F를 거치는 것이 최적인것을 알 수 있으며 이 때의 전체 코스트는 7이 된다.
그러나 실제로 라우터 C에서 패킷을 처음에 송신할 때에 이 패킷이 B와 F를 차례로 거쳐서 전송되어야 한다는 것을 모두 미리 알고 있는 것이 아니라 자신은 처음에 B로 전송하는 것이 최적의 선택이라는 사실만을 알고 있다.
다음에 B는, A가 아니라, E로 전달하는 것이 목적지 F를 찾아가기 위한 최적의 선택이라는 사실만 알고 있으면 되는 것이다.
즉, 각 노드에서는 자신이 패킷을 넘겨줄 최적의 인접 노드(이 노드를 next-hop이라고 부른다.)가 어느 것 인지만 판단하면 된다.

라우팅과 포워딩

앞에서 설명한 라우팅이 이루어지려면 각 라우터는 목적지를 찾아가기 위한 최적의 경로를 알고 있어야 하는데, 최적의 경로를 찾아내기 위해서 라우팅 알고리즘이 사용된다.
예를 들어 라우터는 패킷이 도착할 때마다 매번 라우팅 알고리즘을 수행하는것이 아니라 어느 경로가 최적일지를 미리 준비해 두어야 한다.
이렇게 라우팅 알고리즘으로 미리 얻은 라우팅 정보를 정리해 둔 것을 라우팅 테이블이라고 한다.
라우팅 테이블을 참고하여 패킷을 목적지와 가장 가까운 인접 노드(next hop)와 연결된 링크로 내보내는 동작을 포워딩(forwarding)이라고 한다.
포워딩 동작 순서는 다음과 같다. 만일 라우팅 테이블에서 적절한 인접노드 정보를 찾지 못했으면 이 패킷을 디폴트 라우터로 보낸다.
디폴트 라우터는 테이블에 정보가 없을 경우(한 번도 가보지 않은 곳이라는 의미) 새로운 길을 찾아주는 곳으로 이해하면 된다. 예를 들어 내가 북극의 어디 이상한데에 접속할려 그러는데 한 번도 접속 해보지 않았을 경우 디폴트 라우터로 패킷을 보내 새로운 길을 찾는다.

이 그림은 라우팅 테이블을 나타내는 그림이고 해석의 예시를 하나 들자면 target의 의미는 내가 보낼 호스트이고 next hop은 target을 보내기 위한 어떤 IP를 사용할지 보여주는 것이다. target뒤에 있는 24는 24비트를 사용한다는 의미이다. 또한 앞에 24비트만 확인한다는 의미이기도 하다. direct는 자기에게 보내는 것이므로 자신의 네트워크로 보낸다는 의미이다.

먼저 같은 네트워크에 있는 호스트로 패킷을 전달하는 경우로서 호스트1이 호스트 2로 패킷을 전달하는 동작을 알아보겠다. 호스트 1은 목적지 주소로 호스트2의 IP 주소인 1.0.0.2를 기록하여 전송한다.
호스트1은 먼저 자신의 라우팅 테이블에서 목적지 주소와 정확하게 일치하는 루트가 있는 지를 확인하게 되는데(라우팅 테이블의 항목을 루트라고 한다), 호스트1의 라우팅 테이블을 보면 목적지 주소와 정확하게 일치하는 루트가 없다.
그러나 라우팅 테이블의 첫 번째 항목을 보면 1.0.0.0/24로 되어 있는데 이것의 의미는 목적지 주소의 앞부분 24비트를 비교하여 1.0.0.0과 같으면 이 항목이 원하는 루트라는 것을 말한다.
1.0.0.2의 앞부분 24비트를 비교하면 1.0.0.0과 일치하므로(비교하지 않는 부분은 0으로 처리) 이 첫 번째 항목이 바로 원하는 루트 정보가 되며 이 루트를 이용하여 패킷을 인터페이스 'a'를 통해서 forwarding한다.
참고로 라우팅 테이블 항목에서 /24의 의미는 network-prefix 부분이 24비트라는 것을 말한다. 즉, 목적지 IP 주소의 24비트의 크기만 비교하여 이 항목과 같으면 같은 네트워크에 있는 것으로 판단한다.
다른 네트워크에 있는 호스트로 패킷을 전달하는 예로 호스트1이 호스트3에게 패킷을 전달하는 경우를 보겠다.
호스트1은 패킷의 목적지 주소에 2.0.0.1을 써서 전송한다. 호스트1은 라우팅 테이블에서 이 패킷이 디폴트 라우터로 전달되어야 한다는 것을 알고(라우팅 테이블에 없기 때문) 인터페이스 'a'를 통해서 패킷을 라우터1로 전달한다.
이 때 라우팅 테이블의 두 번째 항목이 사용되었는데 0.0.0.0/0의 의미는 0 비트 크기만 비교하여 0.0.0.0과 같은지를 찾는 것으로 모든 임의의 IP 주소는 항상 이 항목이 원하는 루트가 될 수 있기 때문이다.(/0의 의미는 하나도 비교하지 않는다는 뜻)
라우터1에서도 같은 작업이 이루어져 이 패킷은 인터페이스 'c'를 통해서 라우터2로 전달될 것이다.
라우터2는 라우팅 테이블 참조해서 이 패킷이 자신의 링크에 연결되어 있는 호스트로 가는 패킷임을 알게 되며(테이블의 두 번째 항목을 이용)이 패킷을 인터페이스 'b'를 통해 전송하면 된다.

라우팅 테이블 항목

라우팅 테이블의 항목(entry)은 각 호스트를 찾아가는데 필요한 정보가 들어 있으며 이를 경로(route) 정보라고 한다.
그런데 모든 목적지 호스트를 각각 찾아가는 루트 정보를 모두 가지고 있으려면 라우팅 테이블의 크기가 매우 커져서 다루기가 불가능해진다.
따라서 루트 정보를 호스트 별로 기록하는 것이 아니라 netid 부분만 처리하면 된다. 이렇게 해도 되는 이유는 우선 패킷을 목적지 호스트가 접속되어 있는 네트워크까지만 전달하면 목적지 네트워크 내에서는 라우터가 ARP 등을 이용하여최종 호스트로 패킷이 전달될 수 있기 때문이다.
라우팅 테이블의 각 항목(루트)은 다음과 같이 네 가지 요소로 구성된다.

루트의 구성요소

Target

Prefix-Length

Next Hop

Interface

각 루트에서 32 비트의 IP 주소 중에 실제로 라우팅을 하는데 사용되는 주소 부분의 크기를 Prefix-Length라고 한다.
예를 들어 netid 크기가 24비트인 클래스 C의 IP 주소를 대상으로 루트 정보를 표현할 때에는 Prefix-Length 24가 된다.
라우팅 테이블에서 어떤 목적지를 찾아가는 루트를 찾을 때에는 이 Prefix-Length 크기만 비교하여 이 부분이 일치하면 원하는 루트정보를 찾은 것으로 처리하는 것이다.
루트를 찾기 위해서 라우팅 테이블에서 목적지 주소가 Target인 루트를 찾으면 된다. 일치하는 루트를 찾았으면 해당 루트의 Next Hop 노드로 패킷을 전송하기 위하여 Interface 링크로 패킷을 보내면 된다.
Next Hop에 Target으로 가는데 거쳐야 할 인접 노드의 주소가 적혀있다. 한편 다행히 목적지인 Target이 Next hop 라우터와 같은 네트워크에 직접 연결되어 있을 수도 있는데 이때는 Next Hop에 목적지가 직접 연결되어 있다는 표시로 directly가 나타난다.
라우팅 테이블의 각 루트를 표현하는 데에는 다음과 같이 세 가지 방법이 있다.
- 1)host-specific 루트: Prefix-Length로 32 비트를 사용하여 유일한 호스트 주소에 대한 루트 정보를 표현하는 경우(다 확인하겠다는 의미)
- 2)network-prefix 루트: Prefix-Length 값이 1~31로 목적지 주소 중에 netid 부분만을 사용하여 루트 정보를 표현하는 경경(표시 된 수치 범위까지만 확인하고 찾아간다는 의미)
- 3)default 루트: Prefix-Length 값이 0인 경우로 모든 목적지를 찾아가는데 이 루트가 사용될 수 있다.(찾을 수 없으니까 디포틀 라우터로 보낸다는 의미)
만일 한 목적지 IP 주소에 대하여 두 개 이상의 Target 주소가 일치하는 경우는 큰 값의 Prefix-Length 값을 갖는 루트를 선택한다.(이것을 largest matching prefix rule이라고 한다.)
이렇게 하는 이유는 더 상세한 정보를 먼저 우선순위에 두고 이용하기 위해서이다.

Target/Prefix-Length	Next Hop	Interface
100.100.100.99/32	라우터1	a
100.100.100.0/24	라우터2	a
0.0.0.0/0	라우터3	a

largest matching prefix 법칙을 다시 설명하며 먼저 host-specific 루트가 있는지를 찾아보고 이것이 없으면 다음에 network-prefix 루트를 찾아보며 network-prefix 루트도 없는 경우에는 디폴트 루트, 즉, 디폴트 라우터로 이 패킷을 전송한다.
인터넷에는 가능한 host-specific 루트를 사용하지 않고 network-prefix 루트를 사용하는데 이렇게 함으로써 모든 호스트 별로 라우팅 항목을 만들지 않고 따라서 라우팅 테이블을 최대한 간단히 할 수 있다.

라우팅 테이블 생성

실제로 패킷 forwarding을 할 때에는 라우팅 테이블을 직접 이용하지 않고 라우팅 테이블로부터 만든 "forwarding 테이블"을 이용한다.
정확히 말하면 forwarding 테이블과 라우팅 테이블은 같은 것이 아니다. forwarding 테이블에는 단순히 어떤 목적지 주소(즉, netid)를 갖는 패킷을 어떤 인터페이스로 내보내는지에 필요한 정보만을 가지고 있으며 라우팅 테이블은 이러한 forwarding 테이블을 만드는데 필요한 모든 정보를 가지고 있다.
라우팅 테이블의 각 항목 즉, 각 루트 정보는 다음과 같이 세 가지 방법에 의해 추가 또는 갱신될 수 있다.(라우팅에 문제가 생길수 있으므로..)

1)수동적으로 사람이 입력하는 경우

2)ICMP Redirect를 수신하여 자동으로 입력되는 경우

3)동적 라우팅 프로토콜에 의하여 라우팅 정보를 노드간에 서로 교환하는 경우

수동입력이란 네트워크 관리자가 라우팅 테이블에 루트 정보를 직접 입력하는 것을 말한다.
ICMP Redirect에 의한 라우팅 정보 갱신은 다음과 같다. 어떤 송신지 호스트에서 목적지를 찾아가기 위한 최적의 next-hop 주소를 잘못 알고 있다는 사실을(아니면 더 좋은 길을 찾았다든가)같은 네트워크에 있는 라우터가 발견하였을 때, 이 라우터가 송신지 호스트에게 최적의 next-hop 정보를 가르쳐주기 위하여 ICMP Redirect를 사용한다.
참고로 이 송신지 호스트와 라우터는 같은 네트워크에 있으므로 어떤 목적지에 대한 최적은 next-hop 노드의 주소는 같게 된다. 송신지 호스트는 ICMP Redirect 메시지를 받으면 자신의 라우팅 테이블을 갱신한다.
위의 두 가지 라우팅 테이블 갱신 방법보다 세 번째 방법이 기본적으로 사용된다. 즉, 인터넷에서는 라우터들이 서로 정보를 교환하여 라우팅 테이블을 자동으로 생성하는 방법이 기본적으로 사용된다.
이러한 방법을 동적(dynamic) 라우팅 프로토콜이라고 한다.

라우팅 알고리즘

목적지까지의 최단경로를 찾는 것은사실 불가능에 가깝다. 네비게이터에서 목적지까지 가능 최단 도로를 알려주는 것이 가능할까?
어느 한 순간에는 도로의 교통상황을 정확히 파악하고 여러 가능한 경로들을 비교해서 가장 빠른 길을 찾아낼 수 있을 것이다. 그러나 이는 그 순간에만 최적이다.
네트워크의 교통량은 시시각각 변한다. 5분후에는 길이 막히지 않는 곳으로 차들이 더 몰려와서 오히려 그곳이 더 막힐 수 있으므로 최적의 경로를 수시로 바뀌게 된다.
통신 트래픽도 마찬가지로 최적의 경로를 찾는 것은 어렵다. 또한 경로를 찾는 방법(알고리즘)이 복잡해서 시간이 너무 오래 걸리면 소용이 없다.
빠른 시간 내에 답을 얻을 수 있어야 한다.
라우팅은 기본적으로 최단 경로를(shortest path) 찾으며 시간측정으로는 홉수만을 따진다.(이미 눈깜짝하면 다음 라우터에 도착하므로 평가 기준의 의미가 애매함. 그래서 몇 라우터를 거쳐가는지 홉수를 따지는거다)
인터넷 라우팅 알고리즘 중 가장 대표적인 방식으로 거리벡터(distace vector) 라우팅과 링크상태(link state) 알고리즘을 소개하겠다.

Distance Vector 라우팅

거리백터 라우팅 알고리즘에서는 각 노드에서 목적지가 얼마나 멀리 떨어져 있는지를, 즉 거리가 얼마인 지를 평소에 파악해서 테이블로 저장해두는 방법이다.
이 거리백터 알고리즘은 RIP라는 이름으로 구현되어 인터넷 초기에 사용되었으나 지금은 사용되지 않는다.(거리는 의미가 없어졌음)

링크상태 라우팅

거리백터 알고리즘은 단순했으나 네트워크 구성이 변경되면 라우팅 테이블 수렴시간에 문제가 있었고, 네트워크 장애시에도 오동작을 하기가 쉬웠다.
현재 인터넷은 거리백터 알고리즘을 사용하지 않고 링크상태(link state) 라우팅 알고리즘을 사용한다.
거리백터 라우팅에서는 각 노드에서 다른 노드로 연결되는 거리정보를 전달했었다. 그런데 이 정보는 실제로는 아무런 검증이 되지 않은 매우 불확실한 정보였다.
이에 반하여 링크상태 라우팅에서는 각 노드가 인접한 노드 뿐 아니라 네트워크 내의 모든 노드들과 정보를 교환하되 자신이 직접 연결되어 있는 링크에 대한 "확실한 정보"만을 서로 교환한다
각 노드는 이렇게 얻은 여러 링크의 정보를 종합하여 각자 필요한 최적의 라우팅 테이블을 계산한다.
LInk sate 방식은 라우팅 경로의 결정 요소로 distance vector에서 이용하는 거리(홉 수)만이 아니라 지연 시간(delat), throughput, 안정도(reliability)와 같은 요소들을 고려함으로써 보다 최적화된 라우팅 구성을 할 수 있다.
링크 상태 라우팅은 먼저 각 노드가 가지고 있는 링크 정보를 효율적으로 공유하는 절차가 필요하고 각 노드에서 이 공유된 링크 정보를 이용하여 최적의 라우팅 테이블을 계산한게 된다.
구체적으로 다음과 같이 다섯 단계로 동작한다.

1)인접 라우터 파악: 라우터가 처음에 동작을 시작하면 자신과 연결되어 있는 주변 라우터 정보들을 수집한다. 모든 라우터는 고유의 이름을 가지고 있다.

2)코스트 측정: 자신 주변 링크의 정보를 알아낸다. 자기와 연결된 링크의 코스트를 측정한다. 예를 들면, 대역폭이 넓으면 코스트가 적은 것으로 설정할 수 있다.

3)LSP 작성: 링크 정보를 모든 노드에게 알리기 위해서 링크상태패킷(lisk state packet: LSP)을 작성한다.

LSP에는 자신의 고유번호, 순서번호, 각 링크별 코스트, Age 값 등을 기록한다.
LSP는 기본상 주기적으로 보내는데 가능한 메시지의 량을 최소화하며 보통 그 주기를 수 시간 단위로 크게 잡는다.
새로운 라우터 추가, 라우터의 고장 등 망 구성에 어떤 변화가 있을 때 보내기도 한다. 이 때 인접한 링크나 노드에 장애가 발생한 사실을 알내기 위해서는 확인 패킷을 주기적으로 인접 노드로 보내야 한다.

4)LSP 공유: LSP는 바르게 공유되어야 한다.

빠르고 확실한 LSP 배포를 위해서 flooding 방식을 사용한다. flooding방식에서, 각 라우터는 새로운 LSP를 받으면 인접한 라우터로 모두 복사하여 보낸다.
LSP를 수신한 라우터들은 순서번호를 보고 이 LSP 패킷이 새로운 것인지, 이미 받은 것이 중복되어 들어온 것이지를 파악한다. 새로운 LSP를 수신한 경우에는 이 LSP를 인접한 링크로 복사하여 전송한다.
단 이 LSP를 보내온 링크로는 다시 전송하지 않음으로써 패킷이 계속 늘어나는 것을 방지한다. 중복된 LSP는 전송을 하지 않는다. LSP를 수신한 라우터는 Ack를 보낸다.
flooding 방식에서는 오래된 LSP 정보가 네트워크에 계속 돌아다니는 것을 방지하기 위해서 Age 필드를 사용하는데 LSP를 사용하는데 LSP를 수신한 라우터는 이 AGE 값을 1초에 1씩 감소한다.(카톡에 1사라지는것을 생각해보자)
Age 값이 점차 감소하여 0이 되면 이 LSP는 이제 유효하지 않다고 판단하여 버리게 된다.

5)최단 경로 계산: 각 라우터는 네트워크 내의 모든 노드들이 보내온 LSP를 받았고 각 링크의 코스트를 사용하여 각 목적지를 향해 가려면 어느 링크로 나가는 것이 최단 경로인지를 계산할 수 있다.

이제 라우팅 테이블을 완성하게 된다. 최단 경로를 구할 때는 Dijkstra's 알고리즘을 사용한다.
실제로 인터넷에서는 링크 상태 기반 라우팅 프로토콜인 IS-IS(Intermediate System Intermediate System)과 OSPF가 널리 사용된다.

Autonomous System(AS)

앞에서 소개한 라우팅 알고리즘에서 링크상태 정보를 서로 교환하는 범위를 정해주는 것이 필요하다. 전세계 모든 라우터들이 서로 LSP를 교환하기에는 인터넷 규모가 너무 크다.
따라서 하나의 라우팅 알고리즘이 적용되는 범위를 정하였고 이를 Autonomous System(AS)이라고 한다.
AS란 하나의 관리 시스템에 의해 관리되는 범위의 네트워크를 말한다.
예를 들어 대학의 캠퍼스, 한 회사의 기관, ISP 사업가 관리하는 망 범위등이 하나의 AS를 구성하게 된다.
하나의 AS 내에서 최단경로를 찾아주는 라우팅을 도메인내(intradomain)라우팅이라고 한다. AS를 라우팅 도메인이라고 부른다. 도메인내 라우팅을 IGP라고도 부른다.
앞에서 소개한 링크상태 라우팅 알고리즘인 IS-IS나 OSPF가 사용된다.
그런데 임의의 장비를 연결시켜주려면 라우팅은 AS 사이의 라우팅을 지원해야 한다. 즉, 서로 다른 AS에 속한 장비들 간의 연결이 필요하다.
이러한 AS 간의 라우팅을 도메인간(interdomain)라우팅이라고 한다. 도메인간 라우팅을 EGP라고도 부르며 대표적인 라우팅 알고리즘이 BGP(Border Gateway Protocol)이다.

OSPF(Open Shortest Path First)

현재 가장 널리 사용되는 도메인내 라우팅 알고리즘 표준이다. 인터넷이 만들어진 초기에는 거리벡터 방식의 알고리즘인 RIP가 사용되었으나 네트워크의 규모가 커짐에 따라 RIP 동작에 한계가 나타났고, 1990년부터 링크상태 방식인 OSPF가 라우팅 알고리즘 표준으로 채택되었다.
한편 OSPF와 거의 유사한 기능으로서 IS-IS 라우팅 알고리즘이 있는데 이는 ISO 표준에서 제정된 라우팅 알고리즘 이름이다.
OSPF는 부하분산(load balancing) 기능을 제공하는데, 목적지를 향해서 가는 경로 중에 같은 비용이 발생하는 루트가 두 개 이상이 있으면 패킷을 한 경로로만 보내는 것이 아니라 다중 경로(multiple path)로 패킷을 보냄으로써 트래픽을 분산시켜준다.
즉, 같은 비용이 발생하는 여러 경로들로 균등하게 패킷을 전송하여 네트워크의 부하가 한 곳으로 물리지 않도록 하는 것이다. 이 때 사용된 다중경로를 ECMP(equal Cost Multi Path)라고 부른다.
OSPF는 어떤 노드가 고의로 또는 실수로 잘못된 링크 정보를 방송함으로써 네트워크 전체를 오동작시키는 것을 방지하기 위해서 라우팅 메시지의 인증 기능을 제공한다.
앞에서 하나의 AS가 라우팅이 이루어지는 단위라고 했는데, 경우에 따라서는 AS도 규모가 너무 커서 라우팅하기가 어려울 수 가 있다. 수백 ~ 수천개의 라우터를 대상으로 최적의 경로를 찾는 것은 복잡하기 때문이다.
OSPF에서는 이렇게 규모가 너무 큰 AS를 다시 작은 단위인 지역(area)으로 나누고 각 지역에서만 라우팅을 최적화하는 방법을 사용한다.
이렇게 함으로서 서로 라우팅 정보를 교환하는 라우터의 개수를 줄여 통신량과 저장할 링크 정보의 크기를 줄일 수 있다.

AS의 여러 지역(area) 중에 하나를 백본 구역으로 저장하고 이 백본을 경유하여 모든 지역들이 서로 연결되도록 해야 한다.
위에서는 area0이 백본 지역이다. 백본 지역 내에 있는 라우터들을 백본 라우터라고 하며 특히 주변의 지역들을 연결하는 관문 역할을 하는 백본 라우터를 Area Border Router(ABR)라고 부른다.
R1, R2, R3가 ABR이다. ABR 들은 지역들간의 패킷 전달을 책임지다.
각 지역내에서 라우팅은 OSPF 알고리즘으로 동작한다. 한 지역에서 다른 지역으로 패킷을 전송하려면 반드시 백본 지역을 경유하여야 하며 이에 필요한 라우팅 정보는 백본 지역에서 관리한다.
즉, 각 지역에서는 내부의 라우팅 테이블만 작성하고 관리하며 이 라우팅 테이블을 ABR 들이 대표로 서로 공유하여 지역간의 패킷 전송시에 활용하는 것이다.
이렇게 지역이라는 단위로 나누어 처리함으로써 링크상태 정보는 각 지역 내부에서만 서로 주고 받으면 되고 지역 간에는 정리된 최종 결과 라우팅 테이블만 교환하면 되므로 전체적인 통신량을 줄일 수 있게 된다.
즉, AS 전체를 대상으로 링크상태 정보를 AS 내의 모든 라우터들이 서로 직접 교환하지 않아도 되게 한 것이다.
지역을 사용하면 트래픽을 줄이는 편리한 점도 있으나 하나의 AS내에서 임의의 두 지점간에 최단 경로를 찾는 것은 보장할 수 없다.
한편 지역 개념을 사용하면 트래픽을 줄이는 장점외에도 AS의 크기가 계속 확장되더라도 전체적인 라우팅이 복잡해지지 않고 원만하게 동작한다는 장점이 있다. 즉 네트워크의 확장성(scaleability)이 좋아진다

도메인간(interdomain) 라우팅

앞에서 설명한 도메인 내(interdomain)라우팅은 하나의 AS 내부에서 이루어지는 라우팅이엇다. 도메인내 라우팅의 목적은 최단경로를 찾는 것이었다.(도메인내와 도메인간의 차이점 중요)
인터넷에는 다수의 AS들로 구성되 있으므로 AS 사이의 라우팅이 필요하다. 이렇게 다수의 AS를 연결하는 라우팅을 도메인간(interdomain) 라우팅이라고 한다.
궁극적으로는 인터넷 전체를 대상으로 라우팅을 하려면 AS 내부적인 도메인내 라우팅 뿐 아니라 AS 사이를 연결해주는 도메인간 라우팅이 필요하다.
대표적인 도메인간 라우팅 프로토콜로는 BGP(Border Gateway Protocol)가 있다.
도메인내 라우팅에서는 가장 중요한 목표는 호스트 사이에 전달 코스트를 최소화하기 위한 최적의 경로를 찾는 것이었지만, 도메인간 라우팅에서는 이러한 최적화가 목적이 아니고 패킷이 목적지까지 안전하게 도달할 수 있는지의 도달성(reachability) 제공을 목표로 한다.
Interdomain(도메인간) 라우팅에서는 AS(라우팅 도메인)자체를 하나의 라우팅 단위로 취급한다. 즉, 하나의 AS를 하나의 domain으로 취급한다.

BGP

BGP는 TCP상에서 전달되는 메시지 방식으로 운영되며 최적의 빠른 경로를 찾는 것이 아니라 정확히 연결되는 경로를 찾는 기능을 제공(이게 도메인간 라우팅임)한다. BGP에서는 어떤 AS들을 경유하여 목적지와"연결이 가능한지"의 여부 정보만 제공한다.
BGP에서 각 AS에서는 BGP speaker로 동작할 노드를 하나 지정해야한다.
BGP speaker 노드는 해당 AS 내에 있는 네트워크들에 대한 도달성(reachabilty)정보를 방송하는(대변하는) 기능을 담당하는데 도달성이란 이 AS 내부에 또는 이 AS를 경유하여 어떤 네트워크를 찾아갈 수 있는지를 알려주는 것을 말한다.
BGP speakek 노드는 다른 AS의 BGP speaker들과 정보교환을 하기 위해서 BGP 세션(세션의 의미는 통신이 가능한 상태를 유지한다는 의미이다)을 형성하고 있어야 한다. 각 AS는 또한 border gateway역할을 하는 라우터를 하나 이상(한 개가 망가질 때를 대비해서) 지정해두어야 하는데 border gateway는 이 AS에서 외부로의 통신을 담당하는 즉, AS 사이의 통신을 담당하는 라우터를 말한다.
BGP에서는 목적지까지 가는데 어떤 AS들을 거쳐서 가게 되는지를 목록을 알려준다.
이렇게 하는 이유는 라우팅 정책에 맞게 경로가 설정되었는지를 확인하기 위해서이고 또한 경로상에 혹시 루프가 생기는것을 방지하기 위해서이다.
중간에 경유하는 AS목록을 AS Path라고 하는데, AS path 상에 어떤 AS의 주소가 두 번 들어가 있다면 종점간 경로에 루프가 생긴 것이다.

CIDR(Classless Interdomain Routing)

일반적으로 라우팅 테이블의 크기는 작을수록 좋다. 왜냐하면 새로운 패킷이 들어올 때마다 라우터들은 라우팅 테이블을 찾아봐야 하기 때문이다.
다수의 인접한 네트워크를 찾아가기 위한 루트를 한 항목으로 묶어서 처리하는 라우팅 방식이 가능한데 이를 CIDR(Classless Inerdomain Routing)라고 한다.
수십 또는 수백 개의 클래스 C 주소를 관리하는 기관에서는 각 클래스 C 네트워크 별로 루트를 정하면 라우팅 항목의 수가 많아지는데 이런 경우에 인접한 netid 주소를 가지고 있는 네트워크들을 그룹으로 처리하여 라우팅 테이블의 크기를 줄이는 것이다.
이를 aggregate(묶다) route 라고도 부른다.
예를 들어 16개의 인접한 클래스 C 규모의 네트워크를 묶어서 라우팅하는 경우를 살펴보자.
클래스 C 주소의 netid는 24비트이므로 인접한 16개의 클래스 C네트워크 주소를 표현하는데 하위의 4비트를 사용하고 있을 것이다. 따라서 24비트 netid 중에 상위의 20 비트가 이 "16개로 구성된 대형 네트워크(이를 supernet 이라고 부른다)"를 나타내는 주소라고 볼 수 있다.
이렇게 함으로써 netid의 상위 20비트를 대상으로 하나의 루트 항목만 만듬으로써 라우팅 항목의 수를 16개가 아니라 하나로 줄일 수 있는 것이다.
이와 같이 netid의 일부인 20 비트의 주소만 사용하는 것은 클래스 B도 아니고 클래스 C 주소도 아니므로 classless 주소(기존의 A,B,C,D 묶는 방식을 무시해서 이런 이름을 지었다)라고 부른다. 이때는 prefix를 /20 으로 지정해야 한다.

위와 같은 영국내 대학의 주소들이 CIDR로 라우팅되는 것을 보였다. 한편 미국에서 영국으로 건너갈 때에는 위의 3개 대학의 주소를 모두 묶은 더 큰 규모의 CIDR가 가능하며 이때는 /19 prefix를 사용하면 된다.
서브네팅에서는 하나의 네트워크 주소를 다수의 서브네트워크로 나누어 쓰는 것이 목적이었다면, CDIR은 이와 반대로 다수의 네트워크 주소들을 하나로 묶어서 처리함으로써 라우팅 테이블 항목 수를 줄인 것이다.
DIR은 서브네팅의 반대 개념으로서 CDIR의 원래 이름은 supernetting이었다. CDIR작업을 주소를 합하여 처리 한다고 하여 aggregation 이라고도 부른다.

방송형 라우팅

하나의 패킷을(특정 범위 내의) 모든 장비에게 동시에 전송하는 것을 방송(broadcasting)이라고 한다.
송신지는 수신장비들의 모든 주소를 알 필요가 없으며 패킷을 "한 번만" 전송하면 되므로 편리하다.
reverse path forwarding 알고리즘을 예로 들면, 패킷이 들어온 링크를 제외한 나머지 다른 링크들로만 방송 패킷을 전달한다.
같은 패킷을 한 번 받았던 노드는 더 이상 전송을 하지 않는다. 구현하기도 쉽고 효율적이라는 장점이 있다.

멀티캐스트

인터넷은 기본적으로 유니캐스팅으로 동작한다. 즉, 하나의 패킷은 한 목적지로만 전송된다.
이에 비해 멀티캐스트(multicast)는 한 패킷을 여러 목적지로 한 번에 전송하는 것을 말한다. 즉, 패킷 송신 작업은 한 번만 수행되지만 이 패킷을 여러 목적지에서 받을 수 있도록 인터넷 내부에서 복제 작업을하는 것이다.
참고로 방송(boroadcast)은 특정한 조건에 해당하는 대상 전체 예를 들면 같은 LAN에 속한 모든 장비에게 같은 패킷을 전달하는것을 말한다. 예를 들어 LAN에서 특정 IP 주소를 가진 호스트의 MAC 주소를 알기 위하여 사용되는 ARP 프로토콜에서는 ARP 요청 메시지를 "방송"하여 해당 호스트를 찾았다.(축구 중계를 예로 들면 축구 영상을 1개만 보내고 도착하면 도착한 곳에서 복사해서 준다는 의미이다.)
이더넷처럼 매체를 공유하는 네트워크 내에서는 방송을 하거나 멀티캐스트를 하기가 용이하다.
왜냐하면 한 번 전송된 패킷이 모든 네트워크 가입자에게 자연스럽게 전달될기 때문이다. 그러나 라우터들이 패킷을 하나씩만 전달하도록 설계되어 있으므로, 즉 , 유니캐스트로 동작하므로, 방송이나 멀티캐스트를 하려면 별도의 프로토콜을 필요로한다.
중계방송을 하거나 동시에 복사본 데이터를 여러 곳으로 보내는 상황에서는 분명 멀티캐스트가 편리할 것이다.
왜냐하면 보내는 동작을 한 번만 하면 라우터들이 필요한 곳에서 필요한만큼씩만 복사본을 만들어 목적지로 보내주기 때문이다. 즉, 목적지의 분포에 따라, 패킷의 복사가 필요한 라우터에서만 패킷이 복사되어 전송되면된다.
같은 메시지를 받으려면 "멀티캐스트 그룹"에 가입해야 하는데 멀티캐스트 그룹은 멀티캐스트 패킷을 받기를 희망하여 미리 등록된 호스트들의 집합을 말한다.
각 멀티캐스트 그룹은 클래스 D의 주소를 고유의 멀티캐스트 주소와 포트번호를 배정 받아서 사용한다.
인터넷에서는 멀티캐스트를 지원하기 위해서는 IGMP 프로토콜을 만들었다. 어떤 호스트가 멀티캐스트 그룹에 가입하려면 먼저 인접한 멀티캐스트 라우터에게 IGMP 메시지를 보내어 자신이 멀티캐스트 그룹에 가입된 사실을 알리고 이 멀티캐스트 라우터는 또 다른 라우터들에게 이 정보를 연속하여 알려준다.
임의의 호스트가 이 멀티캐스트 그룹 주소로 패킷을 전송하기만 하면 이 그룹에 속하는 모든 호스트가 패킷을 수신하도록 중간의 라우터들이 복제 작업을 해야 한다.
특정 멀티캐스트 그룹에 가입된 목적지로만 복사하여 보내야 하므로 각 라우터는 그룹별 소속 호스트 정보를 알고 있어야 한다. OSFP를 개선하여 목적지에 해당하는 곳으로만 패킷을 전달하는 방식인 MOSPF(Multicast OSPF) 프로토콜이 제안되었다.
그런데 실제로 인터넷에서는 멀티캐스트를 거의 활성화시키지 않는다. 왜냐하면 멀티캐스트 그룹을 만들고 관리하는 작업이 매우 복잡하여 네트워크에 많은 트래픽을 유발하기 때문이다.
각 라우터가 모든 멀티캐스트 그룹에 대한 정보를 알고 있어야 하고 이 라우팅테이블 내용이 수시로 변경될 수 있기 때문에(그룹에서의 새로운 가입 및 탈퇴로 인하여) 멀티캐스트 라우팅 테이블을 유지하는 것이 매우 어렵다.
사용자 입장에서는 멀티캐스트가 편리하겠지만 네트워크는 여러 곳에 패킷을 보내려면 차라리 유니캐스트로 패킷을 일 대일로 보내도록 하는 것이 더 단순하고 관리가 쉽다.(카카오가 이러한 일대일 작업을 해주는것이다.)

기타 라우팅

MBone

MBone은 앞에 설명한 멀티캐스트 라우팅 알고리즘을 사용하지 않고 "턴널링"을 이용하는 멀티캐스트 방식이다.
MBone에 참가하고 있는 라우터들이 서로 턴널링으로 일 대 일로 연결되어 있는 상태로 동작한다.
MBone에 참가하는 라우터들만을 연결된 별도의 멀티캐스트 네트워크를 구성함으로서(다른 프로그램을 돌린다는 의미) 다른 일반 라우터들이 모두 멀티캐스트 라우팅 기능을 가지고 있지 않아도 멀티캐스트가 동작하도록 하는 것이다.

Mobile 네트워크의 라우팅

단말기가 수시로 이동하는 상황에서의 라우팅을 말한다. 대표적인 예는 노트북이나 소형 정보기기를 들고 이곳저곳을 돌아다니는 상황이다. 현재는 스마트폰의 보급으로 이동시의 네트워킹 문제가 대부분 해결되었다. 주변의 라우터를 통해서 인터넷에 연결되는 것이 아니라 전화가입망을 통해서 일대일 접속이 이루어진다. 또는 주변의 LAN을 통해서 접속한다.

AD HOC 네트워크의 라우팅

라우터 위치가 고정되어 있지 않고 움직이는 상황에서의 라우팅을 말한다. 예를들어, 전장, 비상시의 임시 네트워크, 바다에서 함장들간의 통신 등 네트워크 토플로지가 변동하는 상황에서 필요한 라우팅이다.
무선으로 연결된 구성이 수시로 바뀔 수 있는 네트워크를 MANET(Mobile Ad Hoc Network)라고 부른다. 호스트가 불시에 탈퇴할 수도 있고 임의로 새로 가입될 수도 있어 망의 구성을 예측하기가 어렵다.

혼잡제어(매우 중요)

혼잡(congestion)이란 네트워크에 너무 많은 패킷이 유입되면 망에 부하가 걸리고 이로 인해 지연이 발생하거나 패킷 소실이 발생하는 현상을 말한다.
혼잡제어란(congestion control) 혼잡 현상을 피하도록 관리하는 것을 말한다.
혼잡제어를 하는 가장 효과적인 방법은 트래픽의 유입을 막는 것이며 이는 트랜스포트계층에서 다룬다.
마치 도로가 정체되면 이는 자동차들의 도로운행의 문제이지만 근본적으로는 차량의 도로 진입을 막아야만 혼잡제어가 되는 것과 같다. 즉, 효과적인 혼잡제어를 위해서는 네트워크 계층과 트랜스포트 계층의 협력이 필요하다.
혼잡제어는 네트워크 계층에서 처리하는 것보다 트랜스포트 계층에서 처리하는 것이 효과적이다. 왜냐하면 라우터는 인접한 라우터 간의 트래픽 제어밖에 할 수 없지만 트랜스포트 계층에서는 트래픽의 근원지인 종점 호스트에게 트래픽 발생을 줄이도록 요청할 수가 있기 때문이다.(판에 올라오기전에 싹을 잘라버리는거임)
즉, 일단 네트워크에 들어온 트래픽을 제어하는 것보다 네트워크에 들어오기 전에 트래픽을 제어하는 것이 효과적이므로 트랜스포트 계층의 혼잡제어가 더 중요하다.
혼잡제어는 특정 호스간의 원활한 통신을 제공하는 것이 목적이 아니라 망 전체의 동작을 원활하게 이루어지게 하기 위해서 필요한 조치이다. 특정 호스트간의 원활한 통신을 제어하는 것은 흐름제어(flow control)에서 다룬다.

collapse 현상

입력 트래픽이 망의 용량(커패시티)에 접근하면 네트워크의 처리율을 급격히 떨어지고 지연도 급격히 늘어난다.
이상적으로는 대역폭만큼 잘 처리되어야 하나 실제로는 그렇지 못한 것이 네트워크의 특징이다. 고속도로에 차가 어느정도 이상 들어오기 시작하면 정체가 되어 속도가 급격히 떨어지고 심지어는 거의 멈추어 서 있는 현상과 같다. 이러한 현산을 conjestion collapse 라고 한다.

큐잉지연

망에 정체가 생기는 근본 이유는 트래픽 발생이 균일하지 않기 때문이다. 비록 평균치는 아직 네트워크 커패시티 대역폭에 미치지 못하더라도 트래픽이 균일하지 못하고 버스트한 특성을 가지면 이러한 정체가 발생한다.
이를 수학적 모델에서는 큐잉 지연이라고 한다. 이렇게 트래픽 증가로 큐잉 지연이 커지고 따라서 망이 느려지면 트랜스포트 계층은 상대방으로부터 응답을 제시간 내에 받지 못하게 된다.
이로 인해 같은 데이터를 다시 재전송하게 되고 이것이 트래픽을 더욱 가중시켜서 혼잡이 급격히 늘어나는 현상이 바로 conjestion collapse이다. 이때는 지연이 급격히 늘어나서 망은 동작을 멈추게 된다.
라우터의 버퍼 크기를 크게 하더라도 혼잡 현상을 없앨 수 없으며 오히려 버퍼의 크기가 크면 혼잡이 더 심하게 발생한다. 이미 복사본이 재전송되었을수도 있으며 오래전의 패킷들이 전송될 때까지 계속 기다리기 때문이다.
패킷을 버리가나 입력 트래픽을 줄여서 근본적으로 트래픽을 줄여줄 대첵을 세워야 했는데 그래서 등장한게 흐름제어다.

흐름제어와 혼잡제어

두 가지는 개념이 다르다. 혼잡제어의 목적은 네트워크에 유입되는 트래픽이 확실하게 목적지로 전달되게 하는 것이다.
혼잡제어는 네트워크 여러 송수신지들의 집합을 대상으로 하는 전체적인 협력을 필요로 한다.
이에 비해 흐름제어는 특정한 두 지점간에 데이터가 원활이 전달되는 것을 다룬다.
송신지가 수신장치보다 빠르게 데이터를 전송하지 못하게 속도를 조절하는 것을 말한다.
혼잡제어가 필요하지 않은 상태에서도 흐름제어는 필요할 수 있다. 예를 들어 고속도로가 붐비지 않아도 특정 구간을 운행하는 고속버스 회사는 차량의 배치를 조절할 필요가 있는 것과 같다.
반대로 두 지점간에 흐름제어는 필요없지만 네트워크 전체로를 트래픽이 늘어서 트래픽을 감당할 수 없어서 혼잡제어가 필요하기도 한다.
추석명절에 각종차들이 고속도로에 돌아오면 도로는 매우 느리게 된다. 송신장비가 전송속도를 줄여야 하는 경우는 두 가지가 된다. 목적지의 요청에 의해서(흐름제어의 경우) 또는 네트워크 상태의 요청에 의해서(혼잡제어의 경우) 두 가지가 있다.

패킷 버림

그런데 현실적으로 congestion collapse이 발생할 가능성이 매우 높은데도 불구하고 실제로 인터넷이 다운되는 경우는 거의 없다. 이는 인터넷의 트랜스포트 프로토콜이 이를 잘 대처하도록 설계되었기 때문이다.
지연이 어느 정도 이상으로 커지게 되면 라우터는 패킷을 계속 버퍼링하는 것이 아니라 버린다. 즉, 패킷 손실(packet loss)이 발생한다.
이상적으로는 지연이 증가하기 직전까지만 대역폭을 사용하도록 허용하는것이 가장 좋을 것이다. 마치 고속도로가 정체되기 바로 직전까지 차들이 고속도로에 진입하도록 허용하는 것이 최대한 고속도로를 이용하는 것과 같다.
이 상황보다 더 이상 차가 들어오면 정체가 급격히 심해지기 때문이다. 이 시점을 알아내기 위해서 다음과 같은 파워 값을 측정한다.

power = load/delay

지연이 커지면 파워 값이 작아진다. 파워가 클수록 네트워크를 효율적으로 잘 이용하고 있는 것이다.
각 트랜스포트 계층 사용자들에게 대역폭을 어떻게 나누어 주는 방법이 좋을까? 균일하게 나누면 모든 사람들에게 공정할 것 같지만 네트워크 활용 측면에서 이는 비효율적이다.
일시적으로 통신을 하지 않는 트랜스포트 객체의 대역폭은 낭비되기 때문이다. 그러나 인터넷에서 사용자별로 일정한 대역을 보장해 주는 것이 어렵다.
둘째로, 장거리 링크를 사용하는 트랜스포트 계층은 결과적으로 더 많은 네트워크 지원을 사용하는 것이므로 공정하게 대역폭을 제공한다면 단거리 사용자에게 더 많은 대역폭을 배정해야 할 것이다. 그러나 이러한 관리는 매우 복잡하여 현실적이지 못하다.
어떤 링크를 여러 사용자가 공유할 때 각자 사용하는 대역폭을 공정하게 나눈다는 가정에서 출발하였다.
종점간에는 여러 링크를 경유하므로 중간에 어떤 링크에 의해서 사용 대역이 제한되면 비록 다른 링크에서 여유가 있더라도 가장 대역폭이 적게 배정된 곳의 제한을 받게 된다.
예를 들어 서울 부산간에 여러 링크를 거치는데 서울 - 대전 간에 트래픽이 많이 몰려서 종점간 대역폭이 제한을 받으면 비록 대구 - 부산 구간에 대역폭이 남더라도 더 이상 대역폭을 배정해도 의미가 없게 된다.
이런 상황을 max-min fair하다고 한다.
여러 TCP 연결을 설정하고 트래픽을 분산해서 보내는 방안이 있는데, 실제로 비트토렌트 같은 p2p에서는 이러한 방식으로 여러 피어들로부터 데이터를 나누어 받음으로써 파일 다운로드 속도를 높이고 있다.

대역폭 배정

혼잡제어의 기본은 네트워크 전체의 대역폭을 어떻게 사용자들에게 배정하는가이다.
마치 버스 전용차로를 만들어서 버스들이 원활하게 다니고 있는데, 만일 버스가 많아지면 버스 전용차로를 하나가 아니라 두 개를 배정할 수도 있는 것이다.
또는 버스 회사별로 고속도로에 들어올 수 있는 버스 댓수를 배정하는 방법도 가능할 것이다. 혼잡제어에서는 공정성을 위해서 여러 트랜스포트 객체들이 공정하게 네트워크를 사용할 수 있도록 대역폭을 배정하는 것이 필요하다.
혼잡제어의 기본인 대역폭 배정에서는 효율성과 공정성이 문제가 된다. 주어진 대역폭을 효율적으로 사용하되 사용자들 간에 불평등하지 않게 네트워크를 이용할 수 있게 해줘야 한다.
더욱이 사용자별로 사용하는 대역폭이 시시각각 변하므로 효율적이면서 공정한 대역폭 배정은 매우 어렵다. 그러나 최대한 노력을 하고 안정된 동작점으로 빨리 수렴하도록 하는 것이 필요하다.
기본적인 가정은 주어진 대역폭을 공정하게 나누어 쓰도록 하되 이를 빨리 처리해주는 방법이 필요하다.

전송속도 조절

혼잡제어 방법 중에서 트래픽 발생의 근본 원인인 송신측의 전송 속도를, 즉 데이터 유입속도를 제어하는 방법에 대해 알아보겠다.
송신측의 전송속도를 줄이게 되는 원인은 크게 두 가지인데, 첫 째는 앞에서 설명한 혼잡제어를 위해서 즉, 네트워크의 대역폭이 부족해서 트래픽을 줄이는 경우가 있다.
둘 째는 수신측이 데이터를 받는 속도가 느려서(버퍼가 작거나, 처리속도가 느려서) 송신속도를 줄여야 하는 경우이다.
후자를 흔히 흐름제어라고 한다. 트랜스포트 계층의 흐름제어는 윈도우 크기를 조절하는 방법으로 처리한다.
송신속도 조절 방법은 피드백을 어떤 형태로 받는지에 따라 달라진다.
피드백은 명시적인 것과 암시적인 것이 있고 정확도에서도 다양한 형태를 가질 수 있다. 먼저 명시적인 피드백을 이용하는 XCP(explicit Congestion Control)에서는 라우터가 송신속도를 지정하며, EXC(Explicit Congestion Notification)에서는 혼잡이 발생했다는 사실만 알려주며 송신속도를 명확히 지정하지는 않는다.
암시적인 혼잡제어 방법에서는 RTT를 측정하여 네트워크의 속도가 느려진 것을 간접적으로 파악하고 송신속도를 늦추는 방법이 널리 사용된다.
현재 인터넷에서 일반적으로 사용되는 암시적 방법으로는 패킷 손실율과 RTT를 모두 참고하여 네트워크가 혼잡한 것을 판단하는 방법을 사용한다.

AIMD

현재 널리 사용되는 혼잡제어 알고리즘은 AIMD(Additive Increase Multiplicative Decreas)이 있다.
AIMD에서는 대역폭에 여유가 있어 전송속도를 높일 때는 덧셈으로 속도를 높이고, 대역폭에 여유가 없어 전송속도를 줄여야 할 때는 곱셈으로(즉, 일정 비율로) 줄이는 것이다.
예를 들어 현재 전송속도가 1Mbps인데 속도를 높일 때는 한 번에 100Kbps씩 증가하여 1.1Mpbs(1.2 * 0.9), 다음에는 0.972Mbps 순으로 속도를 빠르게 줄여나가는 것을 말한다.
곱셈이 덧셈보다 변화율이 크므로 AIMD에서는 속도를 늘이는 것보다 속도를 줄이는 것을 더 빠르게 함으로써 네트워크가 더 안정적으로 동작하도록 한 것이다.
한편 혼잡제어를 위해서 송신측의 전송속도를 직접 변경하는 것보다는 윈도우 크기를 바꾸는 것이 같은 효과를 얻으면서도 구현하기가 더 쉽다. 즉, 혼잡제어를 마치 흐름제어처럼 운영하는 것이다. 이 경우에 윈도우 크기를 바꿈으로써 전송속도가 아래와 같이 바뀌었다고 볼 수 있다.

전송속도 = W/RTT

MPLS

서울에서 부산까지 버스를 타고 가는 상황을 가정해보자. 중간에 있는 대전과 대구에서 일단 버스를 세우고 어느 방향과 고속도로로 가야할 지를 다시 판단해야 한다고 해보자.
이것이 현재의 라우팅 방식과 같은 모델이다. 즉, 각 라우터에서 일단 패킷을 저장하고, 메모리에 헤더를 옮긴 후 헤더의 목적지 IP 주소를 보고 라우팅 테이블을 참고하여 패킷 포워딩을 한다.
이러한 처리 방식을 저장 후 전달(store - and - forward) 방식이라고 한다. 최근까지는 이러한 라우팅이 잘 동작했다.
예를 들어 서울 - 대전 또는 대전 - 대구 구간의 버스 운행시간이 2시간이라고 하고, 대전과 대구 터미널에서 잠시 버스를 세우고 방향을 찾는데 5분 걸린다고 하자.
두 시간에 비해 5분은 매우 짧은 시간이므로 터미널에서 소요되는 시간을 무시할 수 있었다.
그런데 고속도로와 버스의 성능이 엄청 좋아져서 서울 - 대전, 대전 - 대구 구간을 단 1분만에 갈 수 있다고 해보자, 그러면 5분은 상대적으로 매우 긴 시간이 되며 매우 빨라질 수 있었떤 교통망이 이 5분 때문에 엄청나게 느려지게 될 것이다.
인터넷이 처음 소개된 시절에는 네트워크의 통신 속도가 수십 kbps 였지만, 지급은 수십 Gbps로 동작한다.
백만배 이상 빨라졋다. 참고로 두 시간이 1분으로 빨라진 것은 경우 120배 빨라진 것이다.
여기에 비해 라우터에서 이루어지는 저장후 전달 방식의 처리 속도는 크게 개선되지 않았다. 왜냐하면 메모리에 헤더를 옮기고 헤더를 분석하는데 최소한의 시간이 필요하기 때문이다.
이러한 상황의 문제를 해결하는 좋은 방법으로, 이 버스가 부산을 가는 버스라는 표지를 버스 전면에 부착하게 하고 대전이나 대구 터미널에서는 버스를 세우지 말고, 버스가 지나가면서 바로 어떤 고속도로로 나가라고 지시를 해줄 수 있을 것이다.
예를 들어 터미널에서 5분 걸리던 주소분석 시간이 단지 버스가 지나가면서 판단만 하면 되므로 단 5초면 처리가 가능할 것이다.
MPLS(Multiprotoco Label Switching)는 바로 이런 원리로 동작한다.
라우터에서 패킷의 IP주소를 저장 후 전달 방식으로 분석하느라고 시간을 낭비하지 말고, 패킷에 추가로 목적지를 구분하는 표시 (Label)을 부착하고 MPLS 라우터에서는 이 패킷을 바로 포워딩해주는 것이다.
즉, MPLS는 통신망의 전송속도가 매우 빨라서 상대적으로 라우터가 느린 상황에서 필요한 방식으로, 고속통신망에서 장점이 드러난다. 또한 MPLS를 지원하는 라우터들간에만 동작한다.

MPLS의 동작

MPLS에서는 레이블 개념을 도입하였다. MPLS에서는 IP 주소 대신 각 패킷 앞에 있는 이 레이블을 보고 신속하게 포워딩이 바로 이루어진다.
패킷들은 MPLS를 지원하는 첫 번째 라우터에서는 레이블을 할당받고 이를 네트워크 내부에서 계속 사용하였다.
아래 그림처럼 MPLS 처리에 필요한 헤더는 IP 패킷 바로 앞에 온다.
즉, 링크 계층의 헤더와 IP 패킷 사이에 위치한다.(헤더이 길이는 4바이트이다.)

MPLS 헤더의 구성은 다음과 같다. 먼저 레이블은 20비트로 구성되며 하나의 연결을 구분하는 번호로 사용된다. 일종의 connection identification이다.
Qos(Quality of Service)는 서비스의 등급을 구분하는데 사용되고, S비트는 스택을 나타내며 레이블이 한 개가 아니라 두 개 이상 중첩되어 사용되는 지를 표시하는데 사용된다.
TTL은 이 패킷이 몇 번 더 라우팅될 수 있는지 홉 카운터를 나타낸다.
MPLS에 멀티프로토콜이라는 단어가 들어간 이유는 MPLS 프로토콜이 IP 패킷만 전달하는 것이 아니라 임의의 프로토콜을 사용하는 데이터를 전송할 수 있기 때문이다.
그 이유는 MPLS 헤더가 IP 프로토콜과는 무관하게 동작하기 때문이다.
MPLS는 물론 PPP 뿐 아니라 임의의 링크 계층 위에서 동작할 수 있다. 그 이유는 MPLS 헤더가 링크와 무관하게 별도로 배정되기 때문이다.
MPLS는 OSI 7 계층어디에도 속하지 않는 특별한 용도의 프로토콜이며 간혹 계층 2.5 프로토콜이라고도 부른다. 계층 3의 라우팅 기능의 성능을 향상시키기 위한 편법이라고 볼 수 있다.
MPLS 망의 가장 가장자리 (edge) 라우터에서 레이블을 최초로 붙여주고 MPLS 망의 마지막 단계의 가장자리 라우터에서 이 레이블을 삭제한다.
레이블을 부착하거나 제거하는 라우터를 LER(Label Edge Router)라고 한다. 한편 레이블이 삭제되더라도 IP패킷은 통상적인 방법으로 계속 라우팅 될 수 있으며 기존의 라우터들을 통과해서 최종 목적지까지 갈 수 있다.
MPLS는 고속으로 동작하는 코어망 즉, 네트워크 사업자 중간의 고속 네트워크에서만 사용되며 일반 가입자 라우터에서는 사용되지 않는다.

그림을 보면 첫 단계 이후 라벨이 붙쳐져 있는게 볼 수 있고 그렇게 빠르게 통신하다 라벨을 이해 못하는 라우터에 오면 라벨을 제거하고 IP로 인식해서 전송한다.

IPv6

현재 사용중인 인터넷 IP 프로토콜은 버전 4이며 IPv4라고도 표현한다. IPv4 IP 주소는 4바이트 크기를 사용하는데 4바이트로 표현할 수 있는 총 40억 개의 IP 주소를 현재 거의 다 배정하여 사용하고 있다.
물론 40억개의 IP 주소를 빈틈없이 모두 사용하는 것은 아니지만, 한 기관에서 사용하고 있는 주소의 남는 부분을 다른 기관에서 사용할 수 는없다.
더욱이 향후에는 컴퓨터 뿐 아니라 셋탑박스, 휴대폰 등 전자기기마다 IP 주소를 배정할 필요가 있을 것으로 예상되며 4 바이트 주소가 턱없이 부족할 것이다.
따라서 IP 주소 크기를 확대할 필요성이 절실하였으며 IP version 6, IPv6에서는 주소 크기를 128비트(16바이트)로 확장하여 정의하였다.
이 외에도 IPv6에서는 실시간 서비스 지원, 보안지원, 자동 환경 구성(IP 주소와 도메인 네임만으로 호스트의 통신 환경을 자동으로 구성해주 기능), 이동 라우팅을 포함한 라우팅 기능이 개선되도록 하였다.
IPv6를 도입하더라도 기존에 사용하던 IPv4용 장비들과의 통신 호환성을 유지해야 하므로 일정 기간동안에는 IPv6과 IPv4를 병행하여 사용할 수 있는 기간이 필요하다.
이러한 호환성을 위해서 dual stack operation과 tunneling 두 가지 기술이 제안되었다.
dual stack operation이란 IPv6을 구현하는 장비도 IPv4도 병행하여 구현해 두고 패킷의 헤더에 있는 버전 값을 보고 필요한 프로토콜 스택을 선택하여 처리하겠다는 것이다.
tunneling은 기존 IPv4 네트워크를 통해서도 IPv6 패킷을 전달하기 위한 방안으로, IPv6 패킷을 IPv4 패킷의 유료부하 부분에 실어서 전달하는 것을 말한다.

IPv6의 주소

IPv6에서는 128비트의 주소를 사용함으로써 IP 주소를 충분히 여유 있게 사용할 수 있다. IPv6에서는 IPv4와 달리 클래스 A, B, C 등의 클래스를 정의하지 않았더. 즉, netid와 hostid 같은 주소 구분이 없다.
현재의 IP 프로토콜에서 사용하는 4바이트 IP주소를 IPv6에서도 그대로 사용할 수 있게 하였다.

IPv6 패킷 구조

IPv6로 넘어갈 때라고 생각할 때에는 중요했는데 IPv4로 버티자고 한 뒤로 부터는 별로 중요하지 않은 개념. source address가 128비트인것만 기억하자

IPv6에서는 다양한 옵션을 제공하기 위해서 확장 옵션 헤더를 기본 헤더 뒤에 연속하여 제공한다.
어떤 확장 헤더(옵션)을 사용하는지를 구분하기 위해서 기본 헤더의 NextHeader 필드에는 확장 헤더의 옵션의 타입을 나타낸다. 만일 확장 헤더가 없는 경우는 NextHeader 필드에 이 패킷을 전달할 상위 계층 프로토콜을 지정한다.(즉, TCP, UDP 등을 구분하는 번호가 온다).
확장 옵션은 임의의 개수를 연속하여 추가할 수 있는데 계속 추가되는 옵션의 타입은 그 앞에 있던 확장 헤더에서 구분해 주게 된다.
IPv6는 패킷별로 특정 네트워크를 경유하도록 지정할 수 있다. 이를 위해서 Routing header 확장 옵션을 사용하는데 이 패킷이 목적지까지 가는 도중에 거쳐야 특정 라우터나 네트워크를 지정해 줄 수 있다.
이렇게 함으로써 각 패킷이 특정 서비스 제공자(사업자)의 노드를 경유하도록 할 수 있으며 서비스 품질, 가격, 성능, 안정성, 보안등을 고려하여 사용자가 패킷별로 다른 서비스 제공자를 선택하도록 할 수 있다.
IPv6가 제공하는 주요 확장 헤더의 종류는 다음과 같다.

hop-by-hop header : 송수신지 사이에 있는 모든 게이트웨이들이 확인해야 할 정보를 실어 보내는데 사용한다.
end-to-end header : 목적지 라우터에서만 확인할 정보를 전달한다.
outing header : 목적지까지 가는 도중에 거쳐야 라우터나 특정 네트워크를 지정하는데 사용된다. 이 정보에 따라서 Basic header에 기록되는 목적지 주소는 패킷이 라우터를 지날 때 바뀔 수 있다.
fragment header : 네트워크가 지원하는 최대 메시지의 길이(path MTU)보다 큰 메시지를 전송할 때 사용한다.
authentication header : 패킷의 송신지 확인용으로 사용한다.
privacy header : 인터넷상에서 데이터 보안을 유지할 때 사용하는데 암호화된 데이터는 이 헤더의 데이터 부분에 실려서 전송된다.

IPv6 도입

IPv6는 IPv4에 비해 풍부한 주소와 많은 기능을 제공할 수 있어 수년전부터 도입될 것으로 예상되었으나 실제로는 도입이 거의 되지 않고 있다.
이와 같이 IPv6가 잘 도입되지 않는 이유는 기존의 IPv4 기반의 인터넷 서비스와 장비에서 변경해야 할 것이 너무 많기 때문이다.
현재 NAT와 DHCP를 사용해서 부족한 IP 주소 문제를 잘 해결하고 있으므로 굳이 비싼 투자를 하여 장비를 교체할 이유가 없기 때문이다.
더욱이 서버로 동작하는 장비가 아니라면 임의의 IP 주소를 사용해도 인터넷을 사용할 수 있어 모든 장비가 고유의 고정 IP 주소를 배정받지 않아도 인터넷을 사용하는데 별 문제가 없기 때문이다.

연결형과 비연결형 서비스

모든 통신 서비스는 연결형(connection oriented)서비스와 비연결형(connectionless) 서비스로 구분할 수 있다.

연결형서비스

연결형 서비스란 상대방과 연결을 설정하는 절차, 이 연결을 통해 데이터를 주고받는 절차, 그리고 연결을 해제하는 절차의 세 단계 절차를 항상 거치는 서비스 형태를 말한다.

연결설정

데이터 송수신

연결 종료

예를 들어 전화 서비스는 상대방 전화번호를 다이얼링하여 연결하는 절차, 대화를 나누는 통신 절차, 그리고 전화를 끊으면 통신 서비스를 종료하는 절차가 있으므로 연결형 서비스이다.
다음에 설명할, 트랜스포트 계층의 TCP는 연결형 서비스이다.
연결 설정과 연결 종료의 과정 없이 데이터 송수신을 바로 제공하는 서비스를 비연결형 서비스라고 한다. LAN에서의 MAC 프레임 전송, IP 패킷 전송, UDP 프로토콜 등이 대표적인 비연결형 서비스이다.

비연결형 서비스

비연결형 서비스에서는 연결설정이 필요 없으므로 데이터를 보내고 싶은 순간에 임의의 목적지를 향해 즉시 데이터를 전송할 수 있다는 장점이 있다.
비연결형 서비스에서는 각 패킷 단위로 라우팅을 하게 되며 네트워크의 상태에 따라 라우팅이 달라질 수 있으므로 패킷이 목적지로 전달되는 경로가 달라질 수 있고 따라서 목적지에서 패킷의 도착순서가 다를 수 있다는 단점이 있다.
그러나 통신 서비스 도중에 네트워크 상태가 달라져도(특정 링크의 절단, 또는 라우터의 장애 등) 비연결형 통신은 다른 경로를 통해 계속 이루어질 수 있다는 장점이 있다.

'컴퓨터네트워크' 카테고리의 다른 글

4.트랜스포트 프로토콜(세그먼트, 포트번호, well-known port, TCP 연결 설정, TCP 데이터 송수신, TCP 흐름제어, 윈도우 흐름제어, 재전송, Jacobson/Karels 알고리즘, 데이터 경계 표시, TCP 옵션, UDP, UDP헤.. (0)	2021.09.05
2.IP 프로토콜(인터넷계층, BestEffort, IP패킷구조, IP 주소, IPv6, 특수주소, 메시지 분할 전송, path MTU, DHCP, 고정IP, NAT, 포트번호, ARP/RARP , ICMP, IGMP, 서브네팅,) (0)	2021.09.05
1.인터넷(TCP/IP, UDP, 프로토콜 모음집) (0)	2021.09.05