종단간 멀티캐스트 전송을 위한 ECTP 표준 프로토콜

고석주* 박주영* 김은숙* 강신각**

최근 인터넷 기반의 TV, 교육, 주식정보, 오락, 뉴스, 홍보 등의 인터넷 방송 서비스에 대한 수요가 급격히 증가함에 따라, 인터넷 멀티캐스트 전송 기술이 주목을 받고 있다. 종단간 멀티캐스트 표준 기술의 경우, IETF RMT WG에서 신뢰전송 기술을 중심으로 3가지의 프로토콜을 제정 중에 있으며, 한편 ITU-T SG7 | ISO/IEC JTC 1/SC 6 표준기구에서는 ECTP(enhanced communications transport protocol) 프로토콜을 개발 중에 있다. 특히, ECTP 프로토콜은 한국의 ETRI에서 관련 기술 개발 및 표준화 작업을 주도하고 있으며, 조만간 종단간 멀티캐스트 관련 세계 최초의 표준권고안이 출시될 예정이다. 본 고에서는 ECTP 프로토콜에 대한 소개 및 현황에 대하여 살펴본다.

I. 서 론

지난 20여 년간의 연구개발에도 불구하고, 인터넷 멀티캐스트 기술은 아직 널리 도입되어 있지 않다. 소위 Killer 응용의 부재에서 그 원인을 찾아볼 수 있다. 최근 인터넷 기반의 TV/교육/오락/홍보/증권/뉴스 등의 인터넷방송 서비스 수요가 급격히 증가함에 따라, 멀티캐스트 전송서비스에 대한 수익창출이 가시화되고 있으며, 관련 기술의 도입 이슈가 주목을 받고 있다.

인터넷 멀티캐스트 기술은 크게 네트워크 계층에서의 라우팅 기술과 수송계층에서의 종단 호스트간 데이터 신뢰전송 및 세션관리 기술로 구분해 볼 수 있다. 네트워크 멀티캐스트 라우팅 기술의 경우, DVMRP, MOSPF, CBT, PIM-SM 등의 여러 표준들이 제안되어 왔으며, 현재 대부분의 상용 라우터에는 PIM-SM 기능이 탑재되어 있다. 한편, 최근에는 SSM(source specific multicast) 라우팅 방식이 주목을 받고 있으며, 기존의 방식과는 달리 하나의 멀티캐스트 채널 식별을 위해 송신자의 IP 주소 및 그룹주소를 함께 사용하며, 송신 트래픽에 대한 제어 및 과금 기능과, 확장성 측면에서 ISP들의 큰 호응을 얻고 있다[1-3].

수송계층에서의 종단간 멀티캐스트 기술의 경우, 확장성을 갖는 멀티캐스트 신뢰전송 기술 개발을 위해 그 동안 많은 연구개발이 이루어졌으며, 이를 바탕으로 현재 IETF RMT(reliable multicast transport) WG에서 3가지의 프로토콜을 표준화 중에 있다. 한편, ITU-T SG7 및 ISO/IEC JTC 1/SC 6 표준기구에서는 공동으로 ECTP(enhanced communications transport protocol) 표준 프로토콜을 개발 중에 있으며, 조만간 종단간 멀티캐스트 관련 국제 최초의 표준을 출시할 예정이다. ECTP 표준개발은 한국 ETRI에 의해 주도되어 왔으며, ECTP 규격은 IETF RMT 프로토콜에서 제공하는 신뢰전송 기능뿐만 아니라, 멀티캐스트 세션 연결에 대한 관리 및 서비스품질 관리 등의 강력한 세션관리 기능을 제공하고 있다. 특히, 세션관리 기능은 실제 인터넷방송 서비스에서 CP(contents provider)의 요구사항이 큰 분야이다[4-5].

본 고에서는 ITU-T 및 ISO/IEC JTC1 표준기구에서 제정 중에 있는 ECTP프로토콜에 대하여 소개한다. 먼저, 기존 IETF에서 진행 중인 신뢰전송 프로토콜에 대하여 살펴보고, ECTP 프로토콜의 특징 및 지금까지 진행된 표준화 및 구현 현황에 대해 기술한다.

II. IETF RMT 프로토콜

