1

IPv6 기반 SSM 기술동향! "#!$%&'%(&)!*+!,*-'.&/,0&.(+(.!1-23(.453!6&.7#*2*89!(#!:;%<!=&3)*'> 정상진 (S.J. Jeong) 신명기 (M.K. Shin) 김형준 (H.J. Kim) 차세대인터넷표준연구팀연구원 차세대인터넷표준연구팀선임연구원 차세대인터넷표준연구팀책임연구원, 팀장 현재 IP 네트워크상의멀티캐스트기법은 ASM 모델로서다대다멀티캐스트로구현되어있다. 그러나, ASM 모델은확장성및멀티캐스트그룹비가입자에대한접근제어방법등의문제를가지고있는것으로밝혀지고있다. 현재 IETF 의 SSM WG 에서는이러한문제를해결하기위한단대다소스기반멀티캐스트프로토콜을제안하여표준화작업을진행하고있다. 본고에서는 IPv6 네트워크에서소스기반멀티캐스트프로토콜및멀티캐스트그룹관리프로토콜에대하여설명하고, 이를구현하기위한기능요구사항에대하여살펴본다. I. 서론 Steve Deering 에의하여처음제안된 IP 멀티캐스트모델은기본적으로 ASM(Any-Source Multicast) 기반다대다 (many to many) 서비스를정의하고있다 [1]. 그동안의대부분의멀티캐스트관련연구및서비스도입은 ASM 모델을기반으로하고있다. 그러나, 실제 ASM 서비스를도입한결과, ASM 은멀티캐스트트리상의각라우터들이멀티캐스트세션에대한상태정보를유지해야하기때문에확장성문제가대두되었으며, 대부분의멀티캐스트서비스는다대다통신이아닌 VOD와같은형태의단대다 (one to many) 서비스가대부분을차지하였다. 그리고, 멀티캐스트주소의할당, 멀티캐스트그룹접근제어등의문제도중요한이슈로등장하였다 [2]. 이러한 ASM의문제를해결하기위해서 1999년 IETF에서는단대다환경에적합한새로운멀티캐스트모델인 SSM(Source-Specific Multicast) 을제안하였으며, 현재표준화가진행중이다 [3],[4]. SSM 모델은멀티캐스트트래픽송신자 S와멀티캐스트그룹 G의쌍으로서멀티캐스트채널을구분한다. 따라서, 기존의 ASM 모델과는달리 SSM에서는송신자의 IP 주소를지정하지않고보내지는멀티캐스트패킷들은각라우터에서차단된다. < 표 1> 은 ASM과 SSM을비교한것이다. SSM을제공하기위해서 IPv4 네트워크에서는 IGMPv3(Internet Group Management Protocol version 3) 이필요하며 IPv6 네트워크에서는 MLDv2 (Multicast Listener Discovery version 2) 이필요하다 [5]. 본고에서는 SSM 프로토콜과 MLDv2 프로토콜규격에대하여설명하며, IPv6 기반 SSM을제공하 < 표 1> ASM과 SSM의비교서비스모델 ASM SSM 네트워크추상화그룹채널세션구분자 G S, G 수신측동작 Join, Leave (Un)Subscribe 47

