Network Working Group Rahul Aggarwal Internet Draft Tom Pusateri Expiration Date: March 2004 Juniper Networks Dino Farinacci Procket Networks Liming Wei Redback Networks IP Multicast With PIM-SM Over a MPLS Traffic Engineered Core draft-raggarwa-pim-sm-mpls-te-00.txt 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 This document describes procedures for IP multicast over a MPLS Traffic Engineered (TE) core. The defined procedures apply when the Provider Edge (PE) routers are running PIM-SM to exchange multicast routing information with the Customer Edge (CE) routers. Point to multipoint (P2MP) MPLS TE LSPs are used in the network core. The procedures described make use of the PIM-SM remote neighbor extensions described in [PIM-SM-REMOTE]. draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 1] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 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 [KEYWORDS]. 1. Introduction This document describes procedures for IP multicast over a MPLS TE core. It addresses the case where MPLS TE is used in the network core and the edge PE routers are participating in multicast routing with CE routers or routers in other network domains. The following figure shows a sample topology: Multicast Source 1 (S1) (G1, G2, G3) | Spe1 | | | | R2----Rpe2--P1 P2---Rpe1--(R1) (G1) (G2, G3) | Rpe3----R3 (G2, G3) | | R4 (G1) Figure 1. A source-PE (Spe) is the PE that is receiving traffic from the multicast traffic source. The multicast traffic source may be one or more hops away. A receiver-PE (Rpe) is the PE that is delivering multicast traffic to one or more receivers. The receivers may be one or more than one hop away. In Figure 1 Spe1 is the source-PE. Rpe1, Rpe2 and Rpe3 are receiver- PEs. Spe1, Rpe1, Rpe2 and Rpe3 are the edge routers and are participating in multicast routing with S1, R1, R2, R3 and R4. S1 is the multicast source that is sending traffic for groups G1, G2 and G3. R1, R2, R3 and R4 are multicast receivers. R1 is listening to G1, R2 to G2 and G3, R3 to G2 and G3 and R4 to G1. P1 and P2 are the core routers and are participating in MPLS TE along with the edge routers. In such a scenario it may not be desirable to run PIM-SM in the network core i.e on P1 and P2 in Figure 1. This may be because: draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 2] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 a) It is desired to keep core routers free of multicast routing state. b) It is desired to have a BGP free core. BGP is needed in the core to distribute unicast routes for multicast RPF used by PIM-SM. This is no longer the case if PIM-SM is not used in the network core. Thus if the core is BGP free for unicast routing (e.g. RSVP-TE is used in the core), not running PIM-SM in the core ensures that a provider can truly have a BGP free core. c) The multicast application that the PE routers are participating in makes it necessary to use TE in the core for multicast traffic [P2MP-MPLS-TE-REQ]. d) PIM-SM control traffic may originate from outside the provider domain. In this case it may be desirable to keep the PIM-SM control traffic out of the network core. The procedures described in this document enable a provider to offer IP multicast services and at the same time have a multicast routing (i.e. PIM-SM) free core. The mechanism described depends on the presence of P2MP MPLS TE LSPs [P2MP-MPLS-TE-REQ, P2MP-RSVP-TE] in the network core. The rest of this document uses the term P2MP LSP to refer to a P2MP MPLS TE LSP. Thus in Figure 1 there may be a P2MP LSP from Spe1 with Rpe1, Rpe2, Rpe3 as the endpoints. P2MP MPLS TE technology is being developed in the MPLS WG. [P2MP-RSVP-TE] describes one mechanism for setting up P2MP LSPs. However the procedures described in this document are independent of the mechanism used for setting up the P2MP LSP. This document describes: a) Exchange of multicast routing information between the edge routers b) Discovery of the P2MP LSP endpoints by a Spe. Thus with respect to Figure 1, discovery of Rpe1, Rpe2 and Rpe3 as endpoints of a particular P2MP LSP, by Spe1. c) Association of the multicast routing state with a P2MP LSP. This pertains to associating multicast routing state that Spe1 learns from Rpe1, Rpe2 and Rpe3 with the relevant P2MP LSP. d) The forwarding state at the Spe and the Rpe to enable IP multicast over a P2MP LSP. draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 3] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 2. PIM-SM Control State Exchange Between Edge Routers As mentioned in the previous section, the network core is PIM-SM free. However the edge PE routers are running PIM-SM towards the CEs or other network domains. Thus they need to exchange PIM-SM routing information. This is accomplished by using PIM-SM remote neighbors as described in [PIM-SM-REMOTE]. The reception of a PIM-SM Join/Prune for a particular multicast source address (S) at a Rpe, is followed by resolving S onto the BGP next-hop that is advertising S. The BGP next-hop for reaching S is the Spe. The resolution of a PIM- SM Join/Prune onto a Spe results in the Rpe initiating a remote neighbor adjacency with the Spe. This is followed by the Rpe sending the PIM-SM Join/Prune to the Spe. For instance in Figure 1, if Rpe1 receives a PIM-SM Join/Prune message from R1, for S1 as the source, it has to propagate the Join to Spe1. Rpe1 learns the route to reach S1 from Spe1. Hence when it receives a PIM-SM Join for S1, it determines Spe1 as the next-hop for reaching S1. Rpe1 then establishes a remote neighbor adjacency with Spe1. It then sends the Join/Prune message to Spe1. It is to be noted that the Rpes may be running IGMP towards the receivers. In that case if the IGMP joins are source specific, the Rpe can send PIM-SM Joins as described above to the Spe. Else PIM-SM Joins have to be sent to the RP. 3. P2MP LSP Endpoint Discovery As described above [PIM-SM-REMOTE] procedures are used to propagate PIM-SM Join/Prune messages from a Rpe to the Spe. The receipt of a PIM-SM Join message from a Rpe allows the Spe to treat the Rpe as a P2MP LSP leaf. There may be various ways to associate the Join message with a particular P2MP LSP. This is discussed further in the next section. Once the Join message is associated with a P2MP LSP, Spe initiates the setup of the P2MP LSP with the Rpe as the endpoint, if the P2MP LSP doesn't already exist. If the P2MP LSP exists, but the Rpe is not one of the existing leaves, Spe adds the Rpe as a new leaf to the existing P2MP LSP. If the P2MP LSP exists and the Rpe is one of the existing leaves, Spe leaves the existing P2MP LSP unchanged. Let us consider an example with respect to Figure 1. a) R4 sends a PIM-SM Join for (S1, G1) to Rpe3. b) Rpe3 determines Spe1 as the next-hop for reaching S1. It establishes a remote neighbor adjacency with Spe1 and sends the directed Join to Spe1. draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 4] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 c) Spe1 decides to map (S1, G1) received from Rpe3 to P2MP-LSP1. As described in the next section, the exact procedures for this mapping are a matter local to Spe1. Initially, P2MP-LSP1 doesn't exist, so Spe1 initiates the setup of P2MP-LSP1 with Rpe3 as a destination. d) R1 sends a Join for (S1, G1) to Rpe1. e) Rpe1 follows [PIM-SM-REMOTE] procedures and sends the directed Join to Spe1. f) Spe1 maps (S1, G1) received from Rpe1 to P2MP-LSP1 g) Spe1 adds a new branch to P2MP-LSP1 with Rpe1 as a destination. If the Spe receives a Prune from a Rpe, it first associates the Prune with a P2MP LSP. If the Spe has no other Join state that would keep Rpe on the P2MP LSP, it can remove Rpe from the LSP. If this was the last Rpe interested in the P2MP LSP, this will result in tear down of the P2MP LSP. 4. Mapping IP Multicast Traffic to a P2MP LSP The Spe on receiving a Join message for a particular (S, G) or (*, G) associates this Join message with a particular P2MP LSP. This in turn results in creating a multicast forwarding entry for that source and group with the P2MP LSP as an outgoing interface. As a result the IP multicast traffic for that source and group can be sent to the P2MP LSP. The selection of the P2MP LSP for a particular source and group is a decision that is local to the Spe. A few potential schemes for selecting a P2MP LSP are outlined here: a) The Spe may create only one P2MP LSP for all possible Rpes. In this case each new Rpe is added as a leaf to that P2MP LSP. Clearly this has the disadvantage of sending all the multicast traffic to all the Rpes that are part of the P2MP LSP. Thus in Figure 1, Spe1 may decide to map (S1, G1), (S1, G2) and (S1, G3) from all the Rpes to the same P2MP-LSP. As a result Rpe1 will receive traffic for (S1, G2) (S1, G3) and Rpe2 for (S1, G1), even though they do not have any receivers interested in the same. b) On the other extreme the Spe may be configured to create a separate P2MP LSP for every multicast source and group. Hence a (S, G) entry is mapped to the P2MP LSP corresponding to the multicast source S and group, G. The number of P2MP LSPs in this case is equal to the number of multicast source, group combinations. This has scaling limitations. Thus in Figure 1, Spe1 may setup three P2MP LSPs. One each for (S1, G1), (S1, G2) and (S1, G3). c) The Spe may associate a set of (S, G) entries Ssg = {(S1, G1), (S2, G2)... (Sn, Gn)} with the same P2MP LSP. The exact procedures draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 5] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 for doing this are outside the scope of this document. One example is when all the Rpes that are part of the P2MP LSP have sent Join messages for all the members of Ssg. Spe1, in Figure 1, may map (S1, G1) to P2MP-LSP1 and {(S1, G2), (S1, G3)} to P2MP-LSP2. P2MP-LSP1 includes destinations Rpe1 and Rpe3. P2MP-LSP1 includes destinations Rpe2 and Rpe3. 5. RPF Interface on a Rpe A Rpe has to associate a particular P2MP LSP as the RPF interface for a given (S, G) entry that the Rpe has propagated to a Spe. This P2MP LSP must be the same as the P2MP LSP that is used by the Spe for sending IP multicast traffic for that paricular (S, G) entry. As described above the selection of a P2MP LSP for a (S, G) entry is Spe driven. This implies that a Spe has to propagate the association between a P2MP LSP and all the (S, G) entrires being mapped onto that LSP, to all the Rpes that are part of that P2MP LSP. This document introduces a new PIM-SM message, Join Acknowledge, for this purpose. It also introduces the notion of "PIM-SM Route Attributes" that can be used to associate common properties associated with the Group Sets in a Join Acknowledge message. Thus a Join Ack can be sent by the Spe to a particular Rpe and convey the P2MP LSP identifier associated with the (S, G) entries, by encoding it as a Route Attribute. Once the Rpe receives the P2MP LSP association for a particular (S, G) entry, it uses that P2MP LSP as the RPF interface for the (S, G) entry. It is to be noted that the P2MP LSP interface will be inferred based on the incoming MPLS label. Hence penultimate hop popping has to be disabled for a P2MP LSP carrying IP multicast traffic. 5.1. Route Attribute This document introduces the notion of a PIM-SM Route Attribute List. This is a list of Route Attributes that can encoded in a PIM-SM message. The intention is to associate the Group Sets in the message with a set of Route Attributes. For solving the RPF problem which is explained above, one of these Attributes can be used for mapping the Group Sets carried in the Join Acknowledge message to a particular P2MP LSP. It is envisioned that these Route Attributes can also be more generally applicable. A Route Attribute List contains a list of Route Attributes: 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 draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 6] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Attribute 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Attribute n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ List Length is the total length in bytes of all the Route Attributes in the list. A Route Attribute has a TLV style 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Attribute Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | Currently only one Route Attribute TLV is defined: "P2MP LSP Attribute", with Type = 1. The length and value are set based on the P2MP LSP Identifier as defined in [P2MP-RSVP-TE]. 5.2. Join Acknowledge This is a new PIM-SM message with Type=9. It is sent by the destination of the Join message to the source of the Join message. It carries attributes associated with the Group Sets that the destination of the Join message wishes to convey to the source of the Join message. Following is the format of the Join Acknowledge message: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Num groups | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 7] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 | Route Attribute List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address m (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hence to solve the RPF interface issue, the Spe sends a Join Acknowledge to a particular Rpe. The Join Acknowledge carries the P2MP LSP Attribute. This enables the Rpe to receive the P2MP association for the Group Sets. 6. Security Considerations Security considerations discussed in [PIM-SM] and [PIM-SM-REMOTE] apply. Other security considerations are for further study. draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 8] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 7. Acknowledgments We would like to thank Kireeti Kompella for his contribution and in particular for his suggestions on determining the RPF interface at the Rpe. We would also like to thank Ron Bonica for his input regarding the problem and the solution presented in this draft. 8. References [PIM-SM] PIM WG, B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt. [PIM-SM-REMOTE] R. Aggarwal, T. Pusateri, "PIM-SM Extensions for Supporting Remote Neighbors", draft-raggarwa-pim-sm-remote-nbr-00.txt [P2MP-RSVP-TE] R. Aggarwal et. al., "Establishing Point to Multipoint MPLS TE LSPs", draft-raggarwa-mpls-p2mp-te-00.txt [P2MP-TE-REQ] S. Yasukawa et. al., "Requirements for Point-to-Multipoint capability extension to MPLS", draft-yasukawa-mpls-p2mp-requirement-00.txt [RFC] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Tom Pusateri Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: pusateri@juniper.net Dino Farinacci Procket Networks draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 9] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 3850 North First Street San Jose, CA, 95134 Email: dino@procket.com Liming Wei Redback Networks 350 Holger Way San Jose, CA 95134 Email: lwei@redback.com IPR Notice The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 10] Internet Draft draft-raggarwa-pim-sm-mpls-te-00.txt September 2003 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-raggarwa-pim-sm-remote-nbr-00.txt [Page 11]