인터넷 멀티캐스트 신뢰전송 프로토콜에 대한 표준화 노력은, 1997년 3월 미국 Memphis에서 개최된 IRTF(Internet Research Task Force) RMRG(Reliable Multicast Research Group) 회의에서 시작되었다. 1999년 3월 IETF 회의에서 RMT WG이 발족하게 된다[6].

RMT WG은 소위 BB(building block) 개념에 입각하여, 먼저 기본적인 BB 문서를 표준화 하고, 이를 토대로 다음 3가지의 표준 프로토콜을 개발할 예정이다.

1. TRACK(TRee-based ACK) 프로토콜

소위 ACK(acknowledgement) 폭주(implosion) 문제를 해결하기 위해, 그룹 참여자(호스트)들을 하나의 논리적 트리로 구성한다. 트리에 의해 각 참여자간에 부모-자식(parent-child) 관계가 형성되며, 각 부모 노드는 자식 노드들에 대한 오류 제어 기능을 수행한다.

(그림 1)은 종단 호스트간의 논리적 트리를 보여준다. 그림에서 각 부모 노드는 DR(desig-nated receiver)로써 표기되고 있으며, 각 자식노드로부터 ACK 패킷 및 손실정보를 받은 후, 재전송을 통해 오류를 복구해 주고, 자기 로컬 그룹에 대한 데이터 송수신 상태 정보를 상위 부모 노드에게 전달한다. 이러한 상태정보에 입각하여 송신자는 흐름 및 혼잡제어를 수행하게 된다.

TRACK 관련 표준화는 미국의 Talarian사 및 Sun Microsystem사에서 주도하고 있으며, 한국의 ETRI에서도 일부 참여하고 있다. 현재 RMT WG에 등재된 관련 표준문서로써는, 먼저 트리 기반의 오류제어 메커니즘을 정의한 TRACK BB, 트리 구성 메커니즘을 정의한 Tree Configuration BB 및 보안 이슈를 정리한 TRACK Security 문서 등이 있다[6].

2. NORM 프로토콜

NORM(NACK Oriented Reliable Multicast)은 손실된 데이터의 복구를 요구하기 위해서 주로 NACK(negative ACK)를 사용한다. 근간이 되는 프로토콜은 SRM(scalable reliable multicast) 및 PGM(pretty good multicast) 프로토콜이 있다.

SRM은 whiteboard 응용처럼 IP멀티캐스트를 사용하는 불특정 다수의 세션 참가자들 간에 서로 신뢰적인 데이터를 주고 받을 수 있도록 설계된 프로토콜이다. SRM에서 NACK 메시지는 그룹주소로 멀티캐스트 되며, 재전송 요청 메시지 수를 줄이기 위해서 적절한 백오프(back-off) 타이머를 사용한다. PGM 방식은 네트워크 라우터를 이용하여 수송계층의 신뢰성을 제공하는 기법이다. 특히 이방식에서는 네트워크 계층의 라우팅 트리 자체를 오류 복구에 사용하게 된다. 각 수신자는 패킷 손실이 발생할 경우 송신자를 향해 NACK 패킷을 전송하고, 각 상위 라우터에서는 이러한 NACK를 취합하여 하나의 NACK 패킷을 차상위 라우터에 전송한다. 이를 위해 각 라우터는 수송계층의 NACK 패킷을 해석할 수 있어야 하고, 상태정보 또한 기억하고 있어야 한다. 또한 (그림 2)에서 보여지듯이, 여러 자식노드로부터의 중복된 NACK 전송을 방지하기 위해, 일단 NACK를 수신한 각 라우터는 하위 노드에게 NCF(NACK confirm) 메시지를 보내게 된다. 최종적으로 NACK가 송신자에 도착하면 송신자는 RDATA(retransmission data) 패킷을 통해 오류를 복구하게 된다. NORM 프로토콜 표준화는 위의 두 가지 방식을 기반으로 진행 중이며, 다른 방식에 비해 상대적으로 표준 개발 진행 속도가 느리다[6].

3. LCT 프로토콜