전자통신동향분석제 18 권제 4 호 2003 년 8 월 기위한 MLDv2의요구사항에대하여기술한다. 이를위해 I장서론에이어 II장에서는 SSM 프로토콜규격에관하여기술하고, III장에서는 MLDv2 프로토콜규격에대하여서술한다. 그리고 IV장에서는 SSM 구현을위한 MLDv2의요구사항에관하여설명하고, 마지막으로 V장에서결론을맺는다. II. SSM 프로토콜개요 SSM 모델은소스의 IP 주소 S와멀티캐스트그룹주소 G로표현되는 SSM 채널 (S, G) 에호스트들이가입하고, 송신자에게서전송되는트래픽들은 (S, G) 에가입한멀티캐스트청취자들에게만전송된다. 또한, 하나의 SSM 채널에대해서오직하나의멀티캐스트송신자가존재할수있다. 따라서 SSM은단대다멀티캐스트를지원한다. ( 그림 1) 은 SSM 동작구조를나타낸것이다. 각모듈의기능은다음과같다 [3]. Address allocation 현재 SSM 서비스를위한전용 IP 주소공간이할당되어있다. IPv4 네트워크에서는 232/8이 SSM을위해할당되어있으며, IPv6에서는 FF3x::/32가 SSM 서비스를위해할당되어있다. ( 그림 2) 는 SSM 주소형식을나타낸것이다. RFC 3306에의해정의된주소형식에따르면, SSM 주소형식에서 plen 필드와 network prefix 필드는모두 0으로설정하도록되어있으며, ( 그림 2) 에도시된 flag 필드에서 P 와 T 필드의값은각각 1로설정하도록되어있다 [6]. 따라서, 실제 SSM 주소공간은 FF3x::/96으로표현된다. 그러나, 향후나머지주소공간도사용될수있으므로 SSM을구현할때 FF3x::/32의주소공간을지원하도록해야함 Session description and Channel discovery SSM 서비스를수신하고자하는응용은채널에가입하기전에미리 S와 G를알아야한다. SSM에서채널발견은각응용이담당을한다. SSM의채널발견은웹페이지를이용한공개또는별도의세션정보통보응용을이용해서이루어짐 IANA assigned 232/8 for IPv4 FF3x::/96 for IPv6 ( 그림 1) SSM 동작흐름도 ADDRESS ALLOCATION session directory/web page source, group SESSION DESCRIPTION Query SSM-aware app SSM-aware app IGMPv3/MLDv2 IGMPv3/MLDv2 8 PIM-SSM PIM-SSM (S, G) (source specific host report) (S, G) Join Only Backbone Router (S, G) Join Only CHANNEL DISCOVERY SSM-AWARE APPLICATION IGMPv3/MLDv2 HOST REPORTING ( 그림 2) IPv6 SSM 주소형식 QUERIER PIM-SSM ROUTING 4 4 8 8 64 32 11111111OOPTscope reserved plen network prefix group ID SSM aware applications SSM 세션에가입하고자하는응용은사전에현재사용중인채널의발견작업을수행해야한다. 응용은종단호스트의네트워크계층의프로토콜에멀티캐스트소스주소와그룹주소를이용하여채널정보를전달할수있어야함 IGMPv3/MLDv2 host reporting and querier 종단호스트는소스주소와그룹주소를이용해서채널을설정할수있어야함 PIM-SSM 라우팅멀티캐스트라우터들이 SSM 주소공간에대해서 ASM 스타일의동작을방지하기위해서는다음사항을만족해야함 - Designated Router(DR) 이 SSM 주소공간에대한 (S, G) Join 요청을받았을때, (S, G) Join 을처리해야하며, (*, G) Join 메시지를발생시키면안됨 48

IPv6 기반 SSM 기술동향 - 백본라우터들은 (*, G) Join 요청을 SSM 주소공간에대해서전달하면안됨 - RP는 SSM 주소공간에대해서 PIM 등록메시지또는 (*, G) Join 메시지를받아들이면안됨 III. MLD 프로토콜개요 MLD(Multicast Listener Discovery) 프로토콜은 IPv6 라우터가자신에게직접연결된링크상에멀티캐스트수신자가있는가를탐색하기위해사용되는프로토콜이다. MLD를이용하여라우터는특정멀티캐스트그룹주소에어떤호스트들이가입되어있는가를알수있다. MLD는 IPv4 멀티캐스트를위한 IGMPv2를 IPv6 환경에맞도록수정한것으로, 현재 IGMPv3 를기반으로한 MLDv2의표준화가추진되고있다. MLDv2 는 MLDv1의기능에소스필터링 (source filtering) 기능이추가된것으로 MLDv1과호환되도록설계되었다 [5]. 1. MLDv2 프로토콜메시지형식 MLDv2 프로토콜은 ICMPv6 프로토콜의서브프로토콜로서 MLDv2 메시지는 IPv6 패킷내에서 Next Header 58의값으로식별된다. 모든 MLDv2 메시지는링크로컬 IPv6 주소를발신주소로표시해서전송되어야하며, 송신노드가 IPv6 주소를할 당받지못한경우에는 IPv6 unspecified 주소를발신주소로표시해서전송해야한다. 또한, IPv6 패킷헤더내의 Hop Limit 필드를 1로설정을하고, Hop-by-Hop 옵션헤더내의 IPv6 라우터 alert 옵션도설정되어있어야한다. MLDv2 프로토콜에는현재다음의두가지의메시지가정의되어있다 [5]. - Multicast Listener Query: 멀티캐스트라우터가자신의이웃노드들의멀티캐스트수신상태를수집하기위해서사용하는메시지 - Version 2 Multicast Listener Report: IP 노드가이웃한라우터들에게자신의현재멀티캐스트수신상태및멀티캐스트수신상태의변화를보고하기위해서사용위에서정의된메시지이외의메시지들은라우터에서차단된다. ( 그림 3) 은멀티캐스트청취자질의메시지의형식을나타낸것이다. 멀티캐스트메시지는 ICMPv6 패킷내에포함되며 28옥텟의고정부분과가변부분으로구분된다. 각필드에대한설명은다음과같다. Type: 메시지종류를나타내며 130으로설정 Code: 송신측에서 0으로설정하며, 수신측에서는무시됨 Checksum: ICMPv6 의사헤더를포함해서전체 MLDv2 메시지에대해서계산함 Maximum Response Code: 질의메시지를받 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type=130 Code Checksum Maximum Response Code Reserved IPv6 Multicast Address Resv S QRV QQIC Number of Sources(N) IPv6 Source Address[i] ( 그림 3) MLDv2 청취자질의메시지형식 49

