이번 절에서는 패킷 교환 WAN에 대해 다룬다. 여러 패킷 WAN 및 프로토콜의 이해 및 멀티미디어 응용의 관점에서 본 장단점, 해결책에 대해 알아보기로 하자.
X.25는 1970년대 초기에 느리고 저성능이던 전송 시스템을 보완하기 위해 고안된 패킷 교환 연결지향 프로토콜이다. 가상회선(virtual circuit)의 개념을 도입하였고 에러 감지와 복구에 중점을 두고 구현되었다. 또, 종단간 흐름제어(end-to-end flow control) 메카니즘을 제공한 것이 특징이다. 서로 다른 속도로 동작하는 종단시스템의 연결시 가령, 송신시스템이 수신시스템에서 처리할 수 없을 정도로 빨리 데이터를 전송한다면 수신시스템에서 애크놀리지먼트(acknowledgment)를 늦게 보냄으로써 송신시스템이 데이터를 보내는 속도를 감소시킬 수 있다. 이러한 메카니즘으로 인해 X.25는 무거운 프로토콜로 간주되고 있다. X.25 스위치는 가상회선에 자원을 실제로는 할당하지 않기 때문에, 일정한 비트율을 보장하지 못하며 등시성과 전송지연 또한 보장하지 못한다. 또, 멀티캐스팅 기능이 제공되지 않는다.
TCP/IP(Transmission Control Protocol/Internet Protocol)는 인터넷 사회(Internet Society)의 후원하에 개발된 통신 표준의 집합으로 가장 많이 사용되는 프로토콜 스택(protocol stack)이다. 전세계적인 붐을 일으키고 있는 인터넷(Internet)이 바로 이 TCP/IP를 사용한다. 아래 그림에 IP를 사용하여 동작하는 WAN의 예를 보이고 있다.
네트워크의 신뢰성(reliability)보다 효율성(efficiency)에 중점을 두었다.
에러복구는 네트워크가 아닌 종단시스템(호스트)에 맡긴다.
호스트에 QoS를 보장하지는 않는다.
비연결형(connectionless) 프로토콜이다. 네트워크는 전송중인 패킷이 어느 호스트들간의 통신에 속하는지 전혀 모르고 모든 패킷을 독립적으로 취급한다. 또, 호스트가 내보내는 데이터의 흐름을 규제하기 위한 허용제어(admission control) 메카니즘을 제공하지 않는다.
IP는 단지 최선노력의(best-effort) 전송서비스를 제공한다. 여기서 최선노력이란 다분히 냉소적인 단어로 그 의미는 패킷의 전송 보장을 위해 자원을 예약한다든지 등의 대책이 없음을 뜻한다.
중간의 IP 라우터에서의 보관/전달 과정이 확률적이어서(probabilistic) 각 패킷의 전송지연은 가변적이다.
네트워크에 과부하가 걸리면 패킷을 폐기(discard)하기도 한다.
IP 네트워크에는 여러 라우팅 프로토콜(routing protocol)이 있다. 소스(송신시스템)가 소스 자신과 목적지 호스트의 주소를 명시한 패킷을 보내면, 중간의 라우터가 특정한 라우팅 프로토콜을 사용하여 얻은 정보를 이용하여 다음 라우터로의 경로를 결정하고 그 경로로 패킷을 전송해 주는 식으로 목적지 호스트까지 패킷이 도달할 수 있다.
멀티캐스팅 기능을 제공할 수 있다.
IP 멀티캐스팅(IP Multicasting)
IP의 중요한 이점은 멀티캐스팅의 지원에 있다. IP 멀티캐스팅은 멀티캐스팅을 지원하도록 IP에 추가된 것으로 호스트가 멀티캐스트 그룹에 참여, 탈퇴할 수 있고, 그룹 멤버쉽 정보를 IP 멀티캐스트 라우터가 유지할 수 있도록 하는 메카니즘을 제공하는 IGMP(Internet Group Management Protocol)을 포함한다. 또, 어떻게 멀티캐스트 패킷을 라우팅할지에 관한 정보를 주고 받을 수 있도록 DVMRP, MOSPF와 같은 멀티캐스트 라우팅 프로토콜도 있어야 한다. 기존의 IP 라우팅 프로토콜에 종속되지 않는 PIM(Protocol Independent Multicasting)이라는 멀티캐스트 라우팅 프로토콜이 1994년 인터넷 표준으로 제안되었다. 아래 그림에 IP 멀티캐스팅의 설명이 있다.
MBone(Multicast Backbone)은 인터넷상의 가상의 실험적 멀티캐스팅 네트워크이다. 세션 디렉토리(session directory)는 인터넷 사용자에 회의중 오디오/비디오 분배와 같은 브로드캐스트 프로그램을 알려준다. 단순히 클릭만 함으로써 사용자는 그룹에 참여하게 되고 관심있는 스트림을 수신하고 복호화하는데 필요한 프로그램들을 지역적으로 활성화시킨다.
ST-II(STream protocol-II )
ST-II(STream protocol - II)는 IP에서 파생된 것으로 특별히 연속적 데이터 스트림을 지원하기 위한 연결지향 패킷 프로토콜이다. IP와는 전혀 별개이지만 ST-II의 구현은 한 라우터내에서 IP와 공존하는 형태를 보인다. ST-II는 연결지향 프로토콜로서 콜 설립(call set-up) 과정이 필요하다. 즉, 통신을 원하는 호스트는 데이터 교환 이전에 네트워크에 연결을 선언해야 하는 것이다. 그러면 ST-II 네트워크는 고정된 경로를 따르는 가상링크(virtual link)를 설립한다. 이 가상링크를 따라 대역폭이나 버퍼 등의 자원이 예약 또는 할당되어 어느 정도의 성능 보장을 제공할 수 있다. 그러나 주의해야 할 점은 ST-II 자체에 대역폭 예약 메카니즘이 내재되어 있지는 않다는 점이다. 대신 콜을 설립한 호스트가 최소의 대역폭, 평균 종단간 지연, 지연분산 등을 명세함으로써 어떤 QoS 레벨을 요청할 수 있는 메카니즘을 제공한다. 또 가상경로의 자원예약은 단방향(unidirectional)이다. 경로가 고정되어 있으므로 링크나 노드의 고장이 발생할 경우 가상링크가 재설립시까지 연결이 중단되는 단점이 있다. ST-II는 멀티캐스팅을 지원한다. 그러나 IP 멀티캐스팅과는 달리 새로운 수신자가 임의로 참여하는 것이 불가능하다. 세션중에 소스에 의해서만 참여가 가능하므로 이를 폐쇄형 멀티캐스트 그룹이라 부르기도 한다. 아래 그림은 ST-II 네트워크를 보이고 있다.
RSVP(ReSerVation Protocol )
RSVP는 IP 네트워크에서의 실시간 전송을 향상시킬 수 있도록 1994년에 고안되었다. IP는 성능을 보장하지 못하며(best-effort) 또한 하나의 서비스 레벨만을 제공하는 단점이 있다. 이에 RSVP는 서비스클래스(class of service)의 개념을 도입하였다. 각 응용들은 실시간 요구조선을 가지는 것과 그렇지 않은 것으로 분류횐다. 비연결형(connectionless) 방식으로 콜 설립과정이 없고 IP와 양립할 수 있다는 점이 ST-II와 다른 점이다. 앞서 ST-II는 IP와는 전혀 별개의 프로토콜이라고 언급한 바 있다.
RSVP의 혁신적인 생각은 송신자가 아닌 수신자가 QoS를 명세한다는 점이다. 지극히 당연한 생각처럼 보일 수도 있다. 가령 송신자가 3 Mbps밖에 처리할 수 없는 CPU를 가진 수신자에 6 Mbps의 비디오 스트림을 보낸 필요는 없는 것이다. 송신자와 수신자간에 전송속도를 미리 협상하면 되지 않느냐고 생각할 수도 있으나 멀티캐스팅의 경우 송신자와 각 수신자간에 일일이 협상한다는 것은 비효율적이다.
이제 RSVP의 예약 메카니즘을 간략히 살펴보자. 소스는 주기적으로 path 메시지를 멀티캐스트 패킷으로 보내면 수신자는 QoS 요구를 명세한 reserve 메시지를 소스로 보냄으로써 응답한다. 그러면 네트워크는 이 역방향을 따라 자원을 예약해 나간다. 또 하나 흥미로운 것은 가령 수신자가 VCR 화질의 비디오 채널을 위해 2 Mbps 정도를 예약했다고 했을 때 그것을 통해 시간에 따라 보고 싶은 채널을 변화시킬 수 있다는 점이다. 이것은 필터(filter)라는 기법으로 구현되는데 자세한 사항은 생략한다.
아직은 RSVP의 성능을 평가하기에 이르다. 혁신적인 아이디어를 많이 포함하기 때문에 연구자들사이에 많은 토의가 계속되고 있다. RSVP의 응용분야는 점대점(point-to-point) 또는 소규모의 다자간 화상회의 같은 것보다는 대규모의 비디오/오디오 브로드캐스팅 같은 것으로 예상된다.
아래 표에서 본 절에서 배운 프로토콜들이 멀티미디어의 전송에 얼마나 적합한지 정리했다.
 이전으로 |
 한단계 위 |
 처음으로 |
 다음으로 |