LCT(Layered Coding Transport) 프로토콜은 오류 복구를 위해 FEC(forward error correction) 기법을 사용한다. FEC 코딩 방식은 ACK/NACK 등의 수신자로부터의 피드백 없이 오류를 복구하는 방식으로, 송신자는 보내고자 하는 데이터 패킷과 parity 패킷을 함께 전송한다. 예를 들면, 송신 데이터 패킷이 k개 있을 경우, 송신자는 n-k개의 parity 패킷을 포함하여 총 n개의 패킷을 전송하게 된다(n>k). 수신자는 FEC 디코딩 단계에서 n개의 패킷 중 임의의 k개 패킷만 수신하면 원본 데이터를 재생할 수 있게 된다. (그림 3)은 n=k+1 인 경우의 예이며, 이 경우 대개 XOR 논리 연산을 수행하여 1개의 parity 패킷을 생성시키게 된다.

LCT 방식에서는 흐름 및 혼잡제어를 위해 여러 개의 멀티캐스트 채널을 사용하여 데이터를 송신한다. 각 수신자들은 자신의 버퍼 혹은 처리용량에 따라 다른 멀티캐스트 계층에 가입할 수 있다. 특히, LCT 방식에서는 수신자의 피드백 패킷을 사용하지 않으므로, 위와 같은 흐름 및 혼잡제어는 수신자 기반으로 이루어진다. 송신자는 컨텐츠의 특성 및 품질에 따라 원본 데이터를 여러 개의 채널로 나누어 보내며, 수신자는 자신의 수신 능력 및 서비스품질 요구사항에 따라 원하는 채널에 가입한다. 수신버퍼의 오버플로 혹은 네트워크의 혼잡이 탐지되는 경우, 일부 채널에서 탈퇴함으로써 혼잡 상태를 피할 수 있다. (그림 4)는 이와 같은 LCT 전송 메커니즘을 기술한다.

LCT 관련 표준 기술 개발은 FEC 관련 특허권을 보유하고 있는 Digital Fountain사에서 주도하고 있으며, RMT WG에 등재된 표준문서로는, FEC 코딩 방식을 정의하는 FEC BB와 오류복구 메커니즘을 기술하는 LCT BB 및 LCT 기반 혼잡제어 방식을 정의하는 LCC(layer congestion control) BB 문서가 있다[6].

III. ECTP

1. 특징 및 현황

기존 IETF RMT 프로토콜은 데이터 전송에 대한 오류제어 및 혼잡제어 등의 신뢰성 제공에 초점을 두고 있는 반면, ECTP 프로토콜은, RMT 프로토콜 기능을 포함할 뿐만 아니라, 특히 다음의 기능을 추가적으로 제공한다.

. 멀티캐스트 세션에 대한 연결 관리(connection management)

IP 멀티캐스트 모델은 그룹에 대한 멤버쉽 정보 및 연결관리 정보를 전혀 제공하지 못한다. 수신자들은 단순히 그룹 주소를 획득하여 네트워크 바인딩(binding)을 통해 데이터를 수신한다. ECTP는 종단간 그룹 참여자간에 세션 연결 및 관리 기능을 제공한다. 특히, 세션관리 기능은 멀티캐스트 상용서비스에 대한 송신자 혹은 CP(contents provider)의 입장에서 필수적으로 요구되는 기능이다. CP는 이러한 연결관리 기능을 통해, 제공하려는 멀티캐스트 세션 서비스를 관리하고 아울러 세션 참여자에 대한 정보를 수집하여 수익모델 창출에 활용할 수 있다.

. 서비스품질 상태 관리(QoS status management)

ECTP는 아울러 송신자로 하여금, 멀티캐스트 전송 데이터에 대하여 수신측의 QoS 상태 정보를 수집 및 파악할 수 있도록 지원한다. 이러한 세션상태 정보를 토대로, 송신자는 데이터 전송속도 조정 및 적절한 세션 QoS 유지 등의 조치를 취할 수 있으며, 나아가 QoS 상태 정보는 개별 수신 고객에 대한 과금 자료로써 활용도 가능하다.

. TRACK 기반 오류 제어

