멀티캐스트 신뢰전송 기술 및 표준화 동향

고석주* 강신각**

인터넷 멀티캐스트 기술은 멀티캐스트 응용 서비스기술, TCP와 상응되는 수송계층에서의 멀티캐스트 신뢰성 제공 기술 및 네트워크 계층에서의 멀티캐스트 라우팅 기술로 분류할 수 있다. 본 글에서는 이 중에서 수송계층에서의 멀티캐스트 신뢰전송 기술에 대하여 살펴보고, IETF 및 ITU-T에서 진행 중인 표준화 동향에 대해 살펴본다. 현재 멀티캐스트 서비스에 대한 요구사항은 많은 반면, 보편적으로 대중화된 서비스 및 기술은 찾아보기 어렵다. 향후 몇 년 안에 IETF 및 ITU-T/JTC1에서는 여러 가지 다양한 프로토콜이 제시될 것이며, 최종 선택은 시장 및 사용자에게 넘겨질 전망이다. ▒

I. 서 론

인터넷 사용자 수의 급격한 증가와 인터넷서비스 보급의 대중화로 인해, 인터넷 멀티캐스트 기술의 발전은 높은 부가가치를 지니는 다양한 응용 서비스 보급을 더욱 촉진시킬 것으로 전망된다. 원격 교육, 화상회의, 네트워크 게임 등의 다자간 멀티캐스트 (many-to-many) 서비스를 포함하여, 하나의 서버에서 수천 혹은 수만 명의 수신자에게 실시간 데이터를 전송하는 one-to-many 멀티캐스트 서비스에 이르기까지 다양한 멀티캐스트 서비스 요구사항이 제기되어 왔다.

인터넷 멀티캐스트 기술은 멀티캐스트 응용 서비스 자체와, TCP와 상응되는 수송계층에서의 멀티캐스트 신뢰성 제공 기술 그리고 네트워크 계층에서의 멀티캐스트 라우팅 기술로 분류할 수 있다. 멀티캐스트 기술 연구는 시작한지 어언 10년이 넘었지만, 아직도 만족할 만한 그리고 대규모 인터넷에 쉽게 적용할 만한 해법이 제시되지 못하고 있다. 특히 수송계층에서의 멀티캐스트 신뢰성 제공 기술인 RMT(Reliable Multicast Transport) 기술의 경우는 더욱 그러하다.

본 글에서는 최근에 진행중인 RMT 기술 및 표준화 동향에 대하여 살펴보고자 한다. 2장에서는 멀티캐스트 기술 동향에 대해 살펴보고, 3장에서는 관련된 표준화 동향 및 이슈에 대해 기술한다.

II. 멀티캐스트 기술 동향

인터넷 멀티캐스팅 기술은 네트워크 계층에서의 멀티캐스트 라우팅 기술과 수송계층에서의 신뢰성 제공기술로 분류할 수 있다. 멀티캐스트 라우팅에서는 인터넷 데이터 패킷(packet)이 목적지에 도달하기까지 경유하게 되는 전송 경로를 설정하는 메커니즘을 의미한다. 수송계층에서의 신뢰성 제공기술이란 기존 TCP(transmission control protocol)처럼 오류제어(error control) 및 혼잡제어(congestion control)을 통해 멀티캐스트 종단 사용자간의 데이터 전송의 신뢰성(reliability)을 제공하는 기술이다.

1. 멀티캐스트 라우팅 기술

인터넷 멀티캐스트 서비스는 Class D라 불리는 인터넷 주소(address)체계를 사용한다. 기존 단대단(point-to-point) 유니캐스트(unicast)에서 사용되는 Class A , B, C 주소의 경우 네트워크 요소(component)와 호스트 요소로 구성되는 것과는 달리, Class D 멀티캐스트 그룹 주소는 특정 그룹 세션(session)을 위해 사용된다. 그러한 그룹 세션은 반영구적인 그룹일 수도 있고, 몇 분 혹은 몇 초 안에 해체되는 세션일 수도 있다. (그림 1)은 각 주소체계를 예시한다.

멀티캐스트 그룹에 참여(join)하기 위해 호스트는 가장 가까운 멀티캐스트 라우터에 등록을 해야한다. 이러한 절차는 IGMP(Internet Group Management Protocol)[1, 2] 프로토콜을 사용하여 이루어진다. (그림 2)에서 보여지듯이 호스트는 자신이 속한 서브넷(subnet)의 라우터에 특정 그룹 주소에 대한 멤버쉽 (membership) 정보를 보내야 한다. 혹은 멀티캐스트 라우터에서 먼저 IGMP 조회(query) 메시지를 보내어 관할 호스트 중에 멀티캐스트 참여자가 있는지 조회할 수도 있다. 이러한 주기적인 폴링(polling)에 대해 아무 응답이 없으면, 서브넷의 모든 호스트들이 해당 그룹을 떠난 것으로 간주하고, 멀티캐스트 라우팅 트리(tree)에 해당 라우터를 제외시키는 가지치기(prune)를 시작한다. IGMP 프로토콜은 RFC1112[1]에서 처음 정의되었으며, RFC2236[2]을 통해 개선되었다. 버전 2의 큰 특징은 호스트의 그룹탈퇴(leave)에 소요되는 지연시간을 줄인 것이다.

