IETF PIM Working Group Haibo Wen Internet-Draft Chunyan Yao Intended status: Proposed Standard Alcatel Shanghai Bell Expires: December 11, 2007 June 12, 2007 Improved Register Procedure in PIM-SM draft-wen-pim-improved-register-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 December 11, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract In [PIM-SM], Register procedure needs to be triggered by multicast packets in the data-plane/forwarding-plane. The dependences of the control-plane on the data-plane/forwarding-plane to build control- plane state does not scale well. And also the encapsulation at the Designated Router and decapsulation at the Rendezvous Point are relatively expensive operations for routers. To solve the above- mentioned problems, this document proposes new mechanisms to make a clear separation of the control-plane and the data-plane/fowarding- plane for PIM register procedure. Wen, et al. Expires December 11, 2007 [Page 1] Internet-Draft Improved Register Procedure in PIM-SM June 2007 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 RFC 2119. 1. Introduction In [PIM-SM], the Register mechanism in the control-plane is triggered by multicast data packets in the data-plane/forwarding-plane(as shown in Figure 1, here data-plane and forwarding-plane are exchangeable): +------+ +------+ +------+ +------+ |Sender| | DR | |Router| | RP | +------+ +------+ +------+ +------+ | | | |-- MC packets -->| | |in the data plane|------ Registers encapsulating --->| | MC packets | | | | | | |<---- Join ------| | |<----- Join -----| |-- MC packets -->| | | |--- MC packets ->|-- MC packets -->| | |\---------- Registers ---------->| | | | | |<--------- Register-Stop ----------| | |--- MC packets ->| | | | |-- MC packets -->| Figure 1: Register procedure in [PIM-SM] (1) The local Source (i.e., the Sender, S) directly sends multicast packets to the attached network segment. (2) When the DR(Designated Router) receives the multicast packets in the data plane, it encapsulates these packets with PIM Register messages. It will continue this operation. The PIM Register messages are unicast to the relevant RP (Rendezvous Point) of this multicast group unless the DR recently receives a Register-Stop message for that (S,G) or (*,G) from the RP. (3) When the RP receives these data-encapsulating Register messages , it decapsulates them, and forwards them onto the shared tree rooted at the RP (i.e. RPT). At the same time, when the RP receives the Register message from sender S to group G, it will initiate an (S,G) Join towards S. Normally, an (S,G) Join message is sent upstream towards S every t_periodic seconds. Wen, et al. Expires December 11, 2007 [Page 2] Internet-Draft Improved Register Procedure in PIM-SM June 2007 (4) Eventually the Join message reaches S's subnet or a router that already has (S,G) multicast tree state, and then packets from S start to flow following the (S,G) tree state (i.e., source- specific tree) towards the RP. (5) When multicast packets from S also start to arrive natively at the RP, the RP will be receiving two copies of each of these packets. At this point, the RP starts to discard the Register messages, and sends a Register-Stop message back to S's DR to prevent the DR unnecessarily encapsulating the packets. Obviously, the procedure is much complicated, because the data-plane and the control-plane are not separated clearly: multicast data packets in the data-plane trigger PIM registering process by continually encapsulating multicast data and unicast to RP (i.e., PIM Register message); native multicast packets along the source-specific shortest-path tree (SPT) in the data-plane triggers the Register-Stop message in the control-plane back to the S's DR. DR and RP need to check every multicast data packet, which is not good for fast packet forwarding. In addition, encapsulation and decapsulation are relatively expensive operations for routers; no matter whether the register procedure is successfully done, the multicast packets are encapsulated by DR towards the RP, if the register procedure fails, these Register messages containing multicast packets waste much network resources. And if the multicast packet is too big, IP fragmentation must be implemented at the DR, the DR may perform Path MTU Discovery to the RP to determine the effective MTU of the tunnel. Besides, the SPTbit and Keepalive Timer(KAT) (S,G) for group (S,G) in the router along the SPT are updated by the corresponding multicast data packets. Furthermore, there is no sender management, whether the sender has been authorized, DR will encapsulated multicast packet in the Register message to unicast to the RP, so malicious sender may use this feature to attack the network. It's sure that the dependences of the control-plane on the data-plane to build control-plane state does not scale well. Considering more and more multicast services are deploying on the network, routers with high performance are needed. However, the issues above-mentioned are not good for this trend. This document contributes on the clear separation of the control plane and the data plane for the register procedure related to the multicast sender. New mechanisms and new messages are defined to solve the issues above-mentioned. 2. New Control-Plane Register Mechanism Multicast data from the sender triggers the Register procedure at the DR in [PIM-SM]. This document divides the control plane register Wen, et al. Expires December 11, 2007 [Page 3] Internet-Draft Improved Register Procedure in PIM-SM June 2007 mechanism into two parts: the first one is sender management, providing some security to PIM-SM; the second one is register procedure to RP. And register procedure is only triggered by the message in the control-plane. 2.1 Overview The basic idea of this new control-plane registering mechanism is to clearly separate the control-plane and the data-plane. As shown in Figure 2, the sender COULD NOT send multicast packets to RP until the SPT from the DR to RP has been established (i.e., once the register procedure in control plane has been successfully done, the packets from the sender can be natively delivered to RP, then down the RPT tree); there is no encapsulation, all the registering related messages are triggered by either control messages or state changes in the control plane. +------+ +------+ +------+ +------+ |Sender| | DR | |Router| | RP | +------+ +------+ +------+ +------+ | | | |- Sender-Request ->| | | |--------- Register-Request ------->| \ | | | |process | | |<---- Join ------| |in | |<----- Join -----| |control |<----- DR-ACK -----|---- SPT-OK ---->| | |plane |--- MC packets --->| |---- SPT-OK ---->| / | |--- MC packets ->| | | | |-- MC packets -->| Figure 2: Steps for Control-plane Registering Mechanism The improved registering mechanism is detailed as follows: (1) Sender S sends Sender-Request message to the directly LAN segment (2) Only the DR router handles the Sender-Request message. The DR unicasts a Register-Request message without any packet encapsulation to the corresponding RP. The format of the new Register-Request message is defined in Section 2.3.1. In this step authentication CAN be added to sender S, if S hasn't been authorized, no Register-Request will be sent to the RP, DR-NAK message with appropriate reason code will be sent to the sender. (3) When the RP receives the Register-Request message, it will set the KeepaliveTimer to Keepalive_Period. If the RPT has been established (i.e., there are receivers under the RP), it will send (S,G) Join message to join the S's Shortest Path Tree(i.e., Wen, et al. Expires December 11, 2007 [Page 4] Internet-Draft Improved Register Procedure in PIM-SM June 2007 SPT) as [PIM-SM] does. Of course, the corresponding PIM states will be established in the routers. If there is no receiver under the RP, RP will send Register-Stop to the S's DR. (4) When the DR receives the (S,G) Join message from the RP, it sets related PIM states (e.g., SPTbit) and multicast forwarding table; it sends DR-ACK to positively notify the sender S to send multicast packets; and it also sends SPT-OK message along the SPT to RP, the corresponding PIM router will set the SPTbit and Keepalive timer. Until now, the process in the control plane has been successfully done. On the other hand, if the DR receives Register-Stop from RP, it will send DR-NAK with appropriate reason code to the sender. (5) In the data plane, multicast packets can be efficiently forwarded along the SPT to the RP, then down the RP tree. 2.2 Sender management mechanism This mechanism just provides some security to PIM-SM. Multicast sender is not allowed to send multicast packets to the LAN segment until it has been authorized to do so by the DR. Even though the sender can send multicast packets to the LAN segment, however, there is no corresponding multicast state or forwarding table on the DR, the multicast packets WILL NOT be flooded out of this segment. Unlike [PIM-SM], there is no encapsulation. The following control messages can be defined for sender management: - Sender-Request This message is sent from sender to routers. If a multicast sender wants to send non-local multicast packets to the network, it SHOULD first send Sender-Request to the network. - DR-ACK This message is sent by the DR of this LAN segment to the multicast sender. It is used to notify the sender that the sender can send multicast packets to the network now. It can indicate that corresponding multicast delivery tree has been established. - DR-NAK This message is sent by the DR to the multicast sender, which notifies the sender not to send the specified multicast packet to the network. This message may contain the reasons that why the sender is not been allowed to send the specified multicast data, for example,not passing authentication, no receiver under the RP. - Sender-Alive Wen, et al. Expires December 11, 2007 [Page 5] Internet-Draft Improved Register Procedure in PIM-SM June 2007 This message is periodically sent by the sender to notify the DR it's alive. (default value: 60 secs) - Sender-Leave This message is sent to the DR by the sender when it will not send multicast data to the specified multicast group any more. IGMP and MLD have implemented multicast group membership management for IPv4 receivers and IPv6 receivers, respectively. The implementation of sender management mechanism can be done either based on the extension to IGMP/MLD, or by defining new protocol. 2.3 Register procedure to RP 2.3.1 Sending Register-Request message from the DR The Register-Request message like the Register message, is unicast from DR to the RP. However, it SHOULD NOT be triggered by multicast packets in the data plane, but triggered by the control message (e.g. , the Sender-Request message sent from a sender, of course, here authentication to the sender can be added before triggering Register- Request message to the appropriate RP). The format of Register-Request message can be defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type Destination ----------------------------------------------------------------- 9 = Register-Request Unicast to RP PIM Version, Reserved, Checksum Described in Section 4.9 of [PIM-SM]. There is no other more field. We can also reuse the format of Register message by defining a bit in the Reserved2 field to indicate this Register- Request, but it will be more complicated. When the DR sends the Register-Request message, a Register Timer (RT) will be set to be Register_Suppression_Time. - If a Register-Stop message from the RP is received, the DR will reset the Register Timer. - If the Register Timer expires and no Join message has been received Wen, et al. Expires December 11, 2007 [Page 6] Internet-Draft Improved Register Procedure in PIM-SM June 2007 , the DR will send Register-Request message again, and the Register Timer will be reset. - If the DR hasn't received either one Join or Register-Stop message after the Register Timer has timed out for 3 times, i.e., no (S,G) Join or Register-Stop has been received within the time (3 * Register_Suppression_Time), DR claims that the RP is unreachable (e.g., send DR-NAK with the reason of RP unreachable). If RP is obtained automatically, this MAY not be needed. 2.3.2 Receiving Register-Request Messages at the RP When an RP receives a Register-Request message, the RP will take the following actions: - It will set KeepaliveTimer(S,G) to Keepalive_Period; - If JoinDesired(S,G) is TRUE, i.e., there are the corresponding multicast receivers under the RP, it will send (S,G) Join message onto the upstream interface, this Join will travel hop-by-hop to the DR or a router that already has (S,G) MC tree state. - If JoinDesired(S,G) is FALSE, i.e., there is no the corresponding multicast receiver under the RP, it will send Register-Stop message back to the S's DR (i.e., the source address of Register-Request). 2.3.3 Receiving (S,G) Join Messages at the DR When the DR with Register Timer RT(S,G) running receives (S,G) Join message, it will do the following actions: - The DR sets the corresponding states for (S,G), just as [PIM-SM] does except for the process related to encapsulation. It also set a Downstream Advertisement Timer (i.e., DAT(S,G)) for this (S,G). - The DR sends SPT-OK message along the SPT. SPT-OK message will trigger the routers along the SPT to set SPTbits and Keepalive Timers. - The DR will trigger the corresponding message of sender management to notify the sender that the multicast delivery tree has been established. Considering anycast-RP may be used, some (S,G) Join messages may reach the router that has already been on the SPT (i.e., SPTbit has been set), the router will respond with SPT-OK message too. 2.3.3.1 SPT-OK Message Wen, et al. Expires December 11, 2007 [Page 7] Internet-Draft Improved Register Procedure in PIM-SM June 2007 A SPT-OK message is used to notify the downstream routers on the SPT that the sender is alive. It is sent by routers along the SPT hop-by- hop. The router on the SPT receives SPT-OK message, it will set its SPTbit to 1 and set KeepaliveTimer(S,G) to Keepalive_Period, and it also sends SPT-OK message to all the interfaces contained in its inherited_olist(S,G). This message can be triggered by the following cases: - Expiry of the DAT(S,G) at the DR: DR maintains a Downstream Advertisement Timer for (S,G), which is set to SPTOK_Period (Default value: 90 secs). Once the timer expires, SPT-OK message will be sent along the SPT of (S,G), and it also reset the timer to SPTOK_Period. This periodic SPT-OK can also be triggered by the periodic message like Sender-Alive from the sender management protocol. - New SPT branch is grafting to the SPT: The router on the SPT (i.e., its SPTbit has been set) receives (S,G) Join message from the interface that is neither RPF'(S,G) nor the one in inherited_olist(S,G), it will send an SPT-OK message out of this interface, then down this grafting SPT branch. In another word, when a new branch is grafting to the SPT, an SPT-OK message will be sent along this grafting branch. The format of SPT-OK message is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type Destination ------------------------------------------------------------------ 10 = SPT-OK Multicast to ALL-PIM-ROUTERS PIM Version, Reserved, Checksum Described in Section 4.9 of [PIM-SM]. There is no other more field. Group Address The group address is the one in this (S,G). Format described in Section 4.9.1 of [PIM-SM]. Wen, et al. Expires December 11, 2007 [Page 8] Internet-Draft Improved Register Procedure in PIM-SM June 2007 Source Address Source address for which the corresponding (S,G) states need to be updated on the SPT. The format for this address is given in Encoded-Unicast-Address in Section 4.9.1 of [PIM-SM]. 2.4 Deletion of SPT from the S's DR When the sender will not send multicast packets any more, the DR will be notified, and the corresponding states and forwarding table along (S,G) state tree (i.e., SPT) will be cleared. On receiving the notification of the Sender's leave, the DR sends MC-Over(S,G) message along the corresponding SPT just as sending SPT-OK message along the SPT. When the router on the SPT receives this MC-Over(S,G), it will clear the SPTbit and the Keepalive Timer. 2.4.1 MC-Over(S,G) Message MC-Over(S,G) message is sent by the sender's DR along the SPT to clear the corresponding SPTbit and Keepalive Timer. The format of MC-Over(S,G) message is the same as SPT-OK message in Section 2.3.3.1, except the Type value. Message Type Destination ----------------------------------------------------------------- 11 = MC-Over Multicast to ALL-PIM-ROUTERS 2.4.2 Other consideration for deleting SPT from the network In [PIM-SM], there is no removing operation for a SPT from its root, only (S,G) Prune message from leaf router does exist to remove SPT branch. So we can take good use of the existing mechanism, if the sender will not send multicast packets to the network any more, the intermediate routers on the SPT can just forward MC-Over message from the DR down to leaf routers (no other actions will be taken on the intermediate routers), which will respond with (S,G) Prune message in upstream direction to remove the SPT of this (S,G) from the network. 3. Impact on the Switchover between SPT and RPT When the router receives SPT-OK message from RPF'(S,G), if this router has different RPF' neighbors for SPT and RPT (i.e., RPF'(S,G) !=RPF'(*,G)), and also the SPTbit has not been set, the router sets the SPTbit and Keepalive Timer; in addition, because the macro PruneDesired(S,G,rpt) has become TRUE, this router sends (S,G,rpt) Wen, et al. Expires December 11, 2007 [Page 9] Internet-Draft Improved Register Procedure in PIM-SM June 2007 Prune message towards the RP. The Prune message travels hop-by-hop, instantiating state along the path towards the RP indicating that traffic from S for G should NOT be forwarded in this direction. The prune is propagated until it reaches the RP or a router that still needs the traffic from S for other receivers. When the router receives MC-Over(S,G) message, the router with RPF'(S,G)!=RPF'(*,G) will clear the SPTbit and the Keepalive Timer, and also send (S,G,rpt) Join towards the RP due to the PruneDesired (S,G,rpt) becomes FALSE. This message travels hop-by-hop to clear the corresponding states if needed. 4. Security Considerations Security considerations provided in [PIM-SM] apply to this document as well. 5. IANA Considerations This document does not require any IANA assignments or action. 6. References 6.1 Informative References [PIM-SM] Fenner, B., et al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, March 2006. Authors' Addresses Haibo Wen Alcatel Shanghai Bell Co., Ltd. 388#, NingQiao Road, Pudong Jinqiao Shanghai 201206 P.R. China Phone: +86 (21) 5854-1240, extension. 9273 Email: Haibo.WEN@alcatel-sbell.com.cn Chunyan Yao Alcatel Shanghai Bell Co., Ltd. 388#, NingQiao Road, Pudong Jinqiao Shanghai 201206 P.R. China Phone: +86 (21) 5854-1240, extension. 7250 Email: Chunyan.YAO@alcatel-sbell.com.cn Wen, et al. Expires December 11, 2007 [Page 10] Internet-Draft Improved Register Procedure in PIM-SM June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wen, et al. Expires December 11, 2007 [Page 11]