Network Working Group IJsbrand Wijnands Internet Draft Bob Thomas Expiration Date: September 2005 Cisco Systems, Inc. Yuji Kamite Hitoshi Fukuda NTT Communications March 2005 Multicast Extensions for LDP draft-wijnands-mpls-ldp-mcast-ext-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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Wijnands, et al. [Page 1] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 Abstract Forwarding multicast packets efficiently over an MPLS core requires Point-to-Multi-Point (P2MP) or Multi-Point-to-Multi-Point (MP2MP) LSP's between one or more Ingress routers and one or more Egress routers. For efficient forwarding core LSRs need to replicate labeled multicast packets where the branches of the P2MP/MP2MP tree diverge. This draft specifies LDP extensions that enable it to build P2MP/MP2MP LSPs in a receiver initiated manner. Table of Contents 1 Specification of Requirments ....................... 2 2 Terminology ........................................ 3 3 Introduction ....................................... 3 4 Label distribution ................................. 3 5 Label allocation ................................... 4 6 MP-T FEC element ................................... 4 7 In-band signaling using LDP ........................ 5 8 Out-of-band signaling with LDP ..................... 5 9 Building a P2MP LSP tree ........................... 6 9.1 Label mapping ...................................... 6 9.2 Label withdraw ..................................... 6 10 Building a MP2MP tree .............................. 7 11 Assigning Labels for MP2MP upstream Traffic ........ 9 12 Acknowledgments .................................... 10 13 References ......................................... 10 13.1 Normative References ............................... 10 13.2 Informational References ........................... 10 14 Authors' Addresses ................................. 11 15 Full Copyright Statement ........................... 11 16 Intellectual Property .............................. 12 1. Specification of Requirments 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. Wijnands, et al. [Page 2] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 2. Terminology P2MP - Point to Multipoint Label Switched Tree. MP2MP - Multipoint to Multipoint Label Switched Tree. MP-T - Multipoint Tree, either a P2MP or MP2MP Tree. Ingess - Router that is a sender on the MP-T. Egress - Router that is a receiver of a MP-T. Root - Router that acts as the Rendezvous point of the MP-T. 3. Introduction Multicast trees are built using Protocol Indenpendent Multicast [PIMv2]. PIM supports three different modes of operation: PIM sparse-mode, PIM bidir [BIDIR] and PIM SSM. This draft specifies extensions to LDP that enable it to build point-to-multipoint and multipoint-to-multipoint trees for MPLS packet forwarding. These P2MP and MP2MP MPLS trees are comparable to multicast PIM SSM and PIM Bidir mode trees and may be used to support multicast over MPLS LSP's. This draft does not specify procedures analogous to PIM sparse-mode multicast. PIM is a receiver driven soft state periodic protocol that builds trees to a source or rendezvous point. Its receiver driven nature allows it to scale well with dynamic multicast group membership and large receiver populations. A router forwards tree membership upstream, but does not forward any information about downstream receivers. LDP extensions in this draft support receiver driven construction of MP-T's. An advantage that the LDP extensions for multicast have over PIM extensions for signaling labels is that LDP has built-in reliability and flow control. 4. Label distribution The labels which are mapped to MP-T LSPs are distributed by LDP in Downstream Unsolicited Ordered Mode and retained using the Conservative Label Retention mode. An LSR distributes the label for an MP-T LSP to an upstream peer only if the peer is the its next hop for the root of the MP-T. Wijnands, et al. [Page 3] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 5. Label allocation Since the extensions for signaling MP-T's use downstream label allocation MP-T LSPs may share the platform wide label space with unicast LSPs. The MPLS forwarding engine is reponsible for deciding to replicate packets using information supplied by LDP. Since MP-T and unicast LSPs share the same label space there is no need for a separate LDP session for MP-T's. 6. MP-T FEC element The MP-T FEC element identifes an MP-T by means of the tree's root address, the tree type and information that is opaque to core LSRs. MP-T type FEC Element encoding: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MP-T Type(TBD)| Address Family | Address Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree Type(TBD)| Opaque Len | Opaque value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MP-T Type MP-T type FEC element, value to be assigned by IANA. Address family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the Root address field. Address Length Length of the Root address value in octets. Root Address The root address of the MP-T. Used by receiving LSR to determine the next-hop toward the MP-T root. Tree Type 1 octet that identifies the tree type ie. - P2MP LSP. Wijnands, et al. [Page 4] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 - MP2MP downstream LSP. - MP2MP upstream LSP. Opaque Len Length of the opaque value in octets. Opaque value Variable length opaque value that uniquely identifies the MP-T. The triple uniquely identifies the MP-T. LDP uses the Root Address to determine the upstream LSR toward the MP-T; the Tree Type determines the nature of LDP protocol interactions required to establish the MP-T LSP; and, the Opaque Value carries information that may be meaningful to edge LSRs. 7. In-band signaling using LDP LDP is used to build Label Switched paths through a network. The packets that traverse the LSP are not of interest to LDP. Edge LSRs may use the Opaque field of the MP-T FEC element to encode multicast stream information. Egress LSRs may encode the source and group for a multicast stream in the Opaque field. Of course, different Egress LSRs which receive the same multicast stream must use the same source/group encoding. Such an opaque value could be used to signal the Root LSR which multicast stream is to be forwared on the MP-T. Specification of such encodings is outside the scope of this draft. The multicast component that wishes to receive multicast packets over a LDP created MP-T creates the opaque FEC value. Depending on the different applications there will be different Opaque FEC encodings. Different FEC encodings are to be documented elsewhere. 8. Out-of-band signaling with LDP When an egress router wishes to receive a multicast stream over a MP-T it needs to know the identifier of that MP-T. Using in-band signaling the egress router can create the MP-T identifier (Opaque FEC) using a pre-defined algorithm, so there no need for other signaling. If the egress router is not able to use in-band signaling, for example when different multicast streams are aggregated over the same MP-T then an out-of-band form of signaling is required to learn the MP-T identifier. Such out-of-band signaling is beyond the scope of this document. Wijnands, et al. [Page 5] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 9. Building a P2MP LSP tree In order for a set of LSRs to become egress LSRs of the same P2MP or MP2MP LSP, they must encode the same "root node" and "opaque identifier" values into the FEC element of the LDP Mapping messages that they send. How they determine what the proper root node and opaque identifier values are is outside the scope of this specification. 9.1. Label mapping An LSR which is setting up a particular MP-T only sends a Label Mapping Message for a P2MP LSP to the LSR which is to be its "upstream neighbor" on that LSP. The upstream neighbor is the one which is the next hop on the best path to the root. If there are multiple paths to the root which are equally good, one is chosen. However, once a label for a given P2MP LSP has been advertised to an upstream LSR, no further label mapping messages for that LSP are sent upstream, until such time as the label has been withdrawn, released, or the LDP connection has failed. When an LSR receives a Label Mapping it determines if it already has state for this MP-T. If it does, it updates its MPLS forwarding engine to reflect the new MP-T branch. If the receiving LSR does not have state and is not the the Root LSR for the MP-T it allocates a label, sends a Label Mapping for the MP-T toward the Root LSR, and installs the binding on its chosen upstream interface. This process is repeated until a Label Mapping message for the MP-T reaches the Root LSR. If the receiving LSR is the Root, it simply informs any subscribing applicaton that the P2MP tree exists. How this is done is beyond the scope of this document. 9.2. Label withdraw When an MP-T egress LSR is no longer interested in an MP-T it withdraws its label for the MP-T by means of a Label Withdraw message using the MP-T FEC Element to identify the MP-T. The LSR receiving a Label Withdraw message for an MP-T from a peer updates its MPLS forwarding engine by removing the output information for the MP-T that corresponds to the peer and sends a Label Release message in reply. If no output information for the MP-T remains in its MPLS forwarding engine the LSR sends a Label Withdraw for the Wijnands, et al. [Page 6] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 MP-T upstream. 10. Building a MP2MP tree A MP2MP LSP is much like a P2MP LSP, is has a Root node and multiple LSP-egress routers. The big difference compared with a P2MP tree is that there will be multiple senders that can forward MPLS packets upstream in the direction of the tree root. Each LSP-egress can be a LSP-ingress router for the same tree. The root node for a P2MP tree is always the same as the LSP-ingress router. This is not the case for MP2MP trees, it can be an LSP-ingress router but can also be a P-router in the core. MPLS forwards packets based on the incoming label. The incomming label identifies the next-hop(s) to which the MPLS packet should be sent. For any MP-T tree there can be multiple next-hops. For an P2MP tree there is only one interface that receives (i.e has forwarding state for) packets belonging to the tree. For MP2MP there is some set of interfaces which have state for the tree. Packets received on any of these interfaces are replicated to each of the other members of this set. From the perspective of a given LSR, a MP2MP "tree" consists of n P2MP LSPs, where n is the number of interfaces (upstream + downstream) on the tree. Thus the forwarding state if O(number of interfaces). If you instead used one P2MP LSP for each member of the tree, your state would be O(number of members), which scales much more poorly. Root +---+ +---+ +---+ +---+ +---+ Rcv |PE1|------|P1 |-------| P | -----|P3 |----|PE2| Rcv +---+ +---+ +---+ +---+ +---+ |S0 |S1 +---+ |P2 | +---+ S2 | | S3 +---+ +---+ | | +---+ +---+ Rcv |PE3|------|P4 |------- -----|P5 |----|PE4| Rcv Src +---+ +---+ +---+ +---+ Figure 1. Wijnands, et al. [Page 7] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 Router P4 sends a label mapping to P2 and tells P2 to use label L2 for downstream traffic. Router P5 does the same and makes P2 assigned L3 for downstream traffic. If we look at P2 the downstream state is as follows. Incoming Outgoing ---------------------------- | L1, S1 | L2, S2 | | | L3, S3 | ---------------------------- Table 1. Based on the label mapping send from P4 router P2 will send a label mapping reply to P4 with a label that is required for upstream traffic to P2. Same will happen for the upstream state from P5. Router P2 tells router P5 to use label L5 for upstream traffic. From P2 to the root of the tree (P) the same protocol operations occur. We send a label mapping including a downstream label L1 (see table 1) and we receive an upstream label L6 mapping back for the upstream state. The upstream label we received in the label mapping reply is shared between the 2 upstream states since they both need to go to the same root via the same path, so we merge them together. Router P2 has the following upstream states: Incoming Outgoing ---------------------------- | L4, S2 | L6, S1 | ---------------------------- Table 2. Incoming Outgoing ---------------------------- | L5, S3 | L6, S1 | ---------------------------- Table 3. The P (root) router will have the following upstream state. Incoming Outgoing ---------------------------- | L6, S0 | | ---------------------------- Table 4. Wijnands, et al. [Page 8] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 The upstream state has been setup and packets can travel to the root of the tree. However, while forwarding on a MP2MP tree we want to send packets down the tree on intermediate nodes while packets travel upstream. That means packets received from PE3 and PE4 need to be sent to P5 via P2. We don't need to depend on the root to send the packets downstream. We do this by merging the downstream state and the upstream states. Each upstream state will copy the interfaces from the downstream state replication list, except if it's the same as its incoming interface. So the upstream state's on router P2 look like this: Incoming Outgoing ---------------------------- | L4, S2 | L6, S1 | | | L3, S3 | ---------------------------- Table 5. Incoming Outgoing ---------------------------- | L5, S3 | L6, S1 | | | L2, S2 | ---------------------------- Table 6. Using the technique of creating specific upstream states in combination with merging the downstream replication list we are able to build a full feature MP2MP LSP tree. The LSP tree does contain more then one LSP path which costs extra labels, but the advantage is that the forwarding logic does not need to deal with any specific forwarding exceptions like we have in PIM bidir trees (forwarding packet that are received on an Outgoing Interface List). 11. Assigning Labels for MP2MP upstream Traffic To support MP2MP (bidirectional tree) LSP's we need to setup both a downstream and a upstream LSP. The downstream path has the same protocol operation as is used for P2MP LSP's, the upstream path is different. The upstream path is setup in response to the downstream path that is build. For a label mapping we sent to an upstream router, the upstream router sends a label mapping in the opposite direction to assign us a label for upstream traffic for this MP2MP FEC. The label mapping for the upstream path has the same encoding as the downstream path. To be able to distinguish between the two we use the Wijnands, et al. [Page 9] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 Tree type encoded in the MP-T FEC. If an LSR receives a label mapping of the type "upstream LSP" then this router will respond with a label mapping of type "downstream LSP". When the downstream router receives this label mapping it knows what this labbel mapping is for the upstream path. 12. Acknowledgments The authors would like to thank Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert and George Swallow for their contribution. 13. References 13.1. Normative References [MPLS] "Multiprotocol Label Switching Architecture", Rosen, E., Viswanathan, A. and R. Callon, RFC 3031, January 2001. [BIDIR] "Bi-directional Protocol Independent Multicast", Handley, Kouvelas, Speakman, Vicisano, June 2002, [PIMv2] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", Fenner, Handley, Holbrook, Kouvelas, December 2002, draft-ietf-pim- sm-v2-new-06.txt. [LDP] "LDP Specification", Andersson, Doolan, Feldman, Fredette, Thomas, January 2001, rfc3036. 13.2. Informational References [MPLS-PIM] "Using PIM to Distribute MPLS Labels for Multicast Routes", Farinacci, Rekhter, Rosen, Qian, November 2000, [RFC2547bis] "BGP/MPLS VPNs", Rosen, et. al., November 2002, draft- ietf-ppvpn-rfc2547bis-03.txt Wijnands, et al. [Page 10] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 14. Authors' Addresses IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium E-mail: ice@cisco.com Bob Thomas Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA, 01719 E-mail: rhthomas@cisco.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan Email: y.kamite@ntt.com Hitoshi Fukuda NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019, Japan Email: hitoshi.fukuda@ntt.com 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." Wijnands, et al. [Page 11] Internet Draft draft-wijnands-mpls-ldp-mcast-ext-00.txt March 2005 16. 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. Wijnands, et al. [Page 12]