서브넷에서 IGMP를 통해 호스트와 멀티캐스트 라우터와의 등록(binding)과정을 통해 각 호스트 혹은 수신자(receiver)들은 특정 그룹의 Class D 주소에 대한 멀티캐스트 데이터를 받을 수 있게 된다. 라우터와 라우터 즉 네트워크를 통한 송신자와 수신자의 연결은 멀티캐스트 라우팅 프로토콜 메커니즘에 의해 이루어진다. 멀티캐스트 라우팅 프로토콜에 의해 그룹에 속한 송수신자들을 연결시켜 주는 트리(tree)가 구성되며, 프로토콜은 트리 구성 절차 및 방법을 정의한다. 현재까지 다양한 종류의 멀티캐스트 라우팅 프로토콜이 제안되어왔다[3]. 이러한 프로토콜들은 크게 인트라도메인(intradomain)을 고려한 것과 인터도메인(interdomain)을 고려한 것으로 나누어 볼 수 있다.

인트라도메인 프로토콜들은 하나의 도메인 혹은 하나의 AS(autonomous system)의 관할 지역에서의 트리 구성방법을 정의하며 크게 SBT(source based tree) 방식과 CBT(center based tree) 방식으로 분류할 수 있다[4]. SBT 방식에서는 데이터 송신자로부터 각 수신자에 이르는 트리가 구성되며 현재까지 DVMRP(Distance Vector Multicast Routing Protocol), MOSPF(Multicast extension to OSPF) 및 PIM-DM(Protocol Independent Multicast ? Dense Mode) 등이 제안되어 왔다. CBT 방식에서는 여러 송신자들이 하나의 코어(core) 혹은 RP(Rendezvous Point) 라우터를 통하여 데이터를 전송하게 된다. 각 송신자와 수신자들은 모두 코어 혹은 RP 라우터에 가입 메시지를 보내야 하며, 이러한 요청기반(request-driven) 방식으로 인해 대규모 망에 쉽게 확장될 수 있으며, 또한 여러 송신자가 하나의 트리를 공유하게 됨으로 보관, 유지해야 하는 라우팅 테이블 정보의 양도 줄어들게 된다. 현재까지 CBT(Core Based Tree) 및 PIM-SM(Protocol Independent Multicast ? Dense Mode)등이 제안되어 왔다.

도메인과 도메인을 통해 트리가 구성되는 인터도메인 멀티캐스트 라우팅 프로토콜은 궁극적으로 해결되어야 하는 라우팅 기술 중의 하나이며, 각 도메인간의 메시지 교환 및 협력을 필요로 한다. 현재 단기적인 해법으로는 M-BGP(Multicast extension to BGP), MSDP(Multicast Source Discovery Protocol) 및 PIM-SM 프로토콜을 연동시켜 사용하는 방식이 제안되고 있으나, 궁극적인 해법으로써, 각 도메인마다 사용할 수 있는 멀티캐스트 주소체계를 설정하고(MASC, Multicast Address Set Claim), 주소에 따라 루트(root) 도메인을 정한 후, 루트 도메인을 중심으로 트리를 구성하는 BGMP 프로토콜 개발이 한창 진행중에 있다[5].

2. 수송계층에서의 RMT 기술

일대일(point-to-point) 전송에서의 신뢰성 제공은 TCP 프로토콜에 의해 제공된다. 사실상 TCP는 유니캐스트 전송에서의 유일한 신뢰성 제공 프로토콜이다. (그림 3)에서 보여지듯이, 현재 멀티캐스트 응용서비스의 경우 UDP(User Datagram Protocol)위에서 작동하거나 혹은 IP 계층과의 raw 소켓(socket) 인터페이스를 통해 제공된다. UDP는 아주 최소한의 기능만 제공하는 수송계층 프로토콜이며, 단순히 포트(port)제공을 통해 응용계층과 IP 계층 사이의 인터페이스 역할만 수행한다. 따라서 전송 오류에 대한 복구기능이 전혀 없는 비신뢰성(unreliable) 프로토콜이다. 따라서 멀티캐스트 응용은 신뢰성을 제공하는 특정 수송계층의 지원을 받아야 한다. 만약 그러한 수송계층 프로토콜이 UDP 위에서 작동한다면 응용계층의 서비스와 함께 동작하게 될 것이고, IP 계층과 직접 인터페이스를 갖는다면, 특정 수송계층 프로토콜로써 사용될 것이다.

TCP와는 달리 신뢰성 기반 멀티캐스트 -이하 RMT(Reliable Multicast Transport)라 표기함 -전송 기법의 경우, 아직 뚜렷한 해법이 정해지지 않았으며, 현재 IETF에서 한창 표준화 작업 중에 있다.

가. RMT 응용 특성 및 요구사항

현재까지 고려되고 있는 멀티캐스트 응용 서비스들은 그 특성에 따라 3가지로 분류할 수 있으며, <표 1>에서 보여지듯이 각각 다른 요구사항을 갖는다.

화상회의 등의 협동형(collaborative) 응용서비스의 경우 다자간(many-to-many) 멀티캐스트 특성을 가지며 대략 100명 이하의 참여자로 구성될 것이다. 이러한 종류의 응용은 화상회의 참여자들이 불편을 느끼지 않을 정도인 400ms 이하의 지연시간이 요구되며, 중간정도의 신뢰성(reliability) 요구사항을 갖는다.

증권정보 혹은 뉴스 전송 등의 메시지전송(message streaming) 멀티캐스트 서비스의 경우, 매우 많은 수신자들을 고려할 필요가 있으며, 적절한 지연시간과 함께 응용에 따라 엄격한 신뢰성을 요구할 수 있을 것이다.

한편 대용량 파일전송 등의 벌크형 데이터(bulk data)서비스는 실시간에 전송될 필요는 없으나 매우 엄격한 신뢰성을 요구하고, 수백만의 혹은 가입자가 존재할 수 있을 것이다.

나. RMT 관련 기술

