INTERNET DRAFT Suresh Boddapati Internet Engineering Task Force Venu Hemige Document: Alcatel draft-boddapati-mpls-pim-ldp-p2mp-00.txt November 2005 Expires: May 2006 P2MP LSP Setup using PIM-SSM and LDP Status of this memo 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. IPR Disclosure Acknowledgement 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. Abstract There is emerging interest in the use of MPLS LSPs for the delivery of multicast traffic. Efficient delivery of multicast traffic using MPLS requires P2MP LSPs. This document describes a mechanism to setup P2MP LSPs using PIM-SSM and LDP. PIM-SSM is a widely deployed multicast routing protocol and has well defined procedures for signalling multicast traffic. LDP is a well defined mechanism for distribution of [Page 1]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 MPLS labels. Utilizing both PIM-SSM and LDP for setting up P2MP LSPs keeps the clear separation between signalling and label distribution, and minimizes changes to both protocols. PIM-SSM signals when to receive multicast traffic and LDP distributes label information regarding how to receive multicast traffic. 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. Table of Contents 1. Overview........................................................2 2. Label allocation and distribution mechanisms for P2MP LSPs......3 2.1. Downstream and upstream label distribution....................3 2.2. Label Distribution Control....................................4 2.3. Liberal Label Retention.......................................4 3. Procedures for setting up P2MP LSPs.............................4 3.1. Egress LSR Procedures.........................................4 3.2. Branch LSR procedures.........................................5 3.3. Ingress LSR procedures........................................6 3.4. Receiving P2MP FEC Advertisements.............................6 4. PIM-SSM-LDP interaction.........................................7 5. Detecting and Stopping Duplicate Traffic on a LAN...............8 6. P2MP FEC Element................................................8 7. An example......................................................9 8. Security Considerations........................................10 9. IANA Considerations............................................10 10. Acknowledgements..............................................10 11. Normative References..........................................10 12. Informative References........................................11 13. Authors' Addresses............................................11 14. Intellectual Property Statement...............................11 15. Full copyright statement......................................12 1. Overview Efficient delivery of multicast traffic using MPLS requires P2MP LSPs. A P2MP LSP has one Ingress LSR and one or more Egress LSRs. This document focuses on the setup of leaf-initiated P2MP LSPs. For creating such LSPs, the following options can be considered. - An existing multicast routing protocol such as PIM-SSM can be extended to also distribute labels required to set up P2MP LSPs. [Page 2]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 - An existing label distribution protocol such as LDP can be extended to also build multicast trees. [LDP-P2MP1] and[LDP- P2MP2] are proposals based on this option. - Without significant modifications to PIM-SSM and LDP, procedures can be defined for both PIM-SSM and LDP to interact with each other such that PIM-SSM builds multicast trees and LDP distributes labels to be used for forwarding labeled traffic on those multicast trees. This document proposes the use of the third option described above. The advantages of such a mechanism are: - There is considerable experience built in the development and use of PIM-SSM as a multicast routing protocol. This can be leveraged for building multicast trees for P2MP LSPs as well. This way, the changes to LDP are minimal. - The changes to PIM-SSM are also minimal. Modifying PIM-SSM to distribute labels would mean that if any other routing protocol replaces PIM-SSM, then that protocol would also have to have procedures defined for label distribution. Besides, PIM-SSM does not lend itself very well for label distribution. Specifically, upstream label allocation is not possible with PIM-SSM as it exists today, since there is no message that goes from an upstream router to a downstream router in response to a Join received from the downstream router. - PIM-SSM is equipped to deal with duplicate traffic on LANs, for scenarios where multiple upstream routers are forwarding the same traffic to the LAN. Using PIM Assert messages, PIM ensures that only one router forwards traffic to the LAN. 2. Label allocation and distribution mechanisms for P2MP LSPs 2.1. Downstream and upstream label distribution Downstream unsolicited label distribution suits well for leaf- initiated P2MP LSPs. However, in the case of LAN interfaces, where it is efficient to send only one copy of the multicast traffic, instead of ingress replicating it multiple times, an upstream label allocation scheme is more suitable. [UPSTREAM] discusses one way of assigning upstream labels, where labels come from a context specific label space. Downstream assigned labels can be allocated from the platform wide label space. This document proposes that downstream unsolicited label distribution MUST be used for point-to-point interfaces and upstream unsolicited label distribution SHOULD be used for LAN interfaces. [Page 3]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 2.2. Label Distribution Control This document also proposes the use of Independent Control for label distribution. If a network has only LAN interfaces and if Ordered Control is used, the P2MP LSP will always end up being constructed from the root. Moreover, traffic could start flowing on the P2MP LSP before the tree is completely set up, and get dropped downstream. On the other hand, if Independent Control is used, the label distribution occurs as soon as the multicast state is available. 2.3. Liberal Label Retention This document also proposes that Liberal Label Retention be used for P2MP LSPs. Liberal label retention enables faster convergence in the following cases: - When a P2MP LSP is already setup, and new branches are added to it. - When topology changes occur in the network and the path to the root of the P2MP LSP changes. 3. Procedures for setting up P2MP LSPs In order to setup P2MP LSPs, all LSRs MUST run PIM-SSM as the multicast routing protocol in the domain. All LSRs MUST also run LDP as the label distribution protocol in the domain. Each P2MP LSP is associated with an (S,G), where S is the IP address of the source of the multicast traffic which will be mapped on to the P2MP LSP. S can be the address of the Ingress LSR, a host directly connected to the Ingress LSR, or a remote host whose traffic is being mapped to a P2MP LSP at the Ingress LSR. G is the multicast group address representing the P2MP LSP. Both S and G can belong to any address family, such as Ipv4, Ipv6 etc. Note that for the purposes of this document, the PIM-SSM requirement does not mean the SSM range of multicast addresses has to be used. It simply means that there is no Rendezvous Point (RP) in the network and no (*,G) state is built. There is no restriction on the group address that can be used. The creation of a P2MP LSP is triggered at an Egress LSR when an (S,G) is added to the multicast routing table by PIM-SSM. The router can create P2MP LSPs for all (S,G)s in its multicast routing table or do it selectively based on a local policy. 3.1. Egress LSR Procedures An Egress LSR is a leaf of a P2MP LSP. On an Egress LSR, a labeled multicast packet is received and is forwarded natively (the label is popped) on one or more interfaces. [Page 4]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 When a new multicast routing table entry for an (S,G) is added (due to receiving a PIM-SSM Join from a downstream router or due to having local multicast receivers), an LSR does the following: - It creates an (S,G) multicast forwarding entry which typically consists of an incoming interface (also known as the RPF interface, the interface on which traffic is expected to arrive), and a set of outgoing interfaces. This is done using regular PIM-SSM procedures as defined in [PIM-SM]. - It allocates a P2MP FEC (see Section 6. ) for the (S,G), and using LDP advertises a label corresponding to the FEC, to each of its directly connected LDP peers. On a point-to-point interface, the label is a downstream assigned label and represents the label which the upstream router should use while sending labeled traffic for the (S,G). On a LAN interface, the label is an upstream assigned label and represents the label which this router would encapsulate the multicast packet in before sending it out on the interface. - A PIM-SSM Join is sent toward the RPF neighbor corresponding to the (S,G). The RPF neighbor is determined from the unicast routing table. If the interface on which the PIM-SSM Join is sent is a point-to-point interface, an ILM entry is also created for the FEC representing the (S,G), with incoming label set to the label that was advertised on the interface for the (S,G). If the interface on which the PIM-SSM Join is sent is a LAN interface, the ILM entry is created only if the label mapping for the FEC representing the (S,G) is already known (due to the upstream LSR having advertised it). - The label action in the ILM entry is to pop the label. Further action is determined by what the traffic sent on the P2MP LSP represents. This is outside of the scope of this document. 3.2. Branch LSR procedures A Branch LSR is an LSR in the path between an Ingress LSR and an Egress LSR. On a Branch LSR, a labeled multicast packet is received and is forwarded as a labeled packet (the label undergoes a swap operation) on one or more interfaces. The label encapsulation on one outgoing interface has no relation to the label encapsulation on another. When a PIM-SSM Join is received by a Branch LSR, if the Join creates a new multicast routing table entry, the procedures are the same as in Section 3.1 except for the ILM entry. The label action for the ILM [Page 5]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 entry is to swap the label on each of the outgoing interfaces. The outgoing interface list is as determined by PIM-SSM and the label to encapsulate on each interface is as determined by LDP. If the outgoing interface is a point-to-point, the label encapsulated is the label advertised by the downstream LSR for the FEC associated with the (S,G). If the outgoing interface is a LAN interface, the label encapsulated is the label advertised by this LSR to its downstream LSRs on the LAN for the FEC associated with the (S,G). If the PIM-SSM Join received by an LSR adds an outgoing interface to an existing (S,G), the following actions are taken. - The interface is added to the outgoing interface list of the ILM entry. - The label to be encapsulated for this outgoing interface is also programmed. The label used is as described above, based on whether the interface is a point-to-point interface or a LAN interface. 3.3. Ingress LSR procedures An ingress LSR is the root of the P2MP LSP. The ingress LSR has one or more FTN entries which map incoming multicast traffic to P2MP LSPs. How a traffic flow is mapped to a P2MP LSP is a policy decision and is outside the scope of this document. The label operation at the ingress LSR is to push a label onto the received multicast packet before forwarding it on one or more interfaces. The label pushed for one downstream interface has no relation to the label pushed for another downstream interface. When an Ingress LSR receives a PIM-SSM Join for an (S,G), if it does not have an FTN entry associated with the (S,G), the following actions are taken. - An FTN entry is created corresponding the (S,G). - The interface on which the Join was received is added to the outgoing interface list. - The label to be encapsulated for this outgoing interface is also programmed. The label used is as described in Section 3.2, based on whether the interface is a point-to-point interface or a LAN interface. When an Ingress LSR receives a PIM-SSM Join for an (S,G), and it already has an FTN entry associated with the (S,G), the first step is bypassed and the rest of the actions as described above are taken. 3.4. Receiving P2MP FEC Advertisements When an LSR receives a P2MP FEC advertisement in a Label Mapping message from a peer, if the LSR has an (S,G) state corresponding to the FEC, the following actions are taken. [Page 6]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 - If the neighbor from which the FEC was received is an RPF neighbor on a LAN interface, an ILM entry for the FEC corresponding to the (S,G) is programmed with incoming label set to the label from the received FEC. - If the neighbor from which the FEC was received is a downstream LSR that also sent a PIM-SSM Join for the (S,G) corresponding to the FEC, and the interface is a point-to- point interface, the label encapsulation for that interface in the outgoing interface list of the ILM entry is updated with the label from the FEC. 4. PIM-SSM-LDP interaction As can be seen from Section 3, the setting up of P2MP LSPs requires interaction between PIM-SSM and LDP. The interactions are as described below. - When PIM-SSM creates new (S,G), it notifies LDP of the (S,G). This causes LDP to create a FEC for the (S,G) and advertise labels to all its neighbors using Label Mapping messages. PIM- SSM also notifies LDP of the RPF neighbor for the (S,G). LDP programs the ILM entry using the incoming label for the FEC advertised to the RPF neighbor (on point-to-point interfaces) or by the RPF neighbor (on LAN interfaces). Note that on point-to-point interfaces, the label is downstream advertised while on LAN interfaces, the label is upstream advertised. - When PIM-SSM receives a Join on an interface to an (S,G), it notifies LDP of the outgoing interface. This causes LDP to program the interface in the outgoing interface list for the FEC corresponding to the (S,G) in either the FTN entry or the ILM entry (based on whether the LSR is an Ingress LSR or an Egress or Branch LSR). The label on the outgoing interface for the FEC is also programmed if available. - When PIM-SSM prunes an interface for an (S,G), it notifies LDP of the prune. This causes LDP to remove the interface from the outgoing interface list for the FEC corresponding to the (S,G) in either the FTN entry or the ILM entry. - When PIM-SSM removes an (S,G) from its database, it notifies LDP of the removal. This causes LDP to withdraw labels for the FEC associated with the (S,G) from all its neighbors using Label Withdraw messages. - When PIM-SSM detects an RPF neighbor change either due to change in the unicast routing topology or due to Assert election, PIM-SSM notifies LDP of the change in RPF neighbor. [Page 7]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 - This causes LDP to reprogram the ILM entry with the old incoming label getting replaced with a new incoming label associated with the new RPF neighbor. 5. Detecting and Stopping Duplicate Traffic on a LAN Due to ECMP, it is possible that two downstream routers on a LAN could solicit traffic for the same multicast flow from two different routers. In other words, two downstream routers could use two different RPF neighbors on the same LAN. If not detected and stopped, the LAN will always receive two copies of the traffic. PIM-SSM has well defined procedures to detect and stop duplicate traffic. In regular PIM-SSM, the detection of duplicate traffic for an (S,G) is triggered by data arrival for the (S,G) on an interface which is in the outgoing interface list. Once duplicate traffic is detected, using PIM-SSM Assert messages, PIM-SSM routers elect an Assert Winner which takes over the responsibility of being the sole forwarder of the (S,G) traffic on the LAN, thus stopping the duplicate traffic flow on the LAN. While this works fine for IP traffic, in the case of P2MP LSPs, it is not necessary that the labeled packet carry an IP packet for the same (S,G) using which the P2MP LSP was created. The P2MP LSP could be used simply as a transport and can carry any type of multicast traffic. Therefore a data driven approach cannot be used to detect duplicate traffic. [VENU-ASSERT] defines a mechanism which enables PIM-SSM routers to detect the possibility of duplicate traffic purely based on PIM-SSM Join messages. This mechanism is based on detecting PIM-SSM Joins sent for the same (S,G) to multiple upstream neighbors. As soon as this is detected, PIM Assert procedures trigger and duplicate traffic is detected and stopped even before it arrives. In order to prevent duplicate traffic from flowing to the LAN, P2MP LSPs setup using PIM-SSM MUST implement the improved Assert procedures defined in [VENU-ASSERT]. Using PIM-SSM to prevent duplicate traffic flow has the advantage of using ECMP paths efficiently. 6. P2MP FEC Element The P2MP FEC element consists of the (S,G) that is associated with the P2MP LSP. The format of the FEC is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (Encoded Source Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Page 8]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 | Group Address (Encoded Group Format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: To be assigned by IANA Reserved: SHOULD be set to zero on transmission and MUST be ignored on receipt. Source Address: The source address (S) in (S,G) associated with this P2MP FEC Element. The source address MUST be encoded using the Encoded Source Format defined in [PIM-SM]. Group Address: The multicast group address (G) in (S,G) associated with this P2MP FEC Element. The group address MUST be encoded using the Encoded Group Format defined in [PIM-SM]. The P2MP FEC element MUST be advertised in a FEC TLV without any other elements in it. The P2MP FEC element MUST be present only once in a FEC TLV. If present more than once, the FEC TLV MUST NOT be processed and an "Unknown FEC" Notification MUST be sent to the peer that advertised it. A P2MP FEC element received with an unknown address family or unknown encoding format MUST NOT be processed and an "Unknown FEC" Notification MUST be sent to the peer that advertised it. 7. An example Consider the following network. S | |if1 | I | | if2 | B / \ if3/ \if4 / \ E1 E2 I is an Ingress LSR connected to a source S on interface if1. B is a Branch LSR connected to I on interface if2. if2 is a point-to- point interface. E1 and E2 are Egress LSRs connected to B on interfaces if3 and if4 respectively. if3 is a point-to-point interface and if4 is a LAN interface. Receivers for a group G are connected to E1 and E2. [Page 9]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 Assuming that a P2MP LSP is desired from I to E1 and E2 for the flow (S,G), the LSP is setup by the following steps. - Since E1 has receivers for group G and assuming it is known that the source is S, E1 initiates a PIM-SSM Join for (S,G) towards B. - E1 also advertises a label mapping LE1 for the FEC associated with (S,G) to B, since if3 is a point-to-point interface. LE1 is a downstream allocated label which comes from platform wide label space. - B forwards the PIM-SSM Join towards I. - B advertises a downstream assigned platform wide label mapping LB for (S,G) to its upstream neighbor I and its downstream neighbor E1 since both are point to point interfaces. B also advertises a context specific upstream label mapping LBif4 to E2 on interface if4. - When I receives the (S,G) Join from B, since it is directly connected to S, it creates an FTN entry that maps (S,G) traffic to a set of P2MP NHLFEs. In this case, the set consists of outgoing interface if1 and label LB. - The P2MP LSP setup is now complete. - Now if E2 wants to join the P2MP LSP, it simply sends a PIM- SSM Join towards B. E2 will also advertise an upstream assigned label to B. Since it already has the upstream label mapping from B, it programs an ILM entry with incoming label LBif4, that was advertised by B. - When B receives the PIM-SSM Join from E2, it adds if4 to the outgoing interface list for the ILM entry corresponding to the (S,G), and the outgoing label on if4 is set to LBif4. Thus the branch of the P2MP LSP is added. 8. Security Considerations This document does not introduce any new security considerations that are not inherent to PIM and LDP. 9. IANA Considerations This document defines a new FEC Element for which the type has to be assigned by the IANA. 10. Acknowledgements The authors would like to acknowledge in no particular order, Alex Zinin, Joe Regan, Ray Qiu, Vach Kompella, Ron Haberman, Sunil Khandekar, Devendra Raut and Jayant Kotalwar for their input and valuable feedback. 11. Normative References [LDP] Andersson, L, et al. "LDP Specification", RFC 3036 [Page 10]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 12. Informative References [PIM-SM] Fenner, B, et al. "Protocol Independent Multicast - - Sparse Mode (PIM-SM): Protocol Specification", draft-ietf-pim-sm-v2-new-11.txt [P2MP-REQ] Le Roux, J-L et al. "Requirements for point-to- multipoint extensions to the Label Distribution Protocol", draft-leroux-mpls-mp-ldp-reqs-01.txt [UPSTREAM] Aggarwal, R, et al. "MPLS Upstream Label Assignment and Context Specific Label Space", draft-raggarwa-mpls-upstream-label-00.txt [LDP-P2MP1] Minei, I, et al. "Label Distribution Protocol Extensions for Point-to-Multipoint Label Switched Paths", draft-minei-mpls-ldp-p2mp-01.txt [LDP-P2MP2] Wijnands, I, et al. "Multicast Extensions for LDP", draft-wijnands-mpls-ldp-mcast-ext-00.txt [VENU-ASSERT] Hemige, V, et al. "Improved Assert in PIM", draft- hemige-pim-improved-assert-00.txt 13. Authors' Addresses Suresh Boddapati Alcatel North America 701 East Middlefield Rd. Mountain View, CA 94043 Suresh.boddapati@alcatel.com Venu Hemige Alcatel North America 701 East Middlefield Rd. Mountain View, CA 94043 Venu.hemige@alcatel.com 14. Intellectual Property Statement 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. [Page 11]
Internet Draft draft-boddapati-mpls-pim-ssm-ldp-p2mp-00.txt Nov, 2005 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. 15. Full copyright statement Copyright (C) The Internet Society (2005). 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 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. [Page 12]