신뢰전송 기능, 특히 오류 제어 기능을 위해 ECTP는 별도의 메커니즘을 도입하지 않고 IETF의 TRACK 메커니즘을 활용한다. 특히, 트리 구조 및 ACK 패킷을 토대로 송신자 QoS 상태 감시 기능이 수행된다. 한편, 트리 구성 메커니즘에서, TRACK에서는 bottom-up 방식을 사용하는 반면에, ECTP는 top-down 방식을 적용한다[7].

ECTP 프로토콜은 현재 한국의 ETRI에서 정부차원의 표준화 과제로써 개발되고 있으며, ITU-T SG7 및 JTC1/SC6 기고활동을 통해 표준제정 완성단계에 있다. ECTP 관련 표준 규격은 ECTP-1[8] 및 ECTP-2[9] 세부 규격으로 나뉘어 진행되고 있으며, ECTP-1에서는 멀티캐스트 세션 연결관리 기능과 오류제어 기능을, 그리고 ECTP-2에서는 QoS 관리 기능에 대한 규격을 정의한다.

2. 프로토콜 개요

ECTP는 인터넷 멀티캐스트 응용을 지원하기 위한 수송계층 프로토콜이며, 네트워크 계층에서의 IP 멀티캐스트 전송 기능을 가정한다. 현재 one-to-many 멀티캐스트 전송 서비스를 주요 목표로 하여 신뢰전송 기능, 연결관리 기능 및 QoS 관리 기능 등을 제공한다. (그림 5)는 ECTP 프로토콜에서 제공되는 기능을 멀티캐스트 세션 시작, 진행 및 종료의 순서로 정리하고 있다.

먼저 송신자는 세션 생성(creation) 메시지를 그룹에 전송함으로써, ECTP 세션을 생성한다. 네트워크에 바인딩된 수신자들은, 확인(confirm) 메시지로 송신자에 응답함으로써, ECTP 세션에 가입한다. 이미 세션이 생성된 후 가입하려는 수신자는 송신자에게 Late Join 메시지를 전송함으로써 가입요청을 하게 되며, 적절한 인증절차를 수행한 후, 송신자는 Join Confirm 메시지로 응답한다.

확장성을 위해 논리적 트리가 구성되는 경우, 확인메시지가 전송되기 전에 송신자와 수신자들간에 트리 구성 절차가 진행된다. ECTP 트리는 송신자를 root 노드로 하여 leaf 수신자 노드를 향해 점진적으로 확장되는 top-down 트리 구성 방식을 사용한다[7]. (그림 6)은 ECTP 트리 구성 예를 보여준다. 트리 구성 메커니즘을 통해, ECTP 송신자(S) 및 수신자(R)들은 하나의 트리 구조로 구성된다.

ECTP는 또한 서비스품질협상(negotiation) 기능을 통해, 송신자와 수신자간에 처리율, 지연, 손실률 등의 QoS 변수 값들을 협상할 수 있도록 지원한다. 이 경우, 송신자의 세션생성 메시지는 목표(target) 값을 지정해주며, 수신자의 확인 메시지는 각 수신자의 제안(proposed) 값을 포함한다. 송신자는 수신자들의 제안 값을 합계하여 세션의 QoS 변수 값으로 결정한다.

ECTP 세션 생성이 생성된 후, 송신자는 멀티캐스트 데이터 전송을 시작할 수 있다. 전송되는 멀티캐스트 데이터에 대하여, TRACK 프로토콜처럼 트리 기반 오류제어 기능이 수행된다. 각 수신자는 각 멀티캐스트 데이터에 대한 성공적인 수신여부를 파악하여 ACK 패킷에 기록하며, 상위의 부모 노드에게 전달한다. ACK 패킷을 통해, 데이터 손실을 탐지한 부모 노드는, 해당 데이터 패킷을 자신의 로컬 그룹에 재전송한다.

세션이 지속되는 동안, ACK 패킷 응답 여부를 통해, 부모노드는 자식노드의 멤버쉽 유지 여부를 파악할 수 있다. 일정 기간 동안 응답이 없는 경우, 부모 노드는 해당 자식 노드가 탈퇴했음을 알고, 이를 송신자에게 전달한다. 이러한 절차를 통해, 송신자는 각 참여자의 멤버쉽 유지 정보를 얻게 된다. 각 수신자는 또한, 명시적인 탈퇴 메시지를 전송하여 세션을 탈퇴할 수도 있다.