RMT 관련 기술은 오류제어, 흐름제어 및 폭주제어 기술로 나누어 볼 수 있다. 이 중에서 흐름제어와 폭주제어 기술은 모두 송신자의 데이터 전송속도 혹은 전송량을 통제하는 기술로써, 최근에 들어서는 같은 부류의 기술로 취급한다.

오류제어 기술은 수신자의 입장에서 손실(loss)된 멀티캐스트 전송 패킷을 복구(recovery)하는 절차를 의미한다. 좀 더 세부적으로 살펴보면 먼저 수신자가 패킷의 손실 여부를 탐지하는 오류탐지(error detection), 송신자 혹은 다른 수신자에게 손실된 패킷의 재전송을 요구하는 재전송 요구(retransmission request), 그리고 이를 토대로 손실된 패킷을 재전송(retransmission) 하는 기능으로 나누어 볼 수 있다. TCP와는 달리 멀티캐스트에서 신뢰성 제공이 어려운 이유는 바로 여러 수신자들이 서비스에 참여하고 있다는 점이다. 특히 손실 패킷의 재전송 요구시 수많은 수신자가 동시에 송신자에 재전송 요구 패킷을 보내는 경우, 소위 ACK(acknowledgement) 혹은 NACK(negative ACK) 폭주(implosion)문제가 발생한다. 대규모 그룹 및 네트워크에 쉽게 적용할 수 있는 확장성(scalability)문제를 해결하기 위해 그 동안 많은 연구들이 진행되어왔다[6].

흐름제어(flow control)란 멀티캐스트 수신자의 버퍼 혹은 패킷 처리능력을 초과하지 않도록 송신자의 송신속도를 제어하는 기법이다. TCP와는 달리 멀티캐스트 환경에서는 여러 수신자를 고려해야 하므로, 어느 수신자의 버퍼용량을 그룹의 대표값으로 정해야 할 지 등의 문제를 고려해야 한다.

폭주제어 혹은 혼잡제어(congestion control)에서는 송신자의 트래픽이 네트워크에 과부하되지 않도록 규정한다. 특히 하나의 패킷이 여러 수신자에게 전달되는 멀티캐스트 전송에서는 혼잡제어의 중요성이 더욱 커진다. 또한 네트워크가 혼잡상태에 있을 때에 송신자의 트래픽 발생을 줄여서 데이터 손실을 방지하도록 하며, 불필요한 트래픽 발생을 억제하는 역할을 한다.

RMT 기술은 위 세가지 핵심 제어기술로 구성되며, 위 제어 메커니즘을 쉽게 대규모 망에 확장할 수 있는 기술을 개발하기 위해 그 동안 많은 연구 및 프로토콜들이 제안되어 왔다.

다. RMT 관련 이슈(issues)

멀티캐스트 전송의 신뢰성 제공을 위해, 그리고 RMT 기법을 보다 광범위한 인터넷에 폭 넓게 보급하기 위해 다음의 이슈들이 제기되어 왔다.

? 확장성(scalability) 문제

소위 ACK/NACK implosion으로 대변되는 확장성 문제는 멀티캐스트 기술적인 문제의 대명사로 알려져 왔다. 멀티캐스트 라우팅의 경우, 라우팅 트리를 구성하기 위해 발생되는 제어패킷 및 라우팅 테이블 정보의 관리 문제가 제기된 반면에, 수송계층 프로토콜의 경우, 데이터전송 오류발생시 수많은 수신자들이 동시에 송신자에게 재전송 요구 패킷을 보내는 경우 송신자가 더 이상 오류복구처리를 수행할 수 없는 상황이 발생하게 된다.

? 혼잡제어(congestion control)

혼잡제어 문제는 멀티캐스트 서비스를 인터넷에 보급하기 위해서 가장 큰 이슈로 고려되고 있다. 특히 IETF 수송계층(transport area) 표준화 담당자 및 인터넷 망사업자의 입장에서 특정 송신자의 트래픽으로 인해 망 전체에 과부하 발생 방지를 최우선적으로 고려할 필요가 있다. 혼잡제어 이슈는 특히 학계를 중심으로 현재까지 꾸준히 연구되어 오고 있으나 아직 만족할만한 해법은 제시되고 있지 못하다. 특히 멀티캐스트의 다양한 네트워크 및 수신자 특성 정보를 고려한 해법 제시가 어려움을 알 수 있다. 현재까지 논의되어온 결과에 따르면, 기본적으로 멀티캐스트 혼잡제어는 윈도우(window) 기반이 아닌 송신속도(rate) 기반 방식이 사용될 전망이다. 즉, 네트워크 상태를 진단하기 위해 송신자와 수신자들에 이르는 RTT(round trip time) 정보를 이용하고, 각 수신자의 수신상태를 파악하기 위해 패킷 손실율을 측정하여 송신자의 데이터 전송율을 조정한다. 특히 멀티캐스트 혼잡제어는 TCP-friendly 접근방식을 취하고 있으며, 이에 따라 정상동작(normal)모드에서는 점진적으로 (slow-start)데이터 전송율을 증가시키고, 혼잡상태가 탐지되면 급격히 송신율을(exponential) 감소시키는 방식을 사용하고 있다.

? 보안 문제 (security)

인터넷 보안문제는 어느 계층을 막론하고 주요 관심 대상이 되고 있다. 특히 응용계층과 인터넷 계층의 IPSEC(IP Security) 이슈가 주로 논의되고 있다. RMT에서의 보안이슈는 수송계층에서의 보안문제만을 다룰 예정이나, 아직 본격적인 논의는 미비한 실정이다.

라. 주요 RMT 프로토콜

위에서 기술한 신뢰성 제공을 위한 제어 메커니즘과 기술개발 관련 이슈를 해결하기 위해 다양한 방식들이 제안되어 왔으며, 이 중 현재까지 알려진 주요 RMT 기법을 정리하면 다음과 같다.

