INTERNET-DRAFT Myung-Ki Shin Expires: September 2002 Yong-Jin Kim ETRI Sang-Ha Kim ChungNam National University March 2002 Explicit Multicast Extension (Xcast+) Supporting Receiver Initiated Join Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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 obsolete by other documents at anytime. 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. Abstract Explicit Multicast (Xcast) is a newly proposed multicast scheme to support a very large number of small multicast groups. Current Xcast specification mentions its data plane only, and does not specify a control plane. Therefore, this document describes an enhanced scheme for the support of receiver initiated join in explicit multicast, named Xcast extension (Xcast+), which complements the existing Xcast. This is achieved by adding IGMPv3/MLDv2 queries at receivers' side and new registration/de- registration messages between designated routers (at sender's side and receivers' side), and then by explicitly encoding the list of address of the designated routers at receivers' side instead of receiver address. Xcast+ encoding of the destination list in IPv4 and IPv6 are the same as Xcast. Whereas Xcast can support a very large number of small multicast groups, Xcast+ can support a very large number of medium size multicast groups. Myung-Ki Shin et al. Expires September 2002 [Page 1] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 Table of Contents: 1. Introduction .............................................. 2 1.1 Terminology .............................................. 3 2. Xcast+ Overview ........................................... 4 3. Control Plane in Xcast+ ................................... 7 3.1 Sender and Receiver Considerations ....................... 8 3.2 Router Considerations .................................... 8 4. Encoding for Xcast+ ....................................... 9 5. Incremental Deployment Option (IDO) ....................... 9 6. New Registration/De-registration Messages Format ..........12 6.1 New UDP Messages for Xcast+4 .............................12 6.2 New Hop-By-Hop Option for Xcast+6 ........................13 7. Applicability Statement ...................................15 8. Security Considerations ...................................15 References ...................................................15 1. Introduction Explicit Multicast (Xcast) is a newly proposed multicast scheme to support a very large number of small multicast groups. Xcast uses explicit encoding of destination list in the data packets, instead of multicast address. The source encodes the list of destinations in the Xcast header, and then sends the packet to a router. Each router along the way parses the header, partitions the destinations based on each destination's next hop, and forwards a packet with an appropriate Xcast header to each of the next hops [1]. Current Xcast specification mentions a data plane only, and does not specify a 'control plane'. Therefore, defining multicast sessions is an application level issue[1]. There will be multiple ways in which an Xcast sender determines the addresses of the other members of the session. For example, SIP[2] and IGMP/MLD-like receiver-join model can be used. This document describes an enhanced scheme for the support of receiver initiated join in explicit multicast, named Explicit Multicast extension (Xcast+). This is achieved by adding IGMPv3/MLDv2 queries (S, G) at receivers' side and new registration/de-registration messages between designated routers (DRs) at sender's side and receivers' side in the control plane, and then by explicitly encoding the list of address of the DRs at receivers' side instead of receiver address. Xcast+ encoding of the destination list in IPv4 and IPv6 are the same as Xcast[1]. With Xcast+, there are a few extensions of Xcast. They are the use of a control plane for receiver initiated join and the use of encoded addresses of the designated routers at receivers' side in the data packets, instead of receiver addresses. These extensions to Xcast bring following benefits : Myung-Ki Shin et al. Expires September 2002 [Page 2] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 - From the viewpoint of senders and receivers, procedures in the control plane are the same to existing SSM schemes [3]. Xcast+ provides the transparency of traditional multicast schemes to senders and receivers. Therefore, Xcast+ senders and receivers do not require to use additional control to join in a session. - Similar to ALM(Application Level Multicast) and Overlay Multicast schemes, Xcast+ supports both multicast and unicast, where multicast is used within a subnet and unicast is used between routers. Therefore, intermediate routers do not have to maintain multicast states, but still exists benefits of multicasting. - There can be an increase of the number of receivers in a subnet, which means Xcast+ can support medium size number of members compared to that of existing Xcast. Whereas Xcast can support a very large number of small multicast groups, Xcast+ can support a very large number of medium size multicast groups. - When the scalability in ASM schemes is considered, one of the main issues may be a complexity of multicast tree construction between multicast routers on the Internet backbone. Because Xcast+ uses the multicast scheme in a subnet, deployment and management are easy and simple even if a multicast scheme is used. Note - Extension (plus) of Xcast+ means the support of receiver initiated IGMPv3/MLDv2 queries and the use of encoded address of the DRs at receivers' side in the data packets, instead of receiver address. 1.1. Terminology 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 RFC 2119. In addition, this document frequently uses the following terms: ASM Any-Source Multicast SSM Source-Specific Multicast Xcast Explicit Multicast Xcast+ Explicit Multicast extension Deginated router (DR) An Xcast+ capable multicast querier router. Branch router (BR) An Xcast+ capable branch router which performs partitioning the set of destinations listed in an Xcast+ packet. Myung-Ki Shin et al. Expires September 2002 [Page 3] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 Registration Request A message sent from a DR at receiver's side to a DR at sender's side in order to request the reception of Xcast+ data. Registration Reply A message sent a DR at sender's side to a DR at receiver's side in order to acknowledge the safe delivery of a Registration Request message. De-registration Request A message sent from a DR at receiver's side to a DR at sender's side in order to cease the reception of Xcast+ data. De-registration Reply A message sent a DR at sender's side to a DR at receiver's side in order to acknowledge the safe delivery of a De-registration Request message. X2M Xcast to Multicast conversion M2X Multicast to Xcast conversion X2U Xcast to Unicast conversion Standard multicast address Multicast address which is used in ASM and SSM. 2. Xcast+ Overview In Xcast+, a receiver initiates IGMPv3/MLDv2 source-specific host report (S, G), where S is a sender address and G is a standrard multicast address. When a designated router (DR) at receivers' side receives the report, it sends new Registration Request messages (S, G, DR) to the sender. These new messages format are specified in section 5. These procedures imply the addition of control plane for Xcast. Thus, when the DR at the sender's side receives the message, it can keep track of the addresses of all DRs at the receivers' side involved in the multicast session (S, G) in its cache table. When the sender sends standard multicast packets, the DR at the sender's side which receives the packets explicitly encodes the addresses of the DRs at the receivers' side in Xcast header, and sends the packets as Xcast+ packets on unicast path (M2X: Multicast to Xcast). Each router along the way parses the header partitions the destinations based on each destination's next hop and forwards the packet with an appropriate Xcast header to each of the next hops. These procedures comply with the data plane for existing Xcast, except for encoding addresses of the DRs at the receivers' side in the data packets instead of addresses of receivers. When the DRs at the receivers' side receive the Xcast+ packets, they send the packets as standard multicast packets to receivers (X2M: Xcast to Multicast). For example, suppose that B, C, D, E, F and H are trying to receive Myung-Ki Shin et al. Expires September 2002 [Page 4] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 packets distributed from A in Figure 1 below: B / R4 -- C / D / / A --- R1 --- R2 --- R3 R8 -- E \ / \ \ / F R5 --- R6 --- R7 \ \ R9 -- H Figure 1 This is accomplished as follows: B, C, D, E, F and H initiate IGMPv3/MLDv2 host report (S, G). When R4, R8 and R9 receive the reports, they send a Registration Request message to the sender. Meanwhile, when R1 intercepts and receives the message, it sends a Registration Reply message (A message acknowledging a safe delivery of the Registration Request) and does not forward this message to the sender. Therefore, R1 identifies a set of all DRs at the receivers' side dynamically . Thus, when R1 receives multicast packets (G) from A, R1, by M2X processing algorithm, it sends the packets as Xcast+ packets with the list of in its data packets to the next hop router, R2. Xcast+ encoding of the destination list in IPv4 and IPv6 are the same as Xcast [2]. Therefore, ignoring details, the packet that R1 sends to R2 looks like this [src = R1 | dest = R4 R8 R9 | payload]. When R2 receives this packet, it needs to properly process the Xcast header. The processing that a router does upon receiving one of these Xcast+ packets is exactly the same as in Xcast except for the following processing : - New X2M encoding processing : When a router receives an Xcast+ packet, if the address of destination is equal to its own address (i.e. the router is a DR at the receiver's side), the router sends the packet as a standard multicast packet to the receivers (X2M). The channel identifier[1] in Xcast header is encoded as the multicast address in IP header. X2M is performed at IGMPv3/MLD (S,G) enabled interface only of final router in on the delivery path. Myung-Ki Shin et al. Expires September 2002 [Page 5] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 - Deletion of X2U encoding processing : Unlike existing Xcast, even if there is only one destination for a particular next hop, do not send the packet as a standard unicast packet to the destination (X2U), because destination address (i.e. standard multicast address) in IP header is meaningful when X2M encoding is used. So, the whole processing algorithm that the router does on receiving an Xcast+ packet is as follows : 1) Perform a route table lookup to determine the next hop for each of the destinations listed in the packet. 2) Partition the set of destinations based on their next hops. 3) Replicate the packet so that there's one copy of the packet for each of the next hops found in the previous steps. 4) Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop. 5) Send the modified copies of the packet on to the next hops. 6) If there is only one destination in Xcast+ header and it is equal to its own address, send the packet as a standard multicast packet to the receivers (X2M). In the example above, R3 will send one copy of packet to destination R5 with Xcast+ list of and one copy of packet to destination R4 with Xcast+ list of . When R4 receives the packet, it will, by the X2M processing algorithm, send the packet as a standard multicast packet to the receivers . In addition, a router receiving a standard multicast packet needs the following processing additionally : - New M2X encoding processing : When a DR receives standard multicast packets, if there is a entry for the multicast session in the Xcast+ cache table, it sends the packets as Xcast+ packets including the addresses of DRs at the receivers' side to the next hops. The multicast address in IP header is encoded as the channel identider[1] in Xcast header. The additional processing algorithm that the router does on receiving a standard multicast packet is as follows : 1) Perform an Xcast+ cache table lookup to determine whether the multicast packet should be converted into Xcast+ packet. Myung-Ki Shin et al. Expires September 2002 [Page 6] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 2) If there is a entry for the multicast session in the cache table, the router sends the packet as a Xcast+ packet to the next hops (M2X). So, in the example above, when R1 received a multicast data from A, R1 will, by M2X processing algorithm, send the packet as a Xcast+ packet to the R2. 3. Control Plane in Xcast+ Figure 2 describes the whole control plane for Xcast+. In Xcast+, a standard multicast address is used to identify a multicast session. A sender creates and advertises a multicast session with a standard SSM address range. (232/8 for IPv4 and FF3x::/12 for IPv6). Advertisement method using web pages might be useful. +------------+ Receiver | SSM app | Xcast+ Session Discovery (by web page) --------------------------------------------------------------- |IGMPv3/MLDv2| IGMPv3/MLDv2 Host Reporting +------------+ | Source-Specific Host Report (S, G) | --------------------------------------------------------------- v +------------+ Xcast+ capable DR at Receiver's side |IGMPv3/MLDv2| IGMPv3/MLDv2 Querier --------------------------------------------------------------- | Unicast | Unicast Routing +------------+ | Registration Request (S, G, DR) ... | v +------------+ Xcast+ capable DR at sender's side | Unicast | Unicast Routing +------------+ Figure 2 Control plane for Xcast+ 3.1 Sender and Receiver Considerations In Xcast+, receivers send IGMPv3/MLDv2 host reports to their DR on the where they belong to a subnet in order to receive multicast packets. In order to achieve these works, it is necessary for receivers to know the address of the sender. Current version of IGMP/MLD, IGMPv3/MLDv2 can support source discovery and source- Myung-Ki Shin et al. Expires September 2002 [Page 7] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 specific host membership report. In addition, IGMPv3/MLDv2 leave operation is also applicable to leave a multicast session dynamically. Xcast+ provides the transparency of traditional multicast schemes to senders and receivers. That is, Xcast+ receivers don't require to use additional control to join in Xcast+ session. A receiver that is an IGMPv3/MLDv2 capable host does not need to be an Xcast+ capable host. So, this requirement for receivers can be easily achieved. As well, when a sender wants to send a multicast data, the requirements are the same as standard multicast sender. 3.2. Router Considerations In Xcast+, When a DR at receivers' side that receives the IGMPv3/MLDv2 (S,G) host report, it keeps the state of (S,G) for the report in Multicast Forwarding Information Base (MFIB) and MUST send Registration Request (S, G, DR) to the sender. It is sent to the sender directly, so the intermediate routers don't need to keep the state information of the multicast session (S, G). If the DR does not receive a Registration Reply (S, G, DR), it SHOULD resend the Registration Reply (S, G, DR). In addition, when it recognizes the expiration of the state of (S, G), it MUST send a De- registration Request to the sender. De-registration Reply SHOULD be sent, the same as Registration Request. Theses new messages will be defined in section 5. When the Registration/De-registration messages reach a DR at senders' side, the DR MUST intercept the message amd does not forward this message to the sender. This means that it can obtains the addresses of all DRs at receivers' side. It SHOULD store and update the list of the DRs per (S, G) into the Xcast+ cache table. And then, the DR at the sender's side SHOULD send a Registration Reply (S, G, DR). If the DR at the sender's receives a De- registration Request (S, G, DR), the whole processing is the same as those of Registration Request (S, G, DR) except for deleting the addresses of the requesting DR for (S, G) in the Xcast+ cache table. Of course, Xcast+ scheme is extended from Xcast, so that all of routers on the unicast path between senders and receivers MUST be an Xcast+ capable router to process and forward the Xcast+ packets. For gradual deployment, tunneling mechanisms proposed in Xcast[1] can be used. This issue is the same as existing Xcast. As well, we propose a new incremental deployment option (IDO) for Xcast+ (see section 5). 4. Encoding for Xcast+ When a sender starts to send multicast packets, a DR at sender's side fist receives the multicast packets. Next, the DR at senders' Myung-Ki Shin et al. Expires September 2002 [Page 8] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 side explicitly encodes the list of addresses of all DRs at receivers' side in the Xcast+ data packets by referencing the Xcast+ cache table. In Xcast+, encoding methods for both IPv4 and IPv6 are the same as Xcast. For IPv4, the source address field of the IPv4 header contains the address of the DR at sender's side. The destination address field carries the All-Xcast-Routers address[1] which is designed for Xcast. In addition, the multicast address carried in standard multicast packet received from a sender is encoded as channel identifier in Xcast header. The list of destinations will be encoded in a separate header. The Xcast header for IPv4 (in short Xcast4) is carried between the IPv4 header and the transport layer header. The IP header will carry the protocol number PROTO_Xcast. [ IPv4 header | Xcast4 | transport header | payload ] For IPv6, the Xcast6 header encoding is similar to IPv4, except that Xcast information is stored in IPv6 extension headers of 'Routing Extension' header and 'Destination Extension' header. The IPv6 header MUST carry the NextHeader value 'Routing Extension'. The source address field contains the address of the DR at sender's side. The method for encoding the destination address is the same as Xcast+ for IPv4. [ IPv6 header | Xcast6 | transport header | payload ] In Xcast header, Xcast bit, X MUST be set, because X2U MUST be prohibited. 5. Incremental Deployment Option (IDO) One way to deploy Xcast+ in a network that has routers that have no knowledge of Xcast+ is to setup "static tunnels" or use Semi- permeable tunneling (IPv6 only) between Xcast+ capable peer routers like Xcast[1]. In the draft, we propose a new Incremental Deployment Option (IDO) for Xcast+. This enables the creation of a virtual network for Xcast+ layered on top of an existing network and gradual deployment for Xcast+ without any static tunneling. The virtual topology consists of sets of all of branch routers (BRs). In order to create the virtual network of BRs for Xcast+, when a DR at receivers' side sends Registration/De-registration messages, the addresses of Xcast+ capable routers on the delivery path are added incrementally to the messages. So, a DR at sender's side receiving the messages can know the list of Xcast+ capable routers per (S, G). The list of BRs is calculated using the list of Xcast+ capable Myung-Ki Shin et al. Expires September 2002 [Page 9] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 routers by the graph search algorithm. The virtual topology MUST be updated periodically. So, the DR at sender's side keeps the list of the BRs as well as DRs per (S, G) into the Xcast+ cache table. In the example below, we assume X1, X3, X4, X7, X8 and X9 support Xcast+ capability (see Figure 3). B / X4 -- C / D / / A --- X1 --- R2 --- X3 X8 -- E \ / \ \ / F R5 --- R6 --- X7 \ \ X9 -- H Figure 3 When the X1 receives packets from the sender A, X1 will create the packet of Figure 4. The address of first BR will be put in the destination address field of the outer IP header. +----------+ | payload | +----------+ | UDP | +----------+ | Xcast+ | | X4,X7, | | X8,X9 | +----------+ | inner IP | | src=X1 | |dst=All_X_| |prot=Xcast| +----------+ | outer IP | | src=X1 | | dst=X3 | | prot=IP | +----------+ Figure 4 When X3 receives this packet, it processes it as follows: Myung-Ki Shin et al. Expires September 2002 [Page 10] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 1) Perform a route table lookup in the Xcast routing table to determine the Xcast+ branch hop for each of the destinations listed in the packet. 2) For those destinations an Xcast+ branch hops are found, partition the destinations based on their branch hops. 3) Replicate the packet so that there's one copy of the packet for each of the Xcast branch hops found in the previous steps. 4) Modify the list of destinations in each of the copies so that the list in the copy for a given branch hop includes just the destinations that ought to be routed through that branch hop. 5) Put the address of the branch hop in the destination address field of the outer IP header in each of the copies. 6) Send the modified copies of the packet on to the branch hops. 7) If there is no destination listed in the packet, send the packet as a standard multicast packet to the receivers (X2M). So, in the example above, X1 will send a single packet on to X3 with a destination list of < X4 X7 X8 X9 >. This packet will be received by R2 as a unicast packet with destination X3, and R2 will forward it on, having no knowledge of Xcast+. When X3 receives the packet, it will, by the algorithm above, send one copy of the packet to X4 with a destination list null and one copy of the packet to X7 with a destination list of < X8 X9 >. R2, R5, and R6 will behave as standard routers with no knowledge of Xcast+. When X7 receives the packet, it will parse the packet and transmit one copy of the packet to X8 and one copy of the packet to X9. When X8 and X9 receives the packet, they will send the packet as a standard multicast packet. 6. New Registration/De-registration Messages Format New registration/de-registration messages are implemented by four messages : Registration Request, De-registration Request, Registration Reply and De-registration Reply. Two Request messages and two Reply messages have the same format respectively, and they are classified by the T field. 6.1 New UDP Messages for Xcast+4 All these messages are carried within the data portion of a UDP, which is in turn placed within the payload portion of an IP packet. The Xcast+ module in Xcast+ routers (at least DRs) MUST identify these messages by checking Destination Port field, which must be assigned by IANA in the future. Myung-Ki Shin et al. Expires September 2002 [Page 11] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 6.1.1 Registration/De-registration Request Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|A|M|O| Reserved | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Address (S) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address (G) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router Address (DR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Option... +-+-+-+-+-+-+-+-+-+-+-+- T 0 = Registration Request 1 = De-registration Request A 1 = Acknowledgement SHOULD be sent M 1 = X+MIP Registration Update (see [5].) O 1 = IDO Sub-Option is included Sequence # 8-bit number to sequence Messages Lifetime 32-bit unsigned integer 6.1.2 Registration/De-registration Reply Messages 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |T|M|O| Reserved | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Address (S) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address (G) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router Address (DR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Option... +-+-+-+-+-+-+-+-+-+-+-+- Status 8-bit unsigned integer indicating status 0 = Registration Reply accepted 1 = De-registration Reply accepted 128 = NOT accepted T 0 = Registration Acknowledgement 1 = De-registration Acknowledgement M 1 = X+MIP Registration Acknowledgement (see [5].) Myung-Ki Shin et al. Expires September 2002 [Page 12] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 O 1 = IDO Sub-Option is included Sequence # 8-bit number to sequence Messages Lifetime 32-bit unsigned integer 6.1.3 IDO Sub-Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of BR | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Candidate Branch Router Addresses (BR) ~ | (A set of Xcast+ capable routers) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # of BR Number of candidate BR addresses 6.2 New Hop-By-Hop Option for Xcast+6 In the case of IPv6, new IPv6 Hop-by-Hop options are defined. 6.2.1 Registration/De-registration Request Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|A|M|O| Reserved | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Address (S) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address (G) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router Address (DR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Option... +-+-+-+-+-+-+-+-+-+-+-+- Option Type TBD Option Length 8-bit unsigned integer T 0 = Registration Request, 1 = Deregistration Request A 1 = Acknowledgement SHOULD be sent M 1 = X+MIP Registration Update (see [5].) O 1 = IDO Sub-Option is included Myung-Ki Shin et al. Expires September 2002 [Page 13] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 Sequence # 8-bit number to sequence Messages Lifetime 32-bit unsigned integer 6.2.2 Registration/Deregistration Reply Option 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 +-+-+-+-+-+-+-+-+ | Option Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Status |T|M|O|Reserved | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Address (S) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address (G) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router Address (DR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Option Type TBD Option Length 8-bit unsigned integer Status 8-bit unsigned integer indicating status 0 = Registration Reply accepted 1 = De-registration Reply accepted 128 = NOT accepted F 0 = Registration Acknowledgement 1 = Deregistration Acknowledgement M 1 = X+MIP Registration Acknowledgement (see [5].) O 1 = IDO Sub-Option is included Sequence # 8-bit number to sequence Messages Lifetime 32-bit unsigned integer 6.2.3 IDO Sub-Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of BR | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | Candidate Branch Router Addresses (BR) | | (A set of Xcast+ capable routers) | ~ ~ + + Myung-Ki Shin et al. Expires September 2002 [Page 14] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # of BR Number of candidate BR addresses 7. Applicability Statement Xcast+ can support a very large number of medium size multicast groups, while Xcast is suitable for a very large number of small multicast groups. Therefore, application areas are the same to Xcast, for example, conferencing, multi-player games, collaborative working, etc., in light of the number of receivers, however, Xcast+ is more scalable in a specific application areas, where there are many receivers in a subnet, such as audio/video broadcasting within an intranet or enterprise. In particular, incremental deployment option might be useful where Semi-permeable tunneling can not be applied (e.g., IPv4). 8. Security Considerations The security consideration of Xcast+ mostly relies on [4]. References [1] R. Boivie et al., Explicit Multicast (Xcast) Basic Specification, , October, 2001. [2] B. Van Doorselaer et al., SIP for the establishment of xcast-based multiparty conferences, , 2000. [3] H. Holbrook and B. Cain, Source-Specific Multicast for IP, , November 2001. [4] O. Paridaens and D. Ooms, Security Framework for Explicit Multicast, , November 2000. [5] M. Shin et al., Xcast+ over Mobile IP (X+MIP), , April 2002. Authors Addresses Myung-Ki Shin Myung-Ki Shin et al. Expires September 2002 [Page 15] INTERNET-DRAFT Xcast+ Supporting Receiver Initiated Join March 2002 ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Phone : 82 42 860 4847 Fax : 82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Yong-Jin Kim ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Phone : 82 42 860 6564 Fax : 82 42 861 5404 E-mail : yjkim@pec.etri.re.kr Sang-Ha Kim Department of Computer Science ChungNam National University 220 Gung-dong, Yuseong-gu, Daejon, 305-764, Korea. Phone : 82 42 821 6271 Fax : 82 42 822 9959 E-mail : shkim@cclab.chungnam.ac.kr Myung-Ki Shin et al. Expires September 2002 [Page 16]