QoS 감시 단계에서, 각 수신자는 세션의 QoS 상태 여부를 파악하기 위해, 처리율, 지연, 손실률 등의 QoS 변수 값을 일정한 방식에 의해 측정한다. 측정된 QoS 값은 ACK 패킷을 통해, 부모 노드에게 전달되며, 각 로컬 그룹별로 통합되어 송신자에게 전달된다. 이러한 방식으로 송신자는 전체 수신자들이 느끼는 QoS 상태를 파악할 수 있다. 이러한 QoS 상태정보는 QoS 유지 절차를 위한 기초 자료로 활용되며, 또한 추후 각 수신자에 대한 과금 정보로 활용될 수도 있다.

QoS 유지 단계에서, 송신자는 파악된 수신자들의 QoS 상태 정보를 토대로, 데이터 전송속도 조정, 세션 중지 및 재개시, 추방, 세션 종료 등의 적절한 유지 조치를 취할 수 있다. 데이터 전송이 모두 완료된 후 송신자는 세션을 종료한다.

3. ECTP 패킷

<표 1>에서 보여지듯이, ECTP 프로토콜은 데이터 패킷과 제어 패킷을 포함하여 총 13개의 패킷을 사용한다. CR과 CC 패킷은 연결생성을 위해 사용되며, TJ와 TC 패킷은 논리적 트리 구성에 사용된다. 세션 생성 후 송신자는 DT 데이터 패킷을 전송하며, 전송할 데이터가 없는 경우, ND 패킷을 전송하여 세션이 유지되고 있음을 알린다. 자식노드의 ACK에 의해 데이터 손실이 탐지될 경우, 송신자 혹은 부모노드는 RD 재전송 패킷을 전송하며, 또한 주기적인 HB 패킷을 전송하여 부모노드가 유지되고 있음을 알린다. 늦은 참여를 하는 수신자는 JR 패킷을 송신자에게 보내고, 송신자는 JC 패킷을 통해 세션 가입을 수락한다. 탈퇴하는 수신자는 LR 패킷을 부모노드에 전송하며, 또한 문제를 일으키는 자식노드에 대해, 부모노드는 LR 패킷을 전송할 수 있다. 세션 종료를 위해 송신자는 CT 패킷을 그룹에 전송한다.

4. ECTP 구현

본 절에서는 멀티캐스트 응용이 ECTP를 사용하기 위한 API(application programming interface)에 대해 소개한다. 먼저, ECTP API는 TCP, UDP 기반 응용처럼, 이미 구현되어 널리 사용되고 있는 응용 프로그램이 쉽게 ECTP를 사용할 수 있도록 설계되었다. 이러한 요구사항을 만족시키기 위해 ECTP API는 버클리 소켓 기반으로 개발되었다. 버클리 소켓을 고려한 이유는 우선 현재의 인터넷에서 네트워크 프로그램을 할 때 가장 많이 사용되어지는 API이며, 추가적인 기능 정의 및 확장이 쉽기 때문이다. <표 2>에 ECTP API인 msocket 함수들을 나열하였다.

ECTP msocket API는 2가지의 분류로 나눌 수 있는데, 첫번째 분류 I은 현재 버클리 소켓에서 제공하는 함수들과 동일한 사용법과 의미를 갖는 함수들이고, 분류 II는 버클리 소켓의 함수는 같은 의미를 가지고 있지만, 사용되는 매개변수가 추가된 경우이다. 각 msocket API는 버클리 소켓 API를 기본으로 하여 wrapping 함수의 형태로 정의하였다.

ECTP구현 방식은 BSD커널의 동작을 따른다. 구현된 프로토콜 개체는 데몬의 형태로 동작하도록 하였으며, 응용 프로그램들은 msocket 라이브러리를 포함하여 ECTP를 사용할 수 있도록 하였다.

ECTP는 (그림 7)과 같은 형태로 UDP상에서 구현되었다. 응용들은 ECTP와 통신하기 위하여 msocket 라이브러리를 통한 IPC(inter-process communications) 방식을 이용하였다. msocket은 크게 3부분으로 나뉘어진다. 첫번째는 응용 프로그램에 제공되는 API의 형태로써 구현되어지며, 두번째는 소켓 시스템 호출을 통한 IPC통신을 맡는 부분, 마지막으로는 가상커널 내부의 소켓계층에서의 소켓 함수들로 구성된다.