① 트리 기반 (tree-based) ACK 방식

멀티캐스트 사용자를 연결하는 수송계층의 논리적 트리를 구성하여 트리 계층 구조를 이용하여 오류를 복구하는 기법이다. 트리를 통해 각 수신자들은 부모-자식(parent-children) 관계를 형성할 수 있으며, 각 부모 노드들은 자식노드들에 대한 오류복구 기능을 제공한다. 부모노드가 재전송을 요구하는 패킷을 가지고 있지 않은 경우에는, 상위 부모노드에게 재전송을 요청하여 결국 데이터 송신자에게 재전송 요구가 전달될 수 있다.

(그림 4)는 수송계층에서의 논리적 트리에 대한 예를 보여주고 있다. 그림에서 각 부모 노드는 DR(Designated Receiver)로써 표기되고 있으며, 각 자식노드로부터 ACK 패킷 및 손실정보를 받은 뒤 오류를 복구하고, 자기 서브 그룹에 대한 데이터 송수신 상태 정보를 상위, 차상위 부모 노드에게 전달한다. 이러한 상태정보에 입각하여 송신자는 흐름 및 혼잡제어를 수행하게 된다.

트리기반 오류제어에서는 이처럼 수 많은 수신자들을 하나의 트리 구조로 연결하여 확장성 문제를 해결하고자 한다. 하지만 어떻게 전체 그룹을 하나의 트리로 구성할 것인지에 대한 만족할만한 해법이 나오지 않았으며, 특히 어떤 수신자 혹은 개체를 부모노드로 정할 것인지 등의 이슈가 남아 있다. 또한 망의 혼잡제어를 위해 각 수신자의 정보를 송신자에게 보낼 필요가 있는 경우, 해당 제어 패킷이 트리를 따라 송신자에게 전달되는 동안 일정시간의 지연(delay)이 발생한다는 문제점도 있다. 대표적인 프로토콜로써는 RMTP(Reliable Multicast Transport Protocol)[7] 및 TRAM(Tree based Reliable Multicast)[8] 프로토콜 등이 있다.

② 멀티캐스트 NACK 기반 신뢰성 제공

오류 재전송을 요구하는 수신자는 NACK 패킷을 전체 그룹에 전송한다. 가까이에 있는 성공적인 수신자가 있을 경우, 이러한 NACK 패킷에 응답한다. 이 경우 같은 NACK 패킷을 여러 수신자들이 동시에 발생시켜 NACK 패킷이 폭주할 우려가 있으므로, 각 수신자는 타이머(timer)를 이용하여 적절한 시간동안 다른 NACK 패킷이 이미 발생되었는지를 파악한다.

이러한 기법을 NACK 억제(suppression) 기법이라 한다. NACK 기반 오류제어에서는 오류복구 기능을 송신자가 아닌 가까이에 있는 수신자의 도움으로 해결하여 확장성을 높이고자 한다. 이 방식에서는 특히 NACK 억제를 위해 사용되는 타이머의 동작이 전체 성능에 영향을 주며, 특히 모든 수신자에게 멀티캐스트 송신 능력을 요구한다. 또한 ACK 패킷의 기능중의 하나인 송신버퍼의 방출(release 혹은 flush) 기능이 없다는 문제점도 지니고 있다. 이 방식의 대표적인 프로토콜로써는 SRM(Scalable Reliable Multicast)[9] 방식을 들 수 있다.

③ FEC(forward error correction) 방식

ACK/NACK 기반 오류복구에서는 수신자의 패킷 수신정보를 송신자에게 전달하여 송신자가 패킷을 재전송 하는 ARQ(Automatic Request)방식인 반면에, FEC 방식에서는 송신자가 데이터 송신 단계에서부터 parity bits 등의 redundancy를 부과하여 데이터를 전송하는 방식이다. 즉, 수신자로부터의 피드백(feedback) 없이, 패킷 손실이 발생했을 경우 다른 패킷의 redundancy 정보를 이용하여 손실된 패킷을 복구하는 방식이다.

이러한 기법을 FEC 방식이라 하며, 최근에 큰 주목을 받고 있다. 특히 위성 등의 비동기(asynchronous) 네트워크에서 적용이 용이하며, 재전송 및 오류복구 등으로 인한 추가 지연시간이 소요되지 않는다. 하지만 이를 위해 별도의 FEC 코딩(coding) 방식이 요구되며, 안정적인 망에서 사용하기에는 불필요한 오버헤드(overhead)가 발생할 수 있다. 이 방식의 대표적인 프로토콜로써는 RMDP(Reliable Multicast Dissemination Protocol)[10] 등이 있다.

④ GRA(generic router assist) 기반 NACK 방식

이 방식은 네트워크 라우터를 이용하여 수송계층의 신뢰성을 제공하는 기법이다. 특히 이방식에서는 네트워크 계층의 라우팅 트리 자체를 오류 복구에 사용하게 된다. 각 수신자는 패킷 손실이 발생할 경우 송신자를 향해 NACK 패킷을 전송하고, 각 상위 라우터에서는 이러한 NACK를 취합하여 하나의 NAK 패킷을 차상위 라우터에 전송한다. 이를 위해 각 라우터는 수송계층의 NAK 패킷을 해석할 수 있어야 하고, 상태정보 또한 기억하고 있어야 한다. 또한 (그림 5)에서 보여지듯이, 여러 자식노드로부터의 중복된 NACK 전송을 방지하기 위해, 일단 NACK를 수신한 각 라우터는 하위 노드에게 NCF(NACK Confirm) 메시지를 보내게 된다. 최종적으로 NACK가 송신자에 도착하면 송신자는 RDATA(retransmission data) 패킷을 통해 오류를 복구하게 된다.