전자통신동향분석제 18 권제 4 호 2003 년 8 월 은수신자가리포트메시지를전송하기전에일정시간동안전송을지연시키는최대허용값을밀리초단위로지정 ( 지연값이 32768밀리초이상인경우에는부동형소수점형식으로표현하며, 최대 140분정도까지지연을주는것이가능함 ) Reserved: 송신측에서 0으로설정하며, 수신측에서는무시됨 Multicast Address: 질의하고자하는멀티캐스트그룹주소를나타냄 ( 일반질의를보내는경우에는멀티캐스트그룹주소를 0으로설정 ) Resv: 송신측에서 0으로설정하며, 수신측에서는무시함 S Flag(Suppress Router-side Processing): 1 로설정된 MLDv2 메시지를수신하는멀티캐스트라우터들은질의의응답을기다리면서수행하는타이머업데이트를억제함 QRV(Querier s Robustness Variable): 질의자에의해서설정되며, 0이아닌값의경우에는질의에대한응답을전송할때, 최대 QRV의값만큼의재전송을함으로써메시지의손실을방지함 QQIC(Querier s Query Interval Code): 질의자가멀티캐스트청취자들에게질의메시지를보내는시간간격을초단위로표시 Number of Source(N): 질의메시지내에포함된멀티캐스트송신자주소의수를나타냄 (Multicast Address and Source Specific Query에서만사용 ) Source Address[i]: n개의멀티캐스트송신자의유니캐스트주소를벡터로표시 MLDv2의질의는다음의세종류가사용된다. - General Query: 어떤멀티캐스트주소를사용하는링크상에멀티캐스트청취자가있는가를조사하기위해서사용하며, 멀티캐스트주소필드와 Number of Sources 필드는 0으로설정함 - Multicast Address Specific Query: 특정멀티캐스트그룹주소에대한청취자가있는가를알아보기위해사용하며질의를하려는멀티캐스 트그룹주소를멀티캐스트주소필드에설정함 - Multicast Address and Source Specific Query: 특정멀티캐스트그룹의소스리스트들중특정송신자에대한멀티캐스트청취자가있는가를알아보기위해사용함 MLDv2에서 General Query는 IPv6 링크 scope 멀티캐스트주소 (FF02::1) 를목적지로전송되어야하며, Multicast Address Specific과 Multicast Address and Source Specific Query는질의하려는멀티캐스트그룹주소가목적지주소가된다. ( 그림 4) 는멀티캐스트청취자리포트메시지의형식을나타낸것이다. 각메시지필드에대한설명은다음과같다. Type: IANA에의해서값이할당될예정임 Reserved: 송신측에서 0으로설정하며, 수신측에서는무시됨 Checksum: ICMPv6 의사헤더를포함해서전체 MLDv2 메시지에대해서계산함 Number of Multicast Address Records(M): 청취자리포트메시지에포함된멀티캐스트그룹주소레코드의수를나타냄 Multicast Address Record: 청취자리포트의송신자가현재자신이가입하고있는멀티캐스트그룹의주소들을나타냄멀티캐스트그룹주소레코드는다음의세종류로구분되며, 청취자리포트의송신자의현재멀티캐스트청취상태를나타낸다. - Current State Record: 가입한멀티캐스트그룹주소에대해서현재인터페이스의멀티캐스트청취상태를표시 - Filter Mode Change Record: 응용의 API 호출로인하여인터페이스의필터모드가변할때마다전송됨 - Source List Change Record: 응용의 API 호출로인해서인터페이스의필터모드의변화는동 50