이와 같은 방식은 응용계층과 독립적인 수송계층 프로토콜을 구현하기에 적합하며, 응용 프로그램과는 무관하게, 시스템 호출이나 쓰레드, 타이머 관리 등을 할 수 있다는 장점이 있다. 또한 구현 프로토콜 스택 구조를 현재 버클리 유닉스 계열의 커널과 동일한 방식으로 구현하였다.

(그림 8)에서는 ECTP의 내부 구조를 나타내었다. ECTP의 내부구조는 크게 6부분으로 구성할 수 있는데, ECTP 주 모듈에서는 사용자 요청과 입력된 패킷들을 처리하는 주요 기능을 담당한다. 입력과 출력 프로세싱을 담당하는 모듈에서는 패킷의 무결성의 검사, 마킹을 비롯하여 입출력 버퍼를 관리하는 일을 담당한다. 그 밖에 하나 이상의 응용 프로그램을 지원하기 위하여 하나 이상의 PCB(protocol control block)을 관리하는 모듈을 정의하였으며, 세션의 성격을 담당하는 부분과 각종 타이머를 관리하는 모듈을 구분하여 ECTP를 구성하였다.

IV. 결 론

지금까지, ETRI의 주도로 ITU-T 및 JTC1 표준기구에서 표준화되고 있는 ECTP 표준기술에 대하여 살펴보았다. 관련 표준화 작업은 사실상 마무리 단계에 있으며, 조만간 국제표준권고안이 출시될 예정이다. 또한, ECTP 구현 및 검증 작업이 완료단계에 있다.

인터넷 방송 등의 서비스 활성화와 함께, ECTP 등의 멀티캐스트 기술이 주목을 받고 있다. 현재 대부분의 인터넷 방송 서비스는 유니캐스트 기반으로 이루어지고 있으나, 동시 접속자 수 증가로 인한 서버 과부하 문제 및 서비스 품질 저하 문제 등으로 어려움을 겪고 있으며, 멀티캐스트 도입 및 기술 활용을 통해 이러한 문제점이 해결될 것으로 기대된다. 특히, 인터넷 생중계 방송 등의 서비스에서 동시 접속자 수 증가 문제를 해결하기 위해서는 멀티캐스트 기술의 활용이 필수적이다. 이처럼 관련 서비스의 활성화에 따라, 그 동안 잠자고 있던 멀티캐스트 기술이 인터넷에 본격적으로 도입 및 활용될 것으로 전망된다.

<참 고 문 헌>

[1]    고석주 외, 인터넷 멀티캐스트 신기술 동향, ETRI 전자통신동향분석, 제16권 제2호, 2001. 4, pp.1-9.

[2]    고석주 외, 차세대 인터넷 멀티캐스팅 기술 동향, 한국통신학회 정보통신지, 제17권 제9호, 2000. 9, pp.168-187.

[3]    고석주 외, 인터넷 멀티캐스트 라우팅 기술 동향, ETRI 전자통신동향분석, 제15권 제3호, 2000. 6, pp.28-41.

[4]    고석주 외, 멀티캐스트 신뢰전송 기술 및 표준화 동향, ETRI 주간기술동향, 00-16호, 2000. 5, pp.16-33.

[5]    http://ectp.etri.re.kr/

[6]    http://www.ietf.org/html.charters/rmt-charter.html

[7]    김은숙 외, An ACK Tree Creation Mechanism using Top-Down Scheme for Tree-based Reliable Multicast Transport Protocols, IC 2001 Conference at Las Vegas, USA, July 2001.

[8]    ITU-T draft Recommendation X.ectp-1|ISO/IEC 14476-1, Enhanced Communication Transport Protocol: Specification of Simplex Multicast Transport, April 2001.

[9]    ITU-T draft Recommendation X.ectp-2|ISO/IEC 14476-2, Enhanced Communication Transport Protocol: Specification of QoS Management for Simplex Multicast Transport, April 2001.