하지만 이러한 방식을 사용하기 위해서는 각 라우터에서 수송계층 메시지를 해석, 처리하는 기능이 요구되며, 이러한 라우터의 개발 및 보급이 가까운 시일 내에 실현될 것으로 보이지는 않는다. GRA 기반 신뢰성 제공 방식의 대표적인 프로토콜은 Cisco System사의 PGM(Pretty Good Multicast)[11]방식이다.

특히, PGM 프로토콜은 (그림 6)에서 보여지듯이 IP 계층 바로 위에 위치하여, 라우터와 상호연동을 통해 수송계층의 멀티캐스트 서비스를 제공하고자 한다.

마. 시장/제품 동향

RMT 제품 관련하여 현재 몇 가지 제품이 개발 및 출시되고 있으나, 대규모 공중망에 보급된 제품은 아직 없는 실정이다.

RMTP 혹은 RMTP-II의 경우 Talarian Corporation사에서(1999년에 Globalcast를 인수함[12]) 개발되고 있으며, 특히 SmartSocket 기술과 RMTP 기술을 병합하여 신뢰성 있는 멀티캐스트 서비스 제공을 목표로 하고 있다. 현재 Sprint 등의 통신회사와 결합하여 미국의 주요 네트워크 POP(Point of Presence) 사이트에 전용 DR(designated receiver) 서버를 구축하고, 주로 기업체 고객을 대상으로 멀티캐스트 서비스를 제공할 계획이다.

RMTP처럼 트리기반 RMT 방식 중의 하나인 TRAM 프로토콜은 Sun MicroSystem사에서[13] 개발되고 있으며, 특히 Java 기술과 TRAM 기술을 접목할 계획이다.

SRM 방식은 미국 대학을 중심으로 개발, 연구되고 있으며 특히 멀티캐스트 시험망인 MBONE(Multicast Backbone) 망에서 활발히 시험되고 있다.

PGM 방식은 Cisco System사 및 WhiteBarn사를[14] 중심으로 개발되고 있으며, 멀티캐스트 신뢰성 및 subcasting ? 하위 계층의 트리노드에게만 재전송 패킷을 전송하는 기법 ? 을 지원하는 라우터 개발이 진행 중이다.

이 외에도 StarBurst Communications사의 MFTP(Multicast File Transfer Protocol) 프로토콜은[15] 파일 전송 서비스를 주요 목표로 개발되었으며, 현재 General Motors사의 dealers 네트워크에서 서비스가 제공되고 있다. MFTP 프로토콜은 실시간성을 요구하지 않는 파일 전송서비스에 특히 적합하며, 데이터 전송의 신뢰성 제공을 위해 한 파일을 여러 개의 Blocks으로 분할하여 Block 단위로 전송하며, 오류복구 또한 각 block 단위로 이루어진다(그림 7참조). 즉, 각 수신자는 손실된 패킷이 속한 block에서의 순번 정보를 NACK 메시지에 실어 송신자에게 보낸다. MFTP의 오류제어 메커니즘은 pass 기반 방식이다. 즉, 일단 첫번째 pass에서 모든 데이터를 송신한 후, 수신자로부터 NACK 메시지를 받는다. 패킷 손실로 판정된 패킷들은 두번째 pass에서 모든 수신자에게 재전송된다. 모든 수신자가 성공적으로 데이터를 수신할 때까지 이러한 절차가 반복된다.

III. IRTF/IETF 표준화 동향

1. IRTF RMRG/IETF RMT WG

인터넷 멀티캐스트의 신뢰성 제공 기술 개발 및 표준화 노력은 1997년 3월 미국 Memphis에서 개최된 IRTF(Internet Research Task Force)의 RMRG(Reliable Multicast Research Group) meeting[16]에서 시작되었다. RMRG meeting은 연간 3~4 번의 회의를 통해, 위에서 언급한 여러 가지 기술적인 문제를 해결하고 가능한 해법을 제시하기 위해 노력하였다.

사실상 그 동안 제안되어온 여러 가지 프로토콜을 기반으로 곧 바로 표준화 작업에 착수할 수도 있었으나, 이처럼 RMRG의 연구 및 검증을 거친 후 IETF에서 표준화 작업을 계획했던 것은, 그만큼 RMT[17]에 대한 기술적인 어려움과 향후 인터넷에 미칠 수 있는 문제점 등이 매우 컸음을 반증한다. 이러한 걱정 및 관심은 1996년 11월에 발행된 Internet draft 문서에서 찾아볼 수 있다. 이 문서에 의하면, 네트웍 혼잡상황 발생시 RMT 트래픽이 인터넷에 끼칠 수 있는 문제점들은 매우 심각할 수 있고, 특히 TCP에 비해 RMT 트래픽의 영향력은 매우 크다. 인터넷의 성공은 혼잡상황이 발생한 링크에서는 패킷을 과감히 폐기하는 best-effort 특성에 기인하며, TCP의 탁월한 혼잡제어 기능으로 인해 오늘날 인터넷은 폭주상태를 예방할 수 있었다. 라고 쓰여 있다.

수 차례의 RMRG meeting을 통해 1999년 3월 IETF 회의에 RM BOF(Bird of Feather) meeting이 열리고, IETF RMT WG(Working Group)이 발족하게 된다. 본디 IRTF는 인터넷 관련 연구 그룹이고, IETF는 인터넷 관련 표준화 단체로써, RMT 관련 기술적 논의가 IRTF RMRG에서 어느 정도 성숙된 이후에 IETF RMT에서 논의될 예정이었으며, 이에 따라 many-to-many 멀티캐스트 및 보안 관련 이슈를 제외한 one-to-many 멀티캐스트 이슈의 대부분이 IETF 표준화 대상에 놓여 있게 되었다.