IPv6 기반 SSM 기술동향 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type=To Be Allocated Reserved Reserved Checksum Number of Multicast Address Records(M) Multicast Address Record[1]. Multicast Address Record[M] ( 그림 4) MLDv2 청취자리포트메시지형식 반하지않고, 소스리스트만변했을경우전송됨 Start MLDv2 프로토콜은 INCLUDE 모드와 EX- CLUDE 모드두가지의인터페이스필터모드를지 Initialize interface(s) 원한다. INCLUDE 모드인경우에는멀티캐스트청취자가가입한그룹 G에대해서멀티캐스트송신자그룹 S에표시된송신자들이보내는멀티캐스트패 Send general query periodically Querier election 킷만을수신하는상태를나타낸다. EXCLUDE 모드인경우에는멀티캐스트그룹 G에대해서송신자그 Update MLD state Initialize timers 룹 S에표시된송신자들을제외한다른멀티캐스트송신자들이보내는멀티캐스트패킷만을수신하는상태를나타낸다. Report Multicast report or query is received? Query 2. MLDv2 프로토콜동작개요멀티캐스트라우터는자신에게부착된링크상에서어떤멀티캐스트그룹주소가청취자를가지는가를알기위하여 MLDv2 프로토콜을사용한다. 각각의라우터는각링크에대해서멀티캐스트그룹주소와해당그룹주소에대한송신자목록및인터페이스의필터코드정보를다음과같은형식으로유지하고있다 (IPv6 multicast address, multicast address timer, filer mode, {source records list}). 인터페이스의설정이완료되면라우터는자신에게연결된각각의링크에대해서 Querier 또는 Non-Querier를수행하게된다. 하나의링크에두 Reception of multicast reports Update MLD state and source timers End ( 그림 5) MLDv2 라우터동작흐름도 Reception of query Update timers and send queries 개이상의멀티캐스트라우터가존재하는경우에는 IP 주소의값이작은라우터가 Querier를담당한다. 라우터는자신에게연결된링크의멀티캐스트주소 51

전자통신동향분석제 18 권제 4 호 2003 년 8 월 Change of interface state (Invocation of IPv6MulticastListen) Start Reception of a query Generate state change report & immediately transmit Check query (src IP, Hop Limit, Router alert option) Retransmit report (up to QRV-1 times) Loss? Yes No End No Validity verified? Yes No State change during transmission? Choose random amount of time [0, Max resp delay] Yes Merge pending report & new state report & transmit No Generate report & schedule the report Timer in pending response expires? Yes Generate new report & clear source list & transmit ( 그림 6) MLDv2 청취자동작흐름도 에대해서주기적으로 General Query를전송함으로써, 현재링크상에멀티캐스트청취자가존재하는가를발견한다. MLDv2 라우터의동작과정은 ( 그림 5) 와같다. 라우터가멀티캐스트청취자로부터청취자리포트를수신하게되면리포트내에포함된청취자의가입한멀티캐스트그룹주소, 필터모드, 소스주소리스트를이용해서라우터의인터페이스상태를갱신하게된다. MLDv2 청취자동작흐름도는 ( 그림 6) 과같다. 멀티캐스트청취자가 General Query를수신할때질의를받는인터페이스상에서듣는각각의멀티캐스트주소에대한타이머를설정하며, 타이머의값은질의메시지에포함된 Maximum Response Code 의값에의해설정된다. Multicast Address Specific Query 또는 Multicast Address and Source Specific Query를수신한경우에는질의를수신한인터페이스를이용해서해당멀티캐스트주소를듣는경우에만해당주소에대한타이머를갱신하고질 의에대한응답을보내게된다. 멀티캐스트응용의 API 호출로인해서청취자의멀티캐스트인터페이스의상태가변한경우호스트는 Current State Report를생성해서라우터에게전송하게된다. 이때, Report의전송을보장하기위해서전송도중패킷의손실이발생하면 Report 내의 QRV 필드의값에따라서최대 QRV-1번만큼의재전송을하게된다. IV. SSM 도입을위한요구사항 본장에서는 SSM 서비스의도입을위한 MLDv2 와 PIM-SM 프로토콜의요구사항에대하여알아본다. 1. SSM 을위한 MLDv2 의요구사항가. 멀티캐스트청취자의요구사항 MLDv2에서는총여섯가지의 Report Type이 52

