Network Working Group Yue.Chen Internet-Draft Zhengzhou Institute of Information Expires: October 8, 2011 Science and Technology Julong.Lan NDSC Pengxu.Tan Hongyong.Jia Zhengzhou Institute of Information Science and Technology Dourui.Yu NDSC April.8, 2011 A Virtual Channel based Inter-domain Any Source Multicast Protocol draft-ychen-vc-id-asm-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2011. Copyright Statement Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with Y.Chen et al. Expires October 10, 2011 [Page 1] Internet Draft Virtual Channel Any Source Multicast April.8 respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 6.b of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Abstract This document defines VC-ID-ASM, a virtual channel based inter- domain any source multicast protocol. Based on extended source specific multicast, the participants join a virtual channel and a shared tree is formed. The receivers receive the multicast traffic along the shared tree, sense the source addresses and then initiate the switch process from the shared tree to the source trees. Table of Contents Copyright Statement............................................... 1 1 Introduction.................................................... 2 2 VC-ID-ASM....................................................... 3 2.1 Many-to-many Group Communication and Group Address Consideration..................................................... 3 2.2 Initial Shared Tree Setup by Extended PIM-SSM................. 5 2.2.1 Virtual channel selection................................... 5 2.2.2 (*,g) state................................................. 5 2.2.3 IGMP/MLD message extension and DR's processing.............. 5 2.2.4 JOIN/REQS/LEAVE message processing by extended PIM-SSM...... 6 2.2.5 Switching from the Shared Tree to the Source Trees.......... 7 2.2.6 VC-ID-ASM Packet Forwarding Rule............................ 8 3 Security Considerations......................................... 8 IANA Considerations............................................... 8 Normative References.............................................. 8 Author's Address.................................................. 9 1 Introduction IP multicast model includes Any Source Multicast (ASM) and Source Specific Multicast (SSM) models. ASM provides many-to-many packet delivery, while SSM provides one-to-many packet delivery in IP layer. The typical intra-domain ASM protocol is Protocol Independent Multicast Routing Protocols-Sparse Mode (PIM-SM)[1]. In PIM-SM, the multicast traffic firstly gathers to a Rendezvous Point (RP), and Y.Chen et al. Expires October 8, 2011 [Page 2] Internet Draft Virtual Channel Any Source Multicast April.8 then reaches the receivers along the shared tree rooted at RP. When the routers directly connected with the receivers (DRs) sense a multicast source, they initiates join to the source and multicast tree rooted at the source is formed. But PIM-SM has the following flaws. (1) It relies on RP, and will cause heavy traffic at and around RP. Computing and distribution the mapping of a group and a RP will consume a great deal computing and bandwidth resource. (2) It is complex, especially in the source registration process. (3) It cannot support inter-domain multicast by itself. One inter- domain scheme is MBGP[2]/PIM-SM[1]/MSDP[3]. But the scheme has serious problems in scalability, security, and group address management. Another inter-domain multicast schema put forward by IETF is MASC/BGMP. Because of its complexity, it is not widely used. The above flaws baffle the deployment of the large scale inter- domain ASM application, and it is urgent to put forward a simple effective inter-domain ASM protocol. Compared with ASM, SSM is a simple. The typical protocol of SSM is PIM-SSM[6], which is a subset of PIM-SM. The introduction of the channel eliminates the dependency to RP and make it directly support inter-domain single source multicast application. Inspired by SSM, VC-ID-ASM, a virtual channel based inter-domain any source multicast protocol, is put forward. It uses the extended PIM-SSM to build a many-to-many inter-domain shared tree for initial group communication and switch to the source trees when the receivers sense the sources for the received packets' heads. Compared with the other schemes, VC-ID-ASM is simple and can support inter-domain ASM application by itself. 2 VC-ID-ASM 2.1 Many-to-many Group Communication and Group Address Consideration The multi-source group communication process of VC-ID-ASM includes two steps. Step1: forming the initial shared tree and source discovery. Firstly, a visual channel identifier , including it supports a specific ASM application, is published in certain ways (via web pages, etc). s is an addressable IP address (commonly a address in core network equipment, near the center of the participants) . s is not the real multicast source, and it only tells the routers what direction they should send the JOIN(for applying receiving the traffic)/REQS(for applying sending the traffic) messages. g is a multicast group identifier. Secondly, after the senders and receivers get the channel address, they tell the DRs by sending extended IGMPv3[5] (or MLDv2[6], for IPv6) messages that they want Y.Chen et al. Expires October 8, 2011 [Page 3] Internet Draft Virtual Channel Any Source Multicast April.8 to send or to receive the group traffic. The routers send the JOIN/REQS messages to the shortest path interface towards s, hop- by-hop. The routers along the shortest path process the messages to create or maintain the (*,g) states, and the initial shared tree is formed. Thirdly, the group traffic is transmitted alone the shared tree and the receivers sense the real source set S={s1,s2,...,sm}. Step2: forming the source specific trees. +---+ +--+ |sr1| |r1| +---+ +--+ | | | | +--+ +--+ |R1| |R2| +--+ +--+ \ / \ / +--+ +--+ +------+ +--+ +--+ |r4|----|R3|----| R4 |----|R5|----|r2| +--+ +--+ +------+ +--+ +--+ \ / | \ | \ / | \I1 |I2 +---+ +---+ +--+ +---+ +----+ +---+ +--+ |sr3|---|R14|---|R6|--|R7-|----| R8 |----|R10|---|s1| +---+ +---+ +--+ +---+ I4+----+I3 +---+ +--+ \ / \ / \ / \I1 I3/ +--+ +---+ +---+ +--------+ +---+ |s2|---|R13|---|R12|----| R9 |----|R11| +--+ +---+ +---+ I2+--------+I4 +---+ | | | | +--+ +---+ |r3| |sr2| +--+ +---+ Figure1 The shared tree rooted at s and the source tree rooted at s1 Be aware of si in S by receiving the multicast packets, the receivers tell theirs DRs they want the traffic of channel (1<=i<=m) by sending IGMPv3 messages. The routers send the PIM-SSM JOIN messages to the shortest path interface towards si, hop-by-hop. And the source tree rooted at si is formed. Then the group traffic from si delivers to the receivers along the source tree. When the traffic alone the source tree reaches the receivers, they can optionally send IGMP or MLD message to leave channel , and the routers send extended PIM-SSM LEAVE messages to the Y.Chen et al. Expires October 8, 2011 [Page 4] Internet Draft Virtual Channel Any Source Multicast April.8 shortest path interface towards s, hop by hop, to eliminate the (*,g) on the shared tree rapidly. The routers need to run extended PIM-SSM to process JOIN/REQS/LEAVE messages. Considering the compatibility with standard PIM-SSM, a group address adopted by VC-ID-ASM must be a SSM address, and specific reserved bits need to be set to identify that it is a VC- ID-ASM address. For IPv4 network, a special range in 232.0.0.0- 232.0.0.255 can be divided out to denote VC-ID-ASM groups. For IPv6 network, a special value of the reserved 4 flag bits can be used to denote VC-ID-ASM groups. Take Fig. 1 as an example, the group senders are s1 and s2, receivers are r1,r2,r3 and r4, and senders as well as receivers are sr1,sr2 and sr3. Router i is denoted as Ri. The broken lines with arrows denote the shared tree rooted at s formed by extended PIM- SSM, and the real lines with arrows denote the source tree rooted at source s1 (the other source trees are neglected). 2.2 Initial Shared Tree Setup by Extended PIM-SSM 2.2.1 Virtual channel selection There are two methods to select a virtual channel s. The one is that we specify a static s which is in the core network to be the virtual channel. The other is that a s in the core network is choosen using a selection algorithm, such as a random core selection algorithm. 2.2.2 (*,g) state (*,g) state formed by extended PIM-SSM includes four fields <*,g,ilist,olist>, where * means it can match any source, g is a VC-ID-ASM group address, ilist is the incoming interface list, and olist is the outgoing interface list. In Fig. 1, for (*,g) of R8, ilist is {I4}, and olist is {I2}. For (*,g) of R9, the ilist is {I1,I3,I4}, and olist is {I1,I2,I4}. Also, the (*,g) states are soft states. The expirations of the interface timer and the state timer will eliminate corresponding interface in ilist or olist, or the whole state. 2.2.3 IGMP/MLD message extension and DR's processing In VC-ID-ASM, a host needs to tell its DR that it applies to send/receive group traffic or leave a group. The value of "Type" field in IGMP/MLD message can be extended to fulfill this. Take MLDv2 message for example. Its "Type" field includes 8 bits. Its value is 130,131 or 132 represents the message is a Multicast Listener Query, a Multicast Listener Report or a Multicast Listener Done message. The field value can be extended as: when its value is 133, the message is a "Multicast Sender Report" message which represents the host applies to send the group traffic. When a DR receives a extended IGMP/MLD message, it creates or maintains its (*,g) state. Diffident with standard PIM-SSM, when receiving a Multicast Sender Report message from a host, it adds the interface receiving the message to ilist of its (*,g) state; Y.Chen et al. Expires October 8, 2011 [Page 5] Internet Draft Virtual Channel Any Source Multicast April.8 when receiving a Multicast Listener Done message from a host, it removes the interface receiving the message from olist and ilist of its (*,g). Then, according the different requests from the host, the DR sends JOIN/REQS/LEAVE message towards s. When sending JOIN message, it adds the sending interface to ilist of its (*,g) state. When sending REQS message, it adds the sending interface to olist of its (*,g) state. When sending LEAVE message, it removes the sending interface from ilist and olist of its (*,g) state. 2.2.4 JOIN/REQS/LEAVE message processing by extended PIM-SSM In control plane, VC-ID-ASM uses extended PIM-SSM JOIN/REQS/LEAVE messages to create and maintain (*,g) states. The type of extended PIM-SSM message includes JOIN (for applying receiving the traffic), REQS (for applying sending the traffic) and LEAVE (for applying leaving the group). JOIN and REQS can be combined in one message, and LEAVE must be used separately. The highest 3 bits in "reversed1" field of SSM message specifies the type of the messages. In the 3 bits, the bit from the highest to the lowest represents whether or not ('1' or '0') expecting to receive the group traffic, whether or not ('1' or '0') expecting to send the group traffic and whether or not ('1' or '0') expecting to leave the group respectively. When a router r receives a JOIN/REQS/LEAVE message sent from a downstream router on interface I, it processes the message as follows. 1. If the message type is '100', '010' or '110', and r does not has (*,g) state, r generates a (*,g) state, with its ilist and olist be set {}. 2. If the message type is '1?0' (where ? represents '1' or '0'), r adds I to the olist of its (*,g) state. 3. If the message type is '?10', r adds I to the ilist of its (*,g) state. 4. If the message type is '??1', r removes I from the ilist and the olist of its (*,g) state. After that, suppose the shortest path interface from r to s is I', r processes as follows. 1. If the set of the ilist and olist without {I'} is null, indicating there is neither sender nor receiver downstream, r Y.Chen et al. Expires October 8, 2011 [Page 6] Internet Draft Virtual Channel Any Source Multicast April.8 immediately sends LEAVE message (whose type is '??1') to I', and eliminates its (*,g) state; 2. If the set of the ilist and olist without {I'} is null and r's (*,g) state is a newly generated one, r immediately sends JOIN/REQS message to I', or else, r sends JOIN/REQS message to I' when JOIN/REQS timer expires; 3. If the set of ilist without {I'} is null and the set of olist without {I'} is not null, indicating there is receiver and no sender downstream, r sends the message with type '100' and adds I' to the ilist of its (*,g) state; 4. If the set of olist without {I'} is null and the set of ilist without {I'} is not null, indicating there is sender and no receiver downstream, r sends the message with type '010' and adds I' to the olist of its (*,g) state; 5. If the set of olist without {I'} is not null and the set of ilist without {I'} is also not null, indicating there is sender and receiver downstream, r sends the message with type '110' and adds I' to the ilist and olist of its (*,g) state. 2.2.5 Switching from the Shared Tree to the Source Trees After forming the shared tree, the group traffic will reach the receivers along it. Being aware of a source address si from the multicast packet header, the receiving hosts apply to join channel using IGMPv3 or MLDv2 messages, and the routers send JOIN(si,g) messages to the shortest path interface towards si, hop by hop, to establish the source tree rooted at si. In VC-ID-ASM, the participants of ASM application can begin to apply to send or receive the group traffic at a time point t1, and should let the group traffic from all sources reaches all receivers in a time period t2 after t1. That is, at the time point t1+t2, the receivers should be aware of the source set S={s1,s2, ...,sm }. After t1+t2, the receivers will send extended IGMP or MLD message to leave channel, and then the routers send extended PIM-SSM LEAVE messages towards s to eliminate the (*,g) on the shared tree. According to above rule, after t1+t2, a new participant can not take part in the group communication. While, the switching process is initiated by the user's host; and the value of t1 and t2 can be set in the terminal programs to meet the needs of the ASM application. For example, in a video conference application, t1 is set to 9:00 a.m. and t2 is set to 30 minutes, which means the conference begin at 8:00, and after 8:30 a user can not take part in the conference. For the application that anyone can take part in Y.Chen et al. Expires October 8, 2011 [Page 7] Internet Draft Virtual Channel Any Source Multicast April.8 the whole group application process, t2 should be equal to or greater than the whole application duration. 2.2.6 VC-ID-ASM Packet Forwarding Rule When a router r receivers a VC-ID-ASM packet P, whose source address is si and destination address is g, on a interface iif, it will forward the packet according to the following rule (related functions can be found in [1], only PIM-SSM functions are considered and the assert mechanics is ignored). o-list = NULL; if ((si,g) state exists) and (RPF check succeeds) o-list= olist(si,g); else if ((*,g) state exists) and (iif is in ilist of (*,g)) {o-list = olist(*,g); o-list = o-list (-) iif}; Forwards P on each interface in o-list; Above process shows that if a router is the intersection of the shared tree and the source tree, it will firstly forward the packet along the source tree. Take R8 for example. It has (s1,g) and (*,g) state. When R8 receives a VC-ID-ASM packet, whose source address is s1 and destination address is g, on interface I3, It will firstly matches the (s1,g) state, and forwards the packet on I1 and I2, which are in the olist of the (s1,g) state. 3 Security Considerations All of the VC-ID-ASM protocol messages (Join/Prune and Hello etc.) are identical, both in format and functionality, to the respective messages used in PIM-SM. Security considerations for these messages are to be found in [1]. It is recommended that IPsec authentication be applied to all VC- ID-ASM protocol messages. The specification on how this is done is found in [1]. Specifically, the authentication of PIM-SM link- local messages, described in [1], applies to all VC-ID-ASM messages as well. The denial-of-service attack based on forged Join messages, described in [1], also applies to VC-ID-ASM. IANA Considerations This document makes no request of IANA. Normative References Y.Chen et al. Expires October 8, 2011 [Page 8] Internet Draft Virtual Channel Any Source Multicast April.8 [1] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), RFC4601, August 2006. [2] T. Bates, Y. Rekhter, R. Chandra, and D. katz, Multiprotocol Extensions for BGP-4, RFC4760. January 2007. [3] M. McBride, J. Meylor, Multicast Source Discovery Protocol (MSDP) Deployment, RFC4611, August 2006. [4] H. Holbrook, B. Cain, Source-specific multicast for IP, RFC4607, Augest 2006. [5] B Cain, S. Deering, Internet Group Management Protocol Version 3, RFC3376, October 2002. [6] R.Vida, Ed.r, Multicast Listerner Discovery Version 2(MLDV2) for IPv6, RFC3810, June 2004. Author's Address Yue Chen Zhengzhou Institute of Information Science and Technology 12 Shangcheng Road Zhengzhou 450004 P.R.China EMail: cyue2008@yahoo.com.cn Julong Lan National Digital Switching System Engneering Technological Reserch Center, P.R.China(NDSC) Lianxue Road Zhengzhou 450004 P.R.China Email: ndscljl@163.com Pengxu Tan Zhengzhou Institute of Information Science and Technology 12 Shangcheng Road Zhengzhou 450004 P.R.China EMail: tanpengxu@gmail.com Hongyong.Jia Zhengzhou Institute of Information Science and Technology 12 Shangcheng Road Zhengzhou 450004 P.R.China Y.Chen et al. Expires October 8, 2011 [Page 9] Internet Draft Virtual Channel Any Source Multicast April.8 EMail: Jiahy_pla@126.com Dourui.Yu National Digital Switching System Engneering Technological Reserch Center, P.R.China(NDSC) Lianxue Road Zhengzhou 450004 P.R.China EMail: ly_dry@126.com Y.Chen et al. Expires October 8, 2011 [Page 10]