2. IETF 표준화 방향

RMT 응용의 매우 다양한 서비스 요구사항에 따라 여러 개의 프로토콜이 표준으로 제안될 예정이다. 이러한 표준화 접근방식은 다분히 정치적인 문제도 포함되어 있으나, 한편으로는 RMT 기술의 복잡성 및 실제 대규모 망에 배치되는 경우에 대한 신뢰성 이슈가 해결되지 않았음을 반증하기도 한다.

RMT WG은 먼저 one-to-many 대용량 벌크형(bulk) 데이터의 멀티캐스트 전송에 대한 표준화에 노력할 예정이다. 상당수의 멀티캐스트 응용이 one-to-many 멀티캐스트 범주에 속한다는 점이 이러한 표준화 방향을 유도하게 되었다. 또한, RMRG의 연구에 따르면 다양한 멀티캐스트 응용 요구사항을 만족시키는 단일 RMT 프로토콜은 없다라는 소위 one size doesnt fits all 개념에 입각하여 RMT WG은 우선 다음 3가지의 프로토콜을 표준화 하기로 했다.

? NACK-based 프로토콜

SRM 프로토콜을 표본으로 하며, 주로 미국의 대학 중심으로 개발되고 있으며 MBONE 망에서 가장 활발히 시험되고 있는 프로토콜이다. NACK 기반 멀티캐스트 재전송 요구를 통해 가까이에 있는 성공적인 수신자가 재전송을 하도록 한다. NACK 패킷의 폭주를 막기위해 타이머 기반 NACK suppression 방식을 사용한다.

? Tree-based ACK 프로토콜

수송계층의 논리적 트리를 구성하고, 트리 계층구조를 이용하여 오류 재전송 및 혼잡제어를 수행한다. 미국 Globalcast사를 인수한 Talarian사에서 개발하고 있으며, Talarian사의 SmartSocket 제품과 통합하여 시장에 출시할 예정이다. 처음의 RMTP 프로토콜에서는 ACK 패킷만 사용하였으나, RMTP-II에서는 점점 ACK 이외에도 실시간 응용 요구사항을 충족시키기 위해 NACK 패킷을 병행하여 사용하고 있으며, 특히 비동기 네트워크 지원을 위해 FEC 방식도 함께 고려 중에 있다. 한편 Sun Microsystem사의 TRAM 프로토콜도 트리 기반 방식이며 표준화에 적극적으로 가담하고 있다.

? FEC 기반 ALC(Asynchronous Layered Coding) 프로토콜

오류 복구를 위해 FEC 기법을 사용하며, 흐름 및 혼잡제어를 위해 각 수신자들은 자신의 버퍼 혹은 처리용량에 따라 다른 멀티캐스트 계층(layer)에 가입할 수 있다. 이 경우 송신자는 같은 데이터를 대역폭 요구사항에 따라 여러 계층의 멀티캐스트 채널을 통해 데이터를 전송하게 된다. Digital Fountain사에서 개발을 주도하고 있으며, 특히 이 방식은 이동통신이나 위성통신망 등의 비대칭 네트워크에서 사용하기에 적합하다.

각 프로토콜 개발에 있어서 RMT WG은 BB(Building Block) 접근방식을 취하고 있다. BB 접근방식에서는 먼저 다양한 프로토콜들이 공통적으로 시용할 수 있는 기본 단위기능을 BB으로 정의하고, 이에 대한 규격을 정의한 다음, 이러한 개별 BB들을 이용하여 응용 서비스 요구사항에 적합한 PI(Protocol Instantiation) 프로토콜을 개발한다.

이러한 표준화의 신속성을 위해 WG은 다음 세 가지의 참조문서를 작성중이다.

? 설계범위(design space)[18]

RMT WG의 표준화 전략 및 범위를 기술한다. 단기적으로는 one-to-many 멀티캐스트 신뢰성 제공을 위해 노력하고, 어느 정도 실현성이 확인되면, many-to-many 멀티캐스트 이슈에 대한 표준화에 착수할 예정이다.

? BB와 PI 개념 정의[19]

RMT WG에서 추구하는 각 BB와 PI의 개념 및 요구사항을 기술한다. BB는 최소한으로 분해될 수 있는 기능 블록을 정의하며, PI는 하나의 독립적인 프로토콜로써 여러 가지 BB와 고려하는 프로토콜의 핵심(core)으로 구성된다.

? BB와 PI 규격개발 지침서

RMT WG에서 각 프로토콜 규격 개발자들이 따라야 하는 공통된 규칙 및 지침을 정리하는 문서이며 현재 진행 중에 있다.

RMT WG은 현재 다음의 BB 문서를 계획하고 있다.

- 혼잡제어 BB

- NACK BB

- FEC BB[20]

- GRA BB[21]

- 보안 요구사항 BB

한편 다음의 PI 규격개발을 목표로 하며 관련된 RFC(Request for Comment) 문서들을 발간할 예정이다.

- NACK 기반 프로토콜

- TRACK (tree based ACK) 프로토콜

- FEC 기반 ALC 프로토콜[22]

향후에 추가적인 BB 혹은 PI가 요구되는 경우 IETF Transport Area Director와 협의하여 추가 작업을 진행할 예정이다.

IETF RMT WG은 IRTF의 RMRG와 SMuG(Secure Multicast Research Group)과 깊은 연관을 가지고 표준화 작업을 진행할 것이며 특히 혼잡제어와 보안관련 이슈에 대하여 공조관계를 계속할 예정이다.

3. 최근 RMT WG meeting