IPv6 기반 SSM 기술동향 정의되어있으나 SSM을위해서는다음의네가지의 Report Type을사용하며, 이외의 Report Type 은사용되어서는안된다 [7]. MODE_IS_INCLUDE: Current State Record 에사용 ALLOW_NEW_SOURCES: Source List Change Record 에사용 BLOCK_OLD_SOURCES: Source List Change Record 에사용 CHANGE_TO_INCLUDE_MODE: SSM 주소범위가변경된경우호스트에의해서전송될수있음멀티캐스트라우터는 Multicast Group and Address Specification Query를이용하여특정 SSM 채널에대한가입자정보를획득하게되므로, 각호스트들은수신한 Multicast Group and Address Specification Query의멀티캐스트그룹주소및소스주소가자신이가입한 SSM 채널과일치할때 Query에대한응답을라우터에게보내야한다. 나. 멀티캐스트라우터의요구사항 SSM을위한 MLDv2 라우터는다음의두가지의 MLDv2 Report 를무시해야한다. MODE_IS_EXCLUDE: Current State Record CHANGE_TO_EXCLUDE_MODE: Filter Mode Change Record SSM을위한 MLDv2 General Query는 MLDv2 의규격을따른다. MLDv2 Multicast Address Specific Query는 MLDv2의규격에서는명시적으로제한하고있지않지만, 실제 SSM을위한 MLDv2 를지원하는라우터들은 Multicast Address Specific Query를전송하지않는다. MLDv2 Multicast Address and Source Specific Query에대해서는 SSM 서비스를위해할당된주소공간에대해서만 Query를보내도록구현되어야한다. 2. SSM 을위한 PIM-SM 의요구사항 SSM은 PIM-SM과같은기존의멀티캐스트라우팅프로토콜과함께사용될수있으며, PIM-SM 의규격내에 SSM의기능구현을위한요구사항이기술되어있다 [8]. 가. SSM 호스트의요구사항 SSM은기존 PIM-SM 프로토콜의일부분을확정해서구현할수있다. SSM 호스트의 IP 모듈인터페이스는다음의확장기능이필요하다. SSM 채널에가입및탈퇴를할수있는응용수준의 API 제공 패킷을수신하는인터페이스가수신자가패킷의목적지를검사할수있는기능을제공하지않는경우에는 OS 수준에서자신이수신자가아닌패킷들을필터링할수있도록해야함 SSM 주소로목적지주소가표시된패킷들은 IP 모듈에의해서 SSM 채널에가입한각소켓들에게채널주소에의해서구분되어전달되어야하며, 채널에가입하지않은소켓들에는전달되어서는안됨 채널의가입및탈퇴는 MLDv2의메시지에의해서이루어짐나. SSM 라우터의요구사항라우터의패킷포워딩모듈에서 SSM 주소를목적지로하는 IP 패킷을라우터가수신했을경우, 라우터자신에게연결된링크상에수신자가없는경우에는패킷을무시하게된다. MLDv2 프로토콜에대한라우터의요구사항은다음과같다. SSM 주소공간에대한 (*, G) 메시지를라우터가수신했을경우라우터는패킷의포워딩상태를설정해서는안되며, 다른이웃의라우터들에게 (*, G) 메시지를전달해서도안됨 라우터가 SSM 주소공간에대해서 non-source 53

