Internet Draft C. Jelger T. Noel Document: draft-jelger-mssmsv6-00.txt LSIIT - ULP Expires: July 2002 January 2002 Supporting Mobile SSM Sources for IPv6 (MSSMSv6) 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 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. Abstract Mobile IPv6 describes how a Mobile Node can change its point of attachment to the Internet. While MIPv6 focuses on unicast communications, it also proposes two basic mechanisms, known as bidirectionnal tunneling and remote subscription, to handle multicast communications with mobile members. In the mean time, the deployment of Source-Specific Multicast (SSM) is of great consideration, using the PIM-SM and MLDv2 protocols. In the particular case of mobile IPv6 SSM sources, the mechanism proposed in MIPv6 to support multicast communications introduces a number of problems that need to be addressed. First, in most scenarios the MIPv6 solution leads to suboptimal routing. Second, it introduces a central point of failure (i.e. the HA) that is not to be neglected as the proposed solution also induces a great traffic concentration around this central point. Third, the processing task of the central point increases with the number of mobile sources it serves, thus reducing the efficiency of multicast delivery. The intend of this document is to describe protocol enhancements that can be used to solve the problems described above, thereby making Mobile IPv6 better equiped to support mobile SSM sources. Jelger, Noel [Page 1] Internet Draft MSSMSv6 January 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 1.1 Terminology....................................................3 1.2 Standards Language.............................................4 2. Protocol Description............................................4 2.1 MIPv6 solution.................................................4 2.1.1 Advantages and drawbacks.....................................5 2.1.2 Session and channel announcements............................5 2.2 MSSMSv6 mode of operation......................................5 2.2.1 Source handover..............................................6 2.2.2 SSM-Source Handover Notification sub-option..................7 2.2.3 Tunnel Management............................................8 2.2.4 Session and channel announcements............................8 2.3 Operation with HMIPv6..........................................8 2.3.1 Source handover within a MAP's domain........................9 2.3.2 Source handover between different Mobility Anchor Points.....9 2.3.3 Session and channel announcements............................9 2.4 Interaction with FMIPv6........................................9 3. Implementation requirements....................................10 3.1 PIM-SSM.......................................................10 3.2 MN operations.................................................10 3.3 Correspondant Nodes operations................................10 4. Security Considerations........................................10 5. References.....................................................10 6. Authors' Addresses.............................................11 Jelger, Noel [Page 2] Internet Draft MSSMSv6 January 2002 1. Introduction Mobile IPv6 [MIPv6] describes how a Mobile Node can change its point of attachment to the Internet. While MIPv6 focuses on unicast communications, it also proposes two basic mechanisms, known as bidirectionnal tunneling and remote subscription, to handle multicast communications with mobile members. In the mean time, the deployment of Source-Specific Multicast (SSM) is of great consideration, using the PIM-SM and MLDv2 protocols. In the particular case of mobile IPv6 SSM sources, the mechanism proposed in MIPv6 to support multicast communications introduces a number of problems that need to be addressed. First, in most scenarios the MIPv6 solution leads to suboptimal routing. Second, it introduces a central point of failure (i.e. the HA) that is not to be neglected as the proposed solution also induces a great traffic concentration around this central point. Third, the processing task of the central point increases with the number of mobile sources it serves, thus reducing the efficiency of multicast delivery. The intend of this document is to describe protocol enhancements that can be used to solve the problems described above, thereby making Mobile IPv6 better equiped to support mobile SSM sources. 1.1 Terminology This memo uses some of the the terminology described in [FMIPv6]. Moreover, this document introduces new definitions for certain terms used in this memo. MN - A Mobile Node is a Mobile IPv6 host capable of moving its point of attachment to the Internet. AR - An Access Router is the last router between the network and the mobile node, i.e., the MN has link layer connectivity to the Access Router. CN - Correspondant Nodes. A peer node with which a mobile node is communicating. The correspondant node may be either mobile or stationary. oAR - old Access Router, the AR involved in handling a MN's traffic prior to an L2 handover. nAR - new Access Router, the AR anticipated to be handling a MN's traffic after completion of an L2 handover. cCoA - Current Care of Address, the Care of Address to which the HA and the Correspondant Nodes forward the data destined to the MN. oCoA - old Care of Address, the Care of Address prior to the MN's handover. Jelger, Noel [Page 3] Internet Draft MSSMSv6 January 2002 nCoA - new Care of Address, the Care of Address in the new subnet. BU - Binding Update. Message sent by a MN to notify its HA or CN about its new CoA. SSM channel - Similar to the definition in [PIM-SSM]. A channel (S,G) identifies the multicast delivery tree associated with a source address S and a SSM destination address G. SSM session - A session (S',G') identifies a SSM communication associated with a source address S' and a SSM destination address G'. In the case of a mobile SSM source, the session may be different than the channel used for multicast delivery. 1.2 Standards Language 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. 2. Protocol Description This section first introduces the solution proposed in MIPv6 to support multicast communications and indirectly mobile SSM sources. The advantages and drawbacks of this solution are described and discussed. Next, the protocol enhancements proposed by the authors are fully described and the resulting mode of operation is explained and compared with the MIPv6 solution. 2.1 MIPv6 solution MIPv6 proposes two simple mechanisms to handle multicast communications with mobile nodes, namely bi-directional tunneling and remote subscription. Actually, bi-directional tunneling is the only solution directly applicable to mobile SSM sources. While not explicitly stated in the current MIPv6 draft, this mechanism can be extended to support mobile SSM sources. With this solution, a mobile SSM source MUST announce its SSM session(s) (the mechanism used to announce the session is not considered in this document) with its home address (H@), and the SSM channel is therefore identified by the mobile node's home address (h@) and by a SSM destination IP address (G). Therefore, the receivers join the channel (H@,G) as it is done when the mobile node is located in its home network. The multicast delivery tree that is created is also identified by the channel (H@,G) and it is rooted at the MN's home network. While away from its home network, the mobile source encapsulates the datagrams destined for this channel to its home agent (HA). The source address of the outer header is the current Care-of-Address (cCoA) of the mobile node (MN), and the destination address is the address of the Jelger, Noel [Page 4] Internet Draft MSSMSv6 January 2002 HA. Because receivers join the channel (H@,G), the source address of the inner header is the MN's home address (H@), and the destination address is the SSM address G. When the HA receives the encapsulated packet, it removes the first header and sends the resulting native multicast datagram onto the (H@,G) SSM delivery tree. The HA MUST not forward the inner multicast datagram if the packets are not received from an address for which the HA has a valid binding. Unicast datagrams sent by the receivers to the source (e.g. RTP/RTCP datagrams) are sent to the MN's home address and delivered to the MN's cCoA by using the classical mechanims defined in MIPv6. 2.1.1 Advantages and drawbacks There two main advantages with the MIPv6 current proposal. First, the SSM delivery tree is rooted at the MN's home address and it is therefore not affected by the MN's movements. Second, the MN's current location is hidden from the multicast receivers, which may be a desired feature for a MN that wants to hide its location. However, this solution has a number of drawbacks. First, suboptimal routing via the HA is introduced. Second, it introduces a central point of failure (i.e. the HA) that is not to be neglected as the proposed solution also induces a great traffic concentration around this central point, especially if there are more than one SSM tree rooted at the HA (i.e. different mobile SSM sources with the same HA). A failure of the HA would cause multiple multicast delivery disruptions. Third, the processing task of the HA increases with the number of mobile sources it serves, thus reducing the efficiency of the multicast delivery and increasing the probability of a failure. 2.1.2 Session and channel announcements The mechanism used to announce SSM sessions is not considered in this document. With the basic MIPv6 solution to support mobile SSM sources, the channel to be announced MUST be (H@,G). In this case, the session is also identified by the pair (H@,G). 2.2 MSSMSv6 mode of operation This section describes mechanisms and extensions to MIPv6 to allow the support of mobile SSM sources with delivery trees rooted at the current position of the source. The advantages and drawbacks of this solution will be described later in this document. In this proposal, a mobile SSM source MUST announce its SSM channel(s) with its current Care-of-Address. The SSM channel is thus identified by the mobile node's current Care-of-Address (cCoA) and by a SSM destination IP address (G). Therefore, the receivers join the channel (cCoA,G) and the multicast delivery tree that is created Jelger, Noel [Page 5] Internet Draft MSSMSv6 January 2002 is also identified by the channel (cCoA,G) and it is rooted at the network hosting the MN. To ensure consistency at higher layers (i.e. transport), the announcement MUST also indicate the home address (H@) of the source to notify applications about the home address of the mobile source. The pair (H@,G) MUST subsequently be used to identify the session, as it is not dependent to the cCoA of the mobile source. In contrast, the delivery tree is identified by the channel (cCoA,G). Therefore, the source address of the multicast datagrams sent by the source MUST be the current Care-of-Address of the MN to ensure correct processing by the routers on the tree. These datagrams MUST also contain an IPv6 Home Address Option, set to the MN's home address (H@), as it is used by the receivers' higher layers to identify the SSM session. 2.2.1 Source handover When a mobile SSM source moves into a new subnet, it must inform the multicast receivers about its new Care_of-Address (nCoA). Receivers will subsequently join the new multicast delivery tree (nCoA,G). If the nCoA is known prior to the handover, by using a protocol such as Fast Handovers for Mobile IPv6 [FMIPv6], the MN can send a Binding Update (BU) message onto the (oCoA,G) delivery tree to inform the receivers about the nCoA. A new BU sub-option is therefore required and its format is described in section 2.2.2. This new sub-option is called "SSM-Source Handover Notification". The sub-option MAY also contains the SSM destination address, which can be different than the previous address. However, for simplification, it is RECOMMENDED that the SSM destination address remains identical. If the nCoA is known after completion of the handover (i.e. when the MN is in the new subnet), the BU message must be encapsulated towards the old Access Router (oAR), which will remove the outer header and then send the multicast datagram onto the old channel (oCoA,G). Whether the nCoA is known prior to the handover or not, the source address in the header of the multicast datagram that contains the BU MUST be oCoA. If the multicast datagram that contains the BU is sent after the handover completes (i.e. encapsulated in a unicast packet sent to the oAR), the source address in the header of the unicast packet MUST be nCoA. Upon reception of the BU with the "SSM-Source Handover Notification" sub-option set to nCoA, a receiver SHOULD initiate a join operation towards the new channel (nCoA,G). The receiver MUST NOT initiate the pruning of the old channel (oCoA,G) before it starts receiving datagrams on the (nCoA,G) channel. When the receiver starts receiving datagrams on the new channel (nCoA,G), it SHOULD initiate the pruning of the old channel (oCoA,G). If a receiver is unable to join the new channel (nCoA,G), it SHOULD maintain its subscription to the old channel (oCoA,G). Upon reception of a new BU containing a "SSM-Source Handover Notification" sub-option, a receiver SHOULD try to join the new delivery channel. Jelger, Noel [Page 6] Internet Draft MSSMSv6 January 2002 After a handover, the MN SHOULD continue to send datagrams onto the old channel (oCoA,G) until it is notified by the oAR that there are no receivers listening to the old channel (oCoA,G) any more. This notification could be done via the Multicast Source Notification of Interest Protocol (MSNIP) but it is out of the scope of this document. When the MN is in the new subnet, it MUST encapsulate the multicast datagrams to the oAR, for further delivery onto the old channel (oCoA,G). The source address in the header of the multicast datagram MUST be oCoA. The source address of the unicast packet MUST be nCoA. Once in the new subnet, the MN MUST also send the multicast datagrams in native multicast onto the new channel (nCoA,G). The source address of the native multicast datagrams MUST be nCoA. Because there might be receivers on the oAR's local link, the oAR SHOULD forward the multicast datagrams sent by the MN from the new subnet onto its local interfaces (e.g. interfaces binded with the MLD entity of the oAR). The MN SHOULD also update the channel and session annoucements with the appropriate new values. 2.2.2 SSM-Source Handover Notification sub-option A new binding update sub-option called "SSM-Source Handover Notification" is defined. It is used by a MN to notify multicast receivers about the new SSM channel associated with the MN after a handover. The field "new source address (nSA)" contains the new address to be used by receivers to join the new multicast delivery tree, i.e. the channel (nSA,G). The BU can contain an OPTIONAL field of length 16 bytes containing the new SSM destination address (G) to be used to join the new channel. If present, the length of the sub- option MUST be set to 32. The sub-option type/identifier is to be attributed (TBA). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + New source address (nSA) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional field ... + Jelger, Noel [Page 7] Internet Draft MSSMSv6 January 2002 2.2.3 Tunnel Management After a handover, the MN SHOULD continue to send datagrams onto the old channel (oCoA,G) until it is notified by the oAR that there are no receivers listening to the old channel (oCoA,G) any more. The tunnel used to forward datagarams onto the old channel is set up between the MN and the oAR. This notification could be done via the Multicast Source Notification of Interest Protocol (MSNIP) but it is out of the scope of this document. However, the MSNIP message sent by the oAR to inform the MN that the tunnel is not needed any more SHOULD be acknowledged by the MN. Moreover, the MN SHOULD periodically probe the oAR to be informed about the presence of receivers on the old channel. 2.2.4 Session and channel announcements The mechanism used to announce SSM sessions is not considered in this document. The SSM channel to be announced MUST be (cCoA,G). The home address (H@) of the source MUST also be announced as it is used by the receivers higher layers to identify the SSM session. The pair (cCoA,G) identifies the channel to be joined (i.e. the multicast delivery tree), and the pair (H@,G) is used to identify the session. 2.3 Operation with HMIPv6 Hierarchical MIPv6 mobility management [HMIPv6] is an extension to MIPV6. It introduces a new node called the Mobility Anchor Point (MAP) to limit the amount of MIPv6 signalling outside the administrative local domain that the MAP belongs to. In this section, the reader is expected to be familiar with HMIPv6. With HMIPv6, the mode of operation of MSSMSv6 is very similar to the operation described in section 2.1. With this solution, a mobile SSM source MUST announce its SSM session(s) (the mechanism used to announce the session is not considered in this document) with its Regional Care-of-Address (RCoA), and the SSM channel is therefore identified by the mobile node's RCoA and by a SSM destination IP address (G). Therefore, receivers join the channel (RCoA,G) as it is done when the mobile node is located in its home network. The multicast delivery tree is rooted at the MAP. The mobile source encapsulates the datagrams destined for this channel to the MAP. The source address of the outer header is the Local Care-of-Address (LCoA) of the mobile node (MN) in the MAP domain, and the destination address is the address of the MAP. Because receivers join the channel (RCoA,G), the source address of the inner multicast datagram MUST be RCoA, and the destination address MUST be the SSM address G. When the MAP receives the encapsulated packet, it removes the first header and sends the resulting native multicast datagram onto the (RCoA,G) SSM delivery tree. The MAP MUST not forward the Jelger, Noel [Page 8] Internet Draft MSSMSv6 January 2002 inner multicast datagram if the packets are not received from an address for which the MAP has a valid binding. Unicast datagrams sent by the receivers to the source (e.g. RTP/RTCP datagrams) are sent to the MN's RCoA, and delivered to the MN's LCoA by using the classical mechanims defined in HMIPv6. The MN SHOULD also update the channel and session annoucements with the appropriate new values. 2.3.1 Source handover within a MAP's domain When a mobile SSM source performs a handover within the domain of its current MAP, no specific mechanism is required to update the multicast delivery channel and session. The SSM channel (RCoA,G) and session (H@,G) both remain identical. The MN SHOULD use its new Local Care-of-Address (nLCoA) as the source address of the packets used to encapsulate the multicast datagrams to the MAP. 2.3.2 Source handover between different Mobility Anchor Points When a mobile SSM source registers with a new MAP after a handover, a method similar to the operation described in section 2.2.1 is used to notify the receivers about the new SSM channel. The new channel to be notified is (nRCoA,G). Datagrams sent to the old channel are encapsulated to the old MAP for further delivery onto the old multicast tree (oRCoA,G). 2.3.3 Session and channel announcements With HMIPv6, the SSM channel to be announced MUST be (RCoA,G). The home address (H@) of the source MUST also be announced as it is used by the receivers higher layers to identify the SSM session. The pair (RCoA,G) identifies the channel to be joined (i.e. the multicast delivery tree), and the pair (H@,G) is used to identify the session. 2.4 Interaction with FMIPv6 The proposed protocol MSSMSv6 is fully compatible with FMIPv6. If FMIPv6 can be used by a MN to acquire a new valid care-of-address prior to the handover, this information can be used by the MN to inform receivers about the new SSM channel to be used shortly. Receivers can therefore anticipate the move and join the new delivery tree prior to the MN handover. Jelger, Noel [Page 9] Internet Draft MSSMSv6 January 2002 3. Implementation requirements The proposed protocol requires a number of minor modifications to the MIPv6 operation. It is worth mentioning that these modifications do not affect the operation of any other mechanisms used in MIPv6. 3.1 PIM-SSM No specific modification to PIM-SSM is required. The current mode of operation of PIM-SSM is unchanged. 3.2 MN operations After a handover, and because the tunnel used to forward data onto the old channel is set up between the MN and the oAR, the MN MUST send to the oAR a copy of the multicast datagrams sent to the new channel (nCoA,G). Moreover, the MN MUST send a BU containing a "SSM- Source Handover Notification" sub-option to each of its SSM multicast channels. These two requirements slightly modify the MN mode of operation. 3.3 Correspondant Nodes operations Upon reception of a BU containing a "SSM-Source Handover Notification" sub-option, a specific mechanism MUST be used to trigger the join operation to the new SSM channel. When the CN starts to receive datagrams onto the new channel, the old associated SSM channel is not further required and SHOULD be pruned. 4. Security Considerations The proposed protocol MSSMSv6 does not introduce new security problems that those already present in MIPv6 and PIM-SSM. 5. References [FMIPv6] G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, K. El- Malki, and M. Khalil, "Fast Handovers for Mobile IPv6" (work in progress), draft-ietf-mobileip-fast-mipv6- 04.txt, Nov. 2001. [HMIPv6] H. Soliman, C. Castelluccia, K. El-Malki, and L. Bellier, "Hierarchical MIPv6 mobility management (HMIPv6)" (work in progress), draft-ietf-mobileip- hmipv6-05.txt, July 2001. Jelger, Noel [Page 10] Internet Draft MSSMSv6 January 2002 [MIPv6] D. Johnson, and C. Perkins, "Mobility Support in IPv6" (work in progress), draft-ietf-mobileip-ipv6-15.txt, July 2001. [PIM-SSM] S. Bhattacharyya, C. Diot, L. Giuliano, R. Rockell, J. Meylor, D. Meyer, G. Shepherd, and B. Haberman, " An Overview of Source-Specific Multicast(SSM) Deployment" (work in progress), draft-ietf-ssm-overview-02.txt, Dec. 2001. 6. Authors' Addresses Questions, comments and suggestions about this memo can be directed to: Christophe Jelger LSIIT Louis Pasteur University Pole API, Boulevard Sebastien Brant 67400 Illkirch France Email: jelger@dpt-info.u-strasbg.fr Phone: +33 (0)3 90 24 45 90 Fax: +33 (0)3 90 24 44 55 Thomas Noel LSIIT Louis Pasteur University Pole API, Boulevard Sebastien Brant 67400 Illkirch France Email: noel@dpt-info.u-strasbg.fr Phone: +33 (0)3 90 24 45 92 Fax: +33 (0)3 90 24 44 55 Jelger, Noel [Page 11]