1999년 11월 워싱턴 회의에서 각 BB 및 PI 문서작업을 위한 drafting 팀들이 구성되었으며, draft 초안 작성을 위해 2월 10일 미국 ACIRI에서 interim meeting을 가졌다. 2월 회의에서는 먼저 혼잡제어 관련하여 Mark Handley의 rate-based 혼잡제어 실험 결과 보고가 있었다. 일단 유니캐스트 환경에서 RTT와 수신측에서의 패킷 손실율에 입각하여 송신자의 전송율을 제어하는 방식에 대해 긍정적인 결과를 얻었고, 추후에 멀티캐스트 환경에 대한 고려와 수신자 기반 혼잡제어 방식(예:ALC)에 대한 토의 및 검증작업이 진행될 전망이다.

혼잡제어 등의 공통 이슈에 대한 모임 후 각 PI별 모임을 가졌다. FEC 기반 ALC의 경우 별 이슈 없이 순조로이 진행된 반면에 NACK 및 TRACK 모임에서는 많은 이견이 있었다. 특히 NACK 프로토콜에서는 모든 수신자들에게 멀티캐스트 송신 능력을 요구하며, 현재 RMT WG에서 추구하는 one-to-many 접근방식에 위배된다는 점이 걸림돌로 작용하고 있다. 한편 TRACK 모임에서는 논리적 트리 구성방식에서부터 이견이 대립되었다. 논리적 트리 구조에서 오류복구를 담당하는 Repair Head 노드를 전용 서버 중심으로 바라보는 RMTP-II(Talarian) 방식과 일반 수신자중에서 Repair Head를 선출하자는 TRAM(Sun) 방식과의 의견 대립이 심했다. 이 외에도 TRACK의 패킷 재전송시 TTL(Time to live) 값을 사용하자는 측과 하지 말자는 측의 의견 대립을 포함하여 TRACK의 표준화에 상당한 걸림돌이 있을 것으로 예상된다.

2000년 3월 호주 Adelaide IETF 회의에서는 그 동안 진행된 각 BB 및 PI 문서에 대한 발표가 있었으며, 지속적인 검토작업을 거쳐 각 BB 문서를 RFC로 제안할 계획이다.

4. 표준화 관련 주요 쟁점 사항

IETF RMT 표준화 일정은 다음 이슈의 해결 및 협상여부에 많은 관련이 있을 것으로 보인다.

? 폭주 제어

현재 송신자 중심의 rate-based 혼잡제어 방식과 수신자 중심의 ALC 방식이 거론되고 있으며, 두 가지 모두 표준화 절차를 진행할 것으로 전망된다. 특히 송신자 중심의 rate-based 방식에서는 여러 수신자중에 RTT를 어떻게 측정할 것인가 ? 측정된 RTT 정보를 어떤 방식으로 송신자에게 전달할 것인가? 라는 기술적인 문제가 해결되어야 한다.

? Many-to-many 멀티캐스트

현재 RMT에서는 one-to-many 멀티캐스트 만을 고려하며, 기본적으로 하나의 Class D 주소에는 하나의 송신자만 있도록 규정하고 있다. 이는 위성 및 이동통신망의 특성을 고려하여 제안된 것인데, 이 경우 NACK 및 TRACK 프로토콜 개발에 있어서 그 동안 연구되어온 많은 방식들이 사용될 수 없게 된다. 또한 그룹회의 등의 many-to-many 멀티캐스트에 대한 고려도 포함해야 한다. 현재 일부 인터넷 전문가 사이에서는 하나의 그룹에 여러 송신자가 존재하는 경우, 관리(트래픽 제어 및 요금문제 등)의 복잡성 때문에, 그리 활성화 되지 못할 것으로 보는 시각이 있으며, 특히 ISP(Internet Service Provider) 입자에서 이러한 논의가 진행중이다. 이는 PIM-SO(Protocol Independent Multicast ? Source Only)라는 방식에서는 PIM 기반의 멀티캐스팅에서 오직 하나의 송신자만 허용하도록 규정하고 있다. 이 이슈는 향후 멀티캐스트 서비스 보급 관련하여 많은 논쟁이 계속될 것으로 보인다.

? 트리 구성 관련

현재 TRACK 프로토콜의 표준화 일정이 가장 느려질 것으로 전망되며, 논리적 트리 구성 방식에서부터 많은 이견 및 기술적인 문제가 예상된다. 특히 Repair Head를 어떻게 결정할 것인가의 문제와, many-to-many 멀티캐스트가 지원되지 않는 상황에서 트리 구조를 어떻게 형성할 것인가의 문제가 걸림돌로 등장하고 있다. 한편, 트리 구조에서 혼잡제어를 위해 RTT 정보를 어떻게 송신자에 전달할 것인가의 문제도 고려되어야 한다.

IV. 결론 및 향후전망

멀티캐스트 기술은 전반적으로 매우 어려운 기술로 알려져 있다. 특히 수송계층에서의 멀티캐스트 신뢰성 제공 기술은 확장성 문제, 혼잡제어 및 보안 이슈 등으로 인해 효과적인 해법을 찾기에 더욱 어렵다. 거의 10여년의 연구 및 개발 결과를 토대로 1999년부터 IETF의 RMT WG에서 관련 표준화가 진행되고 있다. 한편 ITU-T SG7 및 ISO/IEC JTC1/SC6에서도 차세대 수소계층 프로토콜 표준화 작업을 진행하고 있으며, 현재 ECTP(Enhanced Communication Transport Protocol)[23, 24, 25] 프로토콜을 개발 중에 있다. 특히 ECTP 표준화 작업은 ETRI에서 주도하고 있으며 곧 표준화 작업이 마무리 될 전망이다. IETF의 RMT 표준화에 비해 ECTP는 다음과 같은 특징을 갖는다.