전자통신동향분석제 18 권제 4 호 2003 년 8 월 specific 호스트리포트를수신했을경우에는무시하게됨 패킷의링크계층의전송에대한요구사항은다음과같다. 대부분의 shared-medium 링크계층네트워크들은링크계층의목적지주소를선택하기위해서 IP 주소를사용하지않는다. 따라서, 멀티캐스트그룹주소 G로전송되는패킷은 (S, G) 의 SSM 채널에서 S에상관없이 G에가입한모든호스트들에게전송된다. 그러므로, 링크계층에서수신한패킷들을소켓계층으로전달하기전에 IP 모듈에서패킷을필터링하는기능을제공해야한다. 3. SSM 을위한 IPv6 응용 API SSM을위한 MLDv2의 IPv6 응용 API는 IPv6 Specific API와 Protocol Independent API 두가지가정의되어있다. IPv6 Specific API는 Free- BSD 플랫폼기반으로구현되어있으며다음의 API 를위한구조체를가진다 [9]. struct ipv6_mreq_source { struct in6_addr ipv6mr_multiaddr; struct in6_addr ipv6mr_sourceaddr; uint32_t ipv6mr_interface; }; 제공되는 API는 setsockopt() 이며, API는 < 표 2> 와같은옵션을가질수있다. < 표 2> IPv6 API 옵션 Socket option Argument type IPv6_ADD_SOURCE_MEMBERSHIP struct ipv6_mreq_source IPv6_DROP_SOURCE_MEMBERSHIP struct ipv6_mreq_source IPv6_BLOCK_SOURCE struct ipv6_mreq_source IPv6_UNBLOCK_SOURCE struct ipv6_mreq_source Protocol Independent API는 IETF의 MAGMA WG에서표준화가추진중이며, 다음과같은 API 구 조체를가진다 [10]. struct group_source_req { uint32_t gsr_interface; struct sockaddr_storage gsr_group; struct sockaddr_storage gsr_source; }; 제공되는 API는 IPv6 Specific API와마찬가지로 setsockopt() 이며, API는 < 표 3> 과같은옵션을가질수있다. < 표 3> Protocol Independent API 옵션 Socket option Argument type struct MCAST_JOIN_SOURCE_GROUP group_source_req MCAST_LEAVE_SOURCE_GROUP struct group_source_req MCAST_LEAVE_GROUP struct group_req V. 결론 본고에서는기존멀티캐스트모델의단점으로나타난멀티캐스트주소의할당, 멀티캐스트그룹접근제어등의문제를해결하기위해서 IETF에서새롭게표준화추진중인 SSM 프로토콜과 MLDv2 프로토콜규격에대하여설명하였으며, IPv6 기반 SSM을제공하기위한 MLDv2의요구사항과 IPv6 응용 API에대하여기술하였다. SSM 모델은다대다멀티캐스트서비스를제공하지못한다는단점을가지고있지만, 최근인터넷에실제로도입되고있는대부분의멀티캐스트서비스들은응용서비스사업자중심의단대다멀티캐스트서비스이므로대부분의멀티캐스트서비스에적용될수있을것으로기대된다. 참고문헌 [1] S. Deering, Host Extensions for IP Multicasting, IETF RFC 1112, Aug. 1989. 54

IPv6 기반 SSM 기술동향 [2] C. Diot, B. Levine, B. Lyles, H. Kassem, and D. Balensiefen, Deployment Issues for the IP Multicast Service and Architecture, IEEE Network, Vol. 14, No. 1, Jan. 2000. [3] S. Bhattacharyya et al., An Overview of Source- Specific Multicast(SSM), draft-ietf-ssm-overview- 05.txt, Work in progress, May 2003. [4] H. Holbrook et al., Source-Specific Multicast for IP, draft-ietf-ssm-arch-03.txt, Work in progress, May 2003. [5] R. Vida and L. Costa, Multicast Listener Discovery Version 2(MLDv2) for IPv6, draft-vida-mld-v2-07.txt, Work in progress, June 2002. [6] B. Haberman and D. Thaler, Unicast-Prefix-based IPv6 Multicast Addresses, IETF RFC 3306, Aug. 2002. [7] J. Holbrook et al., Using IGMPv3 and MLDv2 For Source-Specific Multicast, draft-holbrook-idmrigmpv3-ssm-04.txt, Work in progress, May 2003. [8] B. Fenner et al., Protocol Independent Multicast Sparse Mode(PIM-SM): Protocol Specification(Revised), draft-ietf-pim-sm-v2-new-07.txt, Work in progress, Mar. 2003. [9] http://mldv2.lip6.fr/index.html [10] D. Thaler et al., Socket Interface Extensions for Multicast Source Filters, draft-ietf-magma-msfapi-04.txt, Work in progress, Mar. 2003. 55