IETF와 3가지 협조단게 필요
인터넷은 원래 30여년 전에 과학기술자들간 문서를 전달할 목적으로 만들어졌다. 그러나, 1990년대 초반 웹의 부상으로 일반인들도 널리 사용하게 됐다.
대중들은 문서의 전달에 만족하다가 점차로 멀티미디어 서비스를 원하게 됐다. 이러한 요구를 만족시키기 위해 1990년 초반부터 인터넷을 통한 실시간 멀티미디어 서비스를 위한 표준화가 인터넷국제표준화기구(IETF, www.ietf.org)에서 진행됐다.
이 결과로 RSVP(Resource reSerVation Protocol), diffServ(differential Service protocol), intServ(integrated Service protocol), MPLS(Multi Protocol Labeling Switch) 등 서비스품질(QoS) 프로토콜들이 만들어졌다. 또한 차세대 인터넷표준인 IPv6도 실시간 멀티미디어 서비스를 원활히 지원할 수 있도록 되어 있다.
이러한 인터넷 QoS 프로토콜과 IPv6를 장착한 라우터는 이미 상용화됐으며, 우리나라를 비롯해 각국에서 수년전부터 생산하고 있으며 사설망을 중심으로 설치되고 있다.
하지만 이러한 인터넷 QoS 프로토콜을 이용해 실시간 멀티미디어 서비스를 효율적으로 제공하려는 움직임은 아직 활발하지 않다.
이는 현재 시점이 인터넷을 통해 멀티미디어를 전송하는 시스템을 만든 초기 단계에 해당하기 때문이다. 앞으로 인터넷 멀티미디어 송수신시스템의 최적화가 필요할 때, 인터넷 QoS 프로토콜의 사용이 본격화될 것이다.
◇MPEG과 IETF 협조 단계
MPEG과 IETF가 협조하는 단계는 3단계로 볼 수 있다.
협조 단계 :
1. 의미단계(semantic level) 2. 구문단계(syntax level) 3. 양단계( quantity level)
의미단계(semantic level) : 요구조건 (requirements) 단계에서 서로 의견을 같이하는 단계이다. 예를 들어 MPEG에서는 "인터넷을 통해 멀티미디어가 전송될 수 있어야 한다. 전송시 지연과 손실을 최소화할 수 있는 방법이 제공돼야한다" 정도의 요구조건이 있다. IETF에서도 마찬가지로 비슷한 요구조건을 갖고 있을 수 있다. 이 단계에서는 두 기구간 협조가 필요없다.
구문단계(syntax level) : 인터넷 프로토콜을 이용해 MPEG 콘텐츠를 실시간 전송하는데 필요한 문법을 맞추는 일을 한다. RTP(Realtime Transmission Protocol) 패킷에 MPEG 콘텐츠의 비트스트림을 실을 때, 패킷의 포맷을 정의하며, SDP(Session Description Protocol)나 RTSP(Real Time Streaming Protocol)를 이용해 호를 설정하고 유지하고 해제하는 절차를 정의한다. 이 단계는 효율성을 고려하는 단계가 아니며, 최소한의 상호운용성을 보장하는 방법에 대한 표준화를 진행한다. 현재 MPEG―4 콘텐츠에 대해서 이 단계까지 진행돼 있다.
양단계(quantity level) : MPEG―2에 비해 MPEG―4는 훨씬 다양한 기능이 갖고 있다. 객체기반 코딩, FGS, IPMP 등을 예로 들 수 있다. IETF 또한 실시간 멀티미디어 서비스를 위한 다양한 프로토콜을 제공하고 있다. 그러나 구문단계(syntax level)만 갖고는 이러한 다양한 기능들을 이용할 수 없다. 따라서, 이러한 다양한 기능들을 이용할 수 있는 방향으로 확장되어야 한다. 이제는 "인터넷을 통해서 MPEG 콘텐츠를 전송할 수 있다"를 넘어서 효율성을 높이는 방법을 표준화해야 한다. 이에 대해서 아직 "이것이 표준화 대상이냐? 구현의 문제 아닌가?"라든지 "어느 기구에서 이에 대한 표준을 담당해야 하는가?"하는 의문을 제시하는 사람들이 대부분이다.
◇MPEG과 IETF가 공동 해결해야 할 대상
MPEG과 IETF가 공동 해결해야 하는 대상은 다음의 3가지가 있다.
application―to―application : 두 개의 MPEG 터미널간의 상호 운용이 가능하기 위해 응용 계층 또는 세션 계층에 대한 프로토콜이 필요하다. SIP(Session Initiation Protocol), SDP, RTSP, RTP/RTCP(RealTime Control Protocol) 등이 이를 위한 프로토콜이며, 상당히 안정화돼있다.
하지만 아직 UEP(Unequal Error Protection) 같은 프로토콜을 이용하는 것이 완전하게 해결되어 있지 않다. 즉, 인터넷에서 UDP를 이용하여 실시간으로 멀티미디어 패킷을 전송할 때, 패킷이 손실되었을 경우 트랜스포트 계층에서 이를 복원하는 프로토콜을 이용하는 것이 바람직하나, 기능만 정의되어 있고 이를 이용하는 시스템에 대한 표준은 완성되지 않았다.
application―to―network : 인터넷 프로토콜중에 RSVP, diffServ, intServ 등은 QoS를 제어하는 프로토콜이다. 이들 프로토콜은 실시간 멀티미디어 서비스를 지원하는 것을 주목적으로 만들어졌으나, MPEG에서는 아직 이를 이용하는데 필요한 표준이 전혀 없으며 가까운 장래에 이를 추진할 움직임도 보이지 않고 있다.
실제로 MPEG과 IETF 모두 이에 대한 추진을 하지 않으면서 서로 상대방이 해야 할 부분으로 인식하고 있다. RSVP, diffServ 등을 장착한 라우터들과 운영체계가 이미 시장에 나와있다는 것을 생각하면, 두 기구가 이렇게 움직이지 않는 것이 매우 이상할 정도이다.
application―to―channel : 네트워크 프로토콜의 기본은 계층간 독립성이다. 그러나, 앞으로 인터넷이 유료화되고, 무선 인터넷이 활성화할 때 통신비용을 절약하면서 멀티미디어 품질을 유지하기 위해서는 계층간의 협조(cross layer optimization)이 필요하다. 아직 이 단계는 학문적으로 연구가 이제 시작되고 있다. 그러나, 표준화 기구에서 이에 대한 요구 조건을 명시해놓는 것은 필요하다고 본다.
인터넷은 원래 30여년 전에 과학기술자들간 문서를 전달할 목적으로 만들어졌다. 그러나, 1990년대 초반 웹의 부상으로 일반인들도 널리 사용하게 됐다.
대중들은 문서의 전달에 만족하다가 점차로 멀티미디어 서비스를 원하게 됐다. 이러한 요구를 만족시키기 위해 1990년 초반부터 인터넷을 통한 실시간 멀티미디어 서비스를 위한 표준화가 인터넷국제표준화기구(IETF, www.ietf.org)에서 진행됐다.
이 결과로 RSVP(Resource reSerVation Protocol), diffServ(differential Service protocol), intServ(integrated Service protocol), MPLS(Multi Protocol Labeling Switch) 등 서비스품질(QoS) 프로토콜들이 만들어졌다. 또한 차세대 인터넷표준인 IPv6도 실시간 멀티미디어 서비스를 원활히 지원할 수 있도록 되어 있다.
이러한 인터넷 QoS 프로토콜과 IPv6를 장착한 라우터는 이미 상용화됐으며, 우리나라를 비롯해 각국에서 수년전부터 생산하고 있으며 사설망을 중심으로 설치되고 있다.
하지만 이러한 인터넷 QoS 프로토콜을 이용해 실시간 멀티미디어 서비스를 효율적으로 제공하려는 움직임은 아직 활발하지 않다.
이는 현재 시점이 인터넷을 통해 멀티미디어를 전송하는 시스템을 만든 초기 단계에 해당하기 때문이다. 앞으로 인터넷 멀티미디어 송수신시스템의 최적화가 필요할 때, 인터넷 QoS 프로토콜의 사용이 본격화될 것이다.
◇MPEG과 IETF 협조 단계
MPEG과 IETF가 협조하는 단계는 3단계로 볼 수 있다.
협조 단계 :
1. 의미단계(semantic level) 2. 구문단계(syntax level) 3. 양단계( quantity level)
의미단계(semantic level) : 요구조건 (requirements) 단계에서 서로 의견을 같이하는 단계이다. 예를 들어 MPEG에서는 "인터넷을 통해 멀티미디어가 전송될 수 있어야 한다. 전송시 지연과 손실을 최소화할 수 있는 방법이 제공돼야한다" 정도의 요구조건이 있다. IETF에서도 마찬가지로 비슷한 요구조건을 갖고 있을 수 있다. 이 단계에서는 두 기구간 협조가 필요없다.
구문단계(syntax level) : 인터넷 프로토콜을 이용해 MPEG 콘텐츠를 실시간 전송하는데 필요한 문법을 맞추는 일을 한다. RTP(Realtime Transmission Protocol) 패킷에 MPEG 콘텐츠의 비트스트림을 실을 때, 패킷의 포맷을 정의하며, SDP(Session Description Protocol)나 RTSP(Real Time Streaming Protocol)를 이용해 호를 설정하고 유지하고 해제하는 절차를 정의한다. 이 단계는 효율성을 고려하는 단계가 아니며, 최소한의 상호운용성을 보장하는 방법에 대한 표준화를 진행한다. 현재 MPEG―4 콘텐츠에 대해서 이 단계까지 진행돼 있다.
양단계(quantity level) : MPEG―2에 비해 MPEG―4는 훨씬 다양한 기능이 갖고 있다. 객체기반 코딩, FGS, IPMP 등을 예로 들 수 있다. IETF 또한 실시간 멀티미디어 서비스를 위한 다양한 프로토콜을 제공하고 있다. 그러나 구문단계(syntax level)만 갖고는 이러한 다양한 기능들을 이용할 수 없다. 따라서, 이러한 다양한 기능들을 이용할 수 있는 방향으로 확장되어야 한다. 이제는 "인터넷을 통해서 MPEG 콘텐츠를 전송할 수 있다"를 넘어서 효율성을 높이는 방법을 표준화해야 한다. 이에 대해서 아직 "이것이 표준화 대상이냐? 구현의 문제 아닌가?"라든지 "어느 기구에서 이에 대한 표준을 담당해야 하는가?"하는 의문을 제시하는 사람들이 대부분이다.
◇MPEG과 IETF가 공동 해결해야 할 대상
MPEG과 IETF가 공동 해결해야 하는 대상은 다음의 3가지가 있다.
application―to―application : 두 개의 MPEG 터미널간의 상호 운용이 가능하기 위해 응용 계층 또는 세션 계층에 대한 프로토콜이 필요하다. SIP(Session Initiation Protocol), SDP, RTSP, RTP/RTCP(RealTime Control Protocol) 등이 이를 위한 프로토콜이며, 상당히 안정화돼있다.
하지만 아직 UEP(Unequal Error Protection) 같은 프로토콜을 이용하는 것이 완전하게 해결되어 있지 않다. 즉, 인터넷에서 UDP를 이용하여 실시간으로 멀티미디어 패킷을 전송할 때, 패킷이 손실되었을 경우 트랜스포트 계층에서 이를 복원하는 프로토콜을 이용하는 것이 바람직하나, 기능만 정의되어 있고 이를 이용하는 시스템에 대한 표준은 완성되지 않았다.
application―to―network : 인터넷 프로토콜중에 RSVP, diffServ, intServ 등은 QoS를 제어하는 프로토콜이다. 이들 프로토콜은 실시간 멀티미디어 서비스를 지원하는 것을 주목적으로 만들어졌으나, MPEG에서는 아직 이를 이용하는데 필요한 표준이 전혀 없으며 가까운 장래에 이를 추진할 움직임도 보이지 않고 있다.
실제로 MPEG과 IETF 모두 이에 대한 추진을 하지 않으면서 서로 상대방이 해야 할 부분으로 인식하고 있다. RSVP, diffServ 등을 장착한 라우터들과 운영체계가 이미 시장에 나와있다는 것을 생각하면, 두 기구가 이렇게 움직이지 않는 것이 매우 이상할 정도이다.
application―to―channel : 네트워크 프로토콜의 기본은 계층간 독립성이다. 그러나, 앞으로 인터넷이 유료화되고, 무선 인터넷이 활성화할 때 통신비용을 절약하면서 멀티미디어 품질을 유지하기 위해서는 계층간의 협조(cross layer optimization)이 필요하다. 아직 이 단계는 학문적으로 연구가 이제 시작되고 있다. 그러나, 표준화 기구에서 이에 대한 요구 조건을 명시해놓는 것은 필요하다고 본다.