- IETF의 경우 one-to-many 멀티캐스트만 고려하는 반면에 ECTP에서는 One-to-many 및 Many-to-may 멀티캐스트 서비스에 대한 지원 규격을 포함한다.

- IETF는 멀티캐스트 신뢰성 제공을 위한 RMT 이슈만을 고려하는 반면에, ECTP는 RMT 이슈를 포함하여 종단간의 QoS(Quality of Service) 관리 및 지원기술을 포함한다.

- IETF 멀티캐스트는 불특정 다수를 대상으로 하는 멀티캐스트 그룹을 고려하는 반면에, ECTP에서는 그룹에 대한 개념 및 정의를 분명히 하고, 일단 참여한 멀티캐스트 사용자는 엄격한 그룹 관리를 통해 멀티캐스트 서비스의 안정성 및 신뢰성을 높인다.

- IETF에서는 정치적인 이유로 인해 NACK, TRACK 및 ALC 등의 RMT 해법을 제시하는 반면에, ECTP는 TRACK 기반의 단일 RMT 해법을 권장하며, 세부 규격에 있어 일관성을 유지하고 있다.

현재 멀티캐스트 서비스에 대한 요구사항은 많은 반면, 보편적으로 대중화된 서비스 및 기술은 찾아보기 어렵다. 본 글에서 살펴보았듯이, 향후 몇 년 안에 IETF 및 ITU-T/JTC1에서는 여러 가지 다양한 RMT 해법을 제시할 것이고, 결국 최종 선택은 시장에 넘겨질 전망이다. 최후의 승자는 멀티캐스트 시장 요구사항과 인터넷 망의 특성을 가장 효과적으로 지원해주는 RMT프로토콜이 될 것으로 전망되며, 이는 주변 멀티캐스트 기술 발전 및 인터넷 망의 성장 방향에도 영향을 받을 것이다.

국내에서도 일부 벤처업체에서 멀티캐스트 서비스를 개발 중이며, 초기에는 실시간 증권 및 재무 정보 제공 서비스 등에서 사용될 전망이다. 이러한 서비스는 특히 IMT-2000 단말 사용자를 포함하는 고객들에게 짧은 문자메시지를 실시간으로 신뢰전송 해주는 기능을 포함할 것으로 예상된다. 나아가 대용량 파일전송 및 화상회의 서비스 등에서도 신뢰전송 프로토콜의 사용이 증가될 것으로 전망된다.

<참 고 문 헌>

  1. Deering, S., Host Extensions for IP Multicasting, IETF RFC 1112, August 1989.
  2. Fenner, W., Internet Group Management Protocol, Version 2, IETF RFC 2236, November 1997.
  3. 고석주 외, "인터넷 멀티캐스트 라우팅 프로토콜 분석 (Analysis of Internet Multicast Routing Protocols)," ETRI 전자통신동향분석, 99년 10월호, pp. 99 - 110, 1999.
  4. Koh S. J., etc, Minimizing Cost and Delay in Shared Multicast Trees, ETRI Journal, Vol. 22, No. 1, pp.30-37, March 2000.
  5. IETF BGMP WG, Border Gateway Multicast Protocol: Protocol Specification, draft-ietf-bgmp-spec-00.txt, Jan., 2000.
  6. 고석주 외, "멀티캐스트 전송을 위한 오류제어 기법의 분류 (Classification of Reliable Multicast Transport Protocols)", ETRI 전자통신동향분석, 99년 6월호, pp. 76 - 84, 1999.
  7. Whetton B., et al., The Reliable Multicast Transport Protocol, IETF Internet Draft, draft-whetton-rmtp-ii-00.txt, April 1998.
  8. Kadansky M., et. al., Tree Based Reliable Multicast, IETF Internet Draft, draft-kadansky-tram-02.txt, January 2000.
  9. Floyd S., et al., A Reliable Multicast Framework for Lightweight Sessions and Application-Level Framing, ACM SIGCOMM 95, pp. 342-356, October, 1995.
  10. Yavatkar R., etc, A Reliable Dissemination Protocol for Interactive Collaborative Applications, Proceeding of ACM Multimedia 95, 1995.
  11. Farinacci D., etc, PGM Reliable Transport Protocol Specification, draft-speakman-pgm-spec-01.txt, Jan., 1998.
  12. http://www.talarian.com
  13. http://www.sun.com
  14. http://www.whitebarn.com
  15. http://www.starbust.com
  16. http://www.east.isi.edu/RMRG
  17. http://www.ietf.org
  18. IETF RMT WG, The Reliable Multicast Design Space for Bulk Data Transfer, WG draft, draft-ietf-rmt-design-space-00.txt, June 1999.
  19. IETF RMT WG, Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer, WG draft, draft-ietf-rmt-buildingblocks-01.txt, June 1999.
  20. IETF RMT WG, Reliable Multicast Transport Building Block: Forward Error Correction Codes, WG draft, draft-ietf-rmt-bb-fec-00.txt, March 2000.
  21. IETF RMT WG, Generic Router Assist (GRA) Building Block: Motivation and Architecture, WG draft, draft-ietf-rmt-gra-fec-00.txt, March 2000.
  22. IETF RMT WG, Asynchronous Layered Coding: A scalable reliable multicast protocol, WG draft, draft-ietf-rmt-pi-alc-00.txt, March 2000.
  23. ITU-T draft Recommendation X.extp, Enhanced Communication Transport Protocol, ITU-T SG7 Q13, March 2000.
  24. ISO/IEC Contribution Draft 14476, Enhanced Communication Transport Protocol, JTC1/SC6, March 2000.
  25. http://pec.etri.re.kr/ectsp