INTERNET-DRAFT B. Tao, Ed. Intended Status: Standards Track Huawei Technologies Inc. Expires: September 13, 2013 Others March 12, 2013 MPLS PIM Inter-working draft-tao-mpls-pim-interworking-01 Abstract This document describes a framework for the inter-working between Protocol Independent Multicast [PIM] and a leaf-driven P2MP tunnel signaling protocol so that multiple PIM sites around an MPLS network can form a single PIM domain without compromising PIM's features, scalability, and performance. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal B. Tao et al. Expires September 13, 2013 [Page 1] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Purpose of This Work . . . . . . . . . . . . . . . . . . . 5 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 2. An Overview: PIM MPLS Inter-working . . . . . . . . . . . . . 6 2.1 PIM-SM, PIM-SSM and PIM-BiDir States . . . . . . . . . . . . 6 2.2 PIM-MPLS Border Router(mPMBR) . . . . . . . . . . . . . . . 7 2.3 A Reference Model for PIM-MPLS Inter-working(PMIW) . . . . . 8 2.3.1 QPI, MPLS Tunnel and M-Flow Spec Binding . . . . . . . 10 2.3.2 PIM Support for QPI and M-Flow Spec Binding . . . . . . 10 2.3.3 M-Flow Spec Binding Policies . . . . . . . . . . . . . . 11 2.3.4 IP Multicast Packet Forwarding at an mPMBR . . . . . . . 11 2.4 Impacted PIM messages and procedures . . . . . . . . . . . . 11 2.4.1 PIM Hello and Adjacency Over MPLS Backbone . . . . . . . 11 2.4.2 PIM Assert and Message . . . . . . . . . . . . . . . . . 12 2.4.3 PIM hop-by-hop Bootstrapping and Message . . . . . . . . 12 2.4.4 PIM Unicast Messages and C-RP Advertisement . . . . . . 12 2.4.5 PIM RP Register and RegisterStop . . . . . . . . . . . . 13 2.4.6 PIM Join/Prune States and In-Band Signaling in MPLS . . 13 2.4.6.4 Aggregating Two Tunnels to Use A Single Tunnel . . . 13 3 Algorithms and Procedures . . . . . . . . . . . . . . . . . . . 14 3.1 Dynamic P2MP Tunnel Creation and Bind An M-Flow Spec To It . 14 3.1.1. In-Band Tunnel Signaling at Leaf LER . . . . . . . . . 16 3.1.2. In-Band Tunnel Signaling at Transit LSR . . . . . . . . 17 3.1.3. In-Band Tunnel Signaling at Root LER . . . . . . . . . 18 3.1.4. Considerations for Load Balance and Traffic Engineering(TE) . . . . . . . . . . . . . . . . . . . . 18 3.2. Operational Procedures for PIM RPT to SPT switch . . . . . 18 4. M-Flow Spec Format . . . . . . . . . . . . . . . . . . . . . . 19 5 OAM&P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1 Normative References . . . . . . . . . . . . . . . . . . . 23 8.2 Informative References . . . . . . . . . . . . . . . . . . 23 B. Tao et al. Expires September 13, 2013 [Page 2] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 24 B. Tao et al. Expires September 13, 2013 [Page 3] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 1 Introduction 1.1 Background IP multicast sources and their receivers can be located at multiple separated sites which are around an MPLS network. PIM, the most popular IP multicast protocol, runs in each of these sites. A requirement therefore is to use the MPLS tunnels to "connect" these multiple PIM sites as if they were in a single PIM domain. Currently there are a few standards to achieve this, most of them for multicast VPN(mVPN) cases: a) [RFC6513] and [RFC6514] use a third protocol, the extended BGP, to discover multicast routes and other states from each PIM site, propagate to other sites, and establish P2MP tunnels in the MPLS backbone to support VPN multicast within MPLS backbone. b) [I-D.lin-mrsvp-te-mvpn] uses an mRSVP-TE [mRSVP-TE] tunnel within MPLS to transparently multicast both PIM's control and data traffic to other VPN sites, and if necessary, establishes a separated P2MP tunnel for each individual multicast flow. This is an out-of-band method to signal VPN PIM states over MPLS backbone. In this way, separated PIM sites of a VPN form a single PIM domain in the VPN, and PIM adjacencies each pair of MPLS edge routers are maintained across the MPLS backbone. c) [I-D.Wijnands-mldp-inband] uses in-band signaling to build mLDP P2MP tunnels to support (S, G) and (*, G) multicast states. Currently, the draft only specifies the encoding and decoding for the above two types of multicast states. It relies on a third protocol to signal PIM ASM related states. These methods, however, either add dependencies to BGP whose workload and complexity keep increasing, or support only a limited portion of PIM features. [RFC6513] extends BGP to support PIM features cross over an MPLS backbone for multicast VPN cases, however, the support is made critically dependent on the extensions to the third protocol. This dependency causes additional requirements and complexity for both network operators and equipment vendors. The extra protocol involvement also introduces more interactions among protocols and thus causes additional overheads to BGP. For B. Tao et al. Expires September 13, 2013 [Page 4] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 example, [RFC6513] uses a BGP discovery phase for a PIM state before a tunnel can be signaled in the MPLS backbone. This adds a delay to the dynamic tunnel signaling. The out-of-bound method limits itself as a solution for only certain cases because: a) It applies to a particular MPLS signaling protocol [mRSVP-TE]; b) Fully meshed PIM adjacencies over MPLS are costly and can have scalability concern (See [RFC6517]); c) The default tunnel may not be optimally routed within MPLS and its usage prevents flexible load balancing and traffic engineering at tunnel level; only limited aggregation can be done on (S, G) data tunnels; d) For PIM RPT to SPT switch, new procedures and messages are introduced. In the third solution, the supported PIM features are limited and it applies only to [mLDP] as the MPLS signaling protocol. See [RFC6517] for more information. 1.2 Purpose of This Work In this document, we introduce a PIM-MPLS inter-working framework which provides the following to resolve the current issues: a) Complete the full support of PIM features with only PIM and a point-to-multipoint(P2MP) tunneling protocol involved; b) Neutrally support various tunnel signaling protocols, including [mRSVP-TE] and [mLDP]; PIM states are "in-band" signaled by the tunnel signaling protocol to another PIM site while the signaling protocol itself uses the data to set up the tunnel with optimal routing and traffic engineering; c) Minimize the changes to the two(2) involved protocols and any introduction of new procedures; d) Provide flexible tunnel aggregation and load balancing for scalability and shared resource usage in backbone e) Minimize overheads in the backbone and on the PIM-MPLS border routers without introducing performance and scalability bottlenecks. There is no PIM adjacencies cross over the backbone network It is important to point out that some existing solutions can be made to work with this framework to have complete PIM support. [mRSVP-TE] and [mLDP] are protocols to signal point-to- multipoint(P2MP) and multipoint to multipoint(MP2MP) tunnels in an MPLS network, starting from the leaves of these tunnels. The leaf- B. Tao et al. Expires September 13, 2013 [Page 5] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 driven signaling is in the same direction as PIM builds its multicast forwarding information base, i.e., from the multicast data listeners to the senders. This framework will take advantage of this characteristics to set up the forwarding states in an MPLS backbone with less messages and delays. 1.3 Terminology 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 [RFC2119]. 2. An Overview: PIM MPLS Inter-working 2.1 PIM-SM, PIM-SSM and PIM-BiDir States [PIM] defines four(4) types of Multicast Routing Information Base(MRIB) entries: 1. (*, *, RP) 2. (*, G) 3. (S, G) 4. (S, G, rpt) For each MRIB entry, the framework identifies the following PIM forwarding states for our purpose in this document: Downstream Per-interface Join/Prune state: One of {"NoInfo" (NI), "Join" (J)} Upstream non-interface specific Join/Prune state: One of {"NotJoined", "Joined"} For each (*, G), there is a sub-set of states called (S, G, RPT), one for each (S, G) pair. In this draft, we are only concerned with their following states: B. Tao et al. Expires September 13, 2013 [Page 6] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 Downstream Per-interface Join/Prune state: One of {"NoInfo", "Pruned"} Upstream non-interface specific Join/Prune State: One of {"RPTNotJoined(G)", "NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"} For definitions of these states, readers are referred to the [PIM] document. This framework makes these PIM states as part of signaling data for a leaf-driven MPLS protocol to signal its P2MP tunnels to achieve optimal multicast routing within the MPLS network and in highly scalable fashion. On the other hand, the remote PIM site at upstream obtains these states from the MPLS signaling data to set up proper PIM forwarding states for the upstream site. These PIM states are therefore "In-Band" signaled to the remote PIM site by MPLS, while MPLS itself sets up optimized multicast LSPs for the traffic to go through the MPLS backbone. We hereafter call them M-Flow Specs, and for in-band signaling purpose, assign a value to each of the types as the following: M-Flow Spec Type-1(value 1) for (*, *, RP); M-Flow Spec Type-2(value 2) for (*, G); M-Flow Spec Type-3(value 3) for (S, G); M-Flow Spec Type-4(value 4) for (S, G, RPT); 2.2 PIM-MPLS Border Router(mPMBR) An mPMBR is a border router where PIM meets the MPLS backbone and inter-works with an MPLS signaling protocol to set up the tunnels, and where IP multicast packets exit an upstream PIM site to enter the MPLS backbone or exit the MPLS backbone to enter a downstream PIM site. An mPMBR can run a multicast member discovery protocol such as IGMP or MLD, besides PIM. Therefore the mPMBR can have local listeners. An mPMBR is called local to a PIM site if it is where the PIM site connects to the MPLS backbone. B. Tao et al. Expires September 13, 2013 [Page 7] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 For convenience in the following discussions, we define the following macro to determine where a P2MP tunnel ingress, or root, will be, for each M-Flow spec F defined previously: mPMBR_lkup(F) = { RP's local mPMBR address, if F is a (*, *, RP) spec; or RP(G)'s local mPMBR adderss if F is a (*, G) spec; or S's local mPMBR address if F is a (S, G) spec; or RP(G)'s local mPMBR if F is a (S, G, RPT) } An mPMBR needs to specify its router ID and advertise it to unicast routing protocol(s) to make the address reachable from all other mPMBRs. It also specifies its PIM interfaces that face a PIM site, as well as one or more MPLS interfaces over which P2MP tunnels can be signaled to support the inter-working functions as defined in this work. In this framework, P2MP tunnels and their sub-LSPs are dynamically created and removed when M-Flow specs are created or removed on mPMBRs. When a tunnel is created for an M-Flow spec, a logic interface is also created at the tunnel's ingress and egress endpoints, respectively. This logic interface will act as if it were a PIM interface but it does not actually run PIM on it. At an P2MP egress mPMBR, PIM builds non-interface upstream states on it using the M- Flow spec created by PIM; at the ingress, or P2MP root mPMBR, PIM builds per-interface downstream states using the M-Flow spec data signaled by the tunnel signaling protocol. An M-FLow spec is said to be "bound" to such a logic interface once the interface is created as above to pass the traffic which will be forwarded per the M-Flow spec by the IP multicast forwarding plane. At a P2MP tunnel's ingress mPMBR, IP multicast packets of the bound M-FLow spec enters this logic interface, which "leads" the packets into the MPLS tunnel. At an egress mPMBR, the packets exit the tunnel and were treated as if they were received from the logic interface as an upstream interface. At this point the packets will be forwarded using the native IP multicast forwarding rules. We call each of these logic interfaces a Quasi-PIM interface(QPI). 2.3 A Reference Model for PIM-MPLS Inter-working(PMIW) Figure 1 illustrates the PIM-MPLS inter-working model on an mPMBR. In this model, a QPI is created for an MPLS tunnel at the ingress and B. Tao et al. Expires September 13, 2013 [Page 8] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 egress LSRs, and this QPI is "advertised" to the mPMBR's PIM, so that PIM uses it as if it were a PIM interface except that PIM protocol does not actually run on it, and therefore PIM does not send or receive any PIM protocol control messages over it (i.e. there is no PIM adjacency on a QPI), but can still send and receive IP multicast data packets. The PIM on each mPMBR uses native PIM procedures to work with its PIM site router(s) and build proper PIM control and multicast packet forwarding states over the PIM interfaces as well QPIs. In order for the mPMBR PIM to build proper control and forwarding states for a QPI, PIM procedures must be modified to i) Extend any validation checks to include the QPI to accept IP multicast packets from the backbone; ii) PIM RFP_Interface() macro can return a QPI if the RPF next-hop goes over an IP interface that has MPLS enabled to support the inter-working. <---------PIM------>|<---PMIW--->|<----MPLS----> | | +--------------------------+ +-----+ | PIM | | | ---| PIM |----| |------------| ======== .......................M-Flows................... ---| |----| |------------| ======== +-----+ ^ |MFIB | ^ | | ^ ^ | +-----+--------|---|-------+ | | | ^ | | | | | | | PIM Site | | | | Router | | QPI MPLS Tunnel | | Native PIM mPMBR Interface Figure 1: mPMBR PIM-MPLS Inter-working(PMIW) Reference Model In the Figure 1, an IP multicast packet in mPMBR's PIM segment is forwarded over the PIM interface(s) as well as QPIs using PIM's B. Tao et al. Expires September 13, 2013 [Page 9] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 native forwarding rules; when an IP multicast packet enters a QPI, the packet will be encapsulated with MPLS and enters the corresponding tunnel. When a packet exits the tunnel at the remote mPMBR, the QPI on this receiving mPMBR becomes the incoming interface for the packet, and the packet enters PIM's segment where it will be forwarded under PIM's native rules. 2.3.1 QPI, MPLS Tunnel and M-Flow Spec Binding When a P2MP tunnel is created in the MPLS backbone for an M-Flow spec, a QPI is also created as an IP multicast logical interface at each of the egress and ingress mPMBRs, and the M-Flow spec is bound to the QPIs at each of the mPMBRs respectively. At the ingress mPMBR, the QPI is where an IP multicast packet enters the P2MP tunnel with the MPLS header, and is subsequently forwarded along the tunnel. At each egress mPMBR, the QPI associated with the tunnel is where the MPLS packet is de-capsulated, and the resulted IP multicast packet continues to be forwarded using PIM's native forwarding rules. The QPI operational status is the same as the P2MP tunnel operational state. At an ingress mPMBR, an M-Flow spec F is said to be "bound" to a QPI (therefore the tunnel as well) when the ingress mPMBR sets the IP multicast forwarding rules of F to use the QPI as a downstream interface in order to carry the traffic of F to other PIM sites, via the backbone network. At an egress mPMBR, an M-Flow spec F is said to be "bound" to a QPI (therefore the tunnel as well) when the egress mPMBR sets the IP multicast forwarding rules of F to use the QPI as an upstream interface in order to receive the traffic of F from another PIM site, via the backbone network. 2.3.2 PIM Support for QPI and M-Flow Spec Binding In this framework, QPIs are made to PIM as if they were a PIM interface, except that PIM control messages do not go over the QPIs. The implementation needs to establish proper PIM per-interface downstream states and upstream states for the QPI and the data signaled by MPLS, which is originated from other PIM interface states and the MPLS signaled data from the remote PIM sites. The actual implementation of the binding on each mPMBR is beyond the scope of this work. The detailed PIM protocol support for the QPI will be completed in a B. Tao et al. Expires September 13, 2013 [Page 10] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 later version. 2.3.3 M-Flow Spec Binding Policies This framework introduces two sets of policies to restrict the binding of an M-Flow to a Tunnel. 1. Default Policy: AGG_POLICY_0 (value: 0) a. One tunnel per (S, G) M-Flow spec; and b. One tunnel per RP for (*, *, RP) M-Flow spec; and c. One tunnel for all M-Flow specs of (*, G) such that RP(G) gives the same RP The default policy is used by a LSR when no other policy is explicitly specified. It is the finest grained, and MUST be provided by an implementation. 2. AGG_POLICY_1 (value: 1): a. A separate P-Tunnel is used to aggregate all (S, G) M-Flow specs such that mPMBR_lkup((S,G)) gives the same mPMBR; and b. A separate P-Tunnel is used to aggregate all (*, *, RP) M-Flow specs such that mPMBR_lkup((*, *,RP)) gives the same mPMBR; and c. A separate P-Tunnel is used to aggregate all (*, G) M-Flow specs such that mPMBR_lkup((*, G)) gives the same mPMBR. AGG_POLICY_1 is the most coarse grained and it, besides others, can be optionally provided by an implementation. 2.3.4 IP Multicast Packet Forwarding at an mPMBR If an IP multicast packet arrives at an mPMBR from a PIM interface, it is forwarded using native IP multicast rules. If an oif is a QPI, the QPI makes the packet to be forwarded into the corresponding MPLS P2MP tunnel. If an IP multicast packet arrives at an egress mPMBR from a P2MP tunnel, it is handled by the bound QPI, which acts as an iif for IP multicast flow. If there is no bound QPI, the packet is dropped. 2.4 Impacted PIM messages and procedures 2.4.1 PIM Hello and Adjacency Over MPLS Backbone An mPMBR does not build any PIM adjacency with any other mPMBR over B. Tao et al. Expires September 13, 2013 [Page 11] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 the MPLS backbone. Instead, relevant PIM states are mapped to and from the MPLS signaling data. The details will be covered in later sections when actual procedures are provided. The PIM downstream per- interface states on a QPI is directly mapped from the corresponding MPLS P2MP tunnel's in-band signaled M-Flow spec data. The PIM upstream states, on the other hand, will be in-band signed to other PIM sites by a P2MP tunneling protocol, and at the same time the signaling protocol sets up optimally routed P2MP tunnel within the MPLS for the multicast flows. There are no impacts to other routers within MPLS backbone or in PIM sites. 2.4.2 PIM Assert and Message An implementation following this framework will not need to make any changes to for PIM asserts, as they will be only applicable inside a PIM site locally, and the framework does not let PIM go cross the backbone. There are no impacts to any router in MPLS backbone or in PIM sites. 2.4.3 PIM hop-by-hop Bootstrapping and Message A designated multicast channel within MPLS backbone, called Multicast Bootstrap Tunnel(MBT), is used to carry PIM's bootstrap messages among all mPMBRs. This tunnel can be either an MP2MP or a bi- directional P2MP tree. The root is designated by the MPLS network operator and leaves are all mPMBRs. An MPLS packet entered into the MBT from any mPMBR will reach all other mPMBRs. At each mPMBR, PIM sends and receives bootstrap messages to each of the mPMBR's PIM interfaces as well as the MBT. Each mPMBRs must implement the functions to send and receive PIM bootstrap messages over the MBT. There are no other impacts to an mPMBR PIM's native bootstrap procedures, and there are no impacts to other routers other than the mPMBRs. 2.4.4 PIM Unicast Messages and C-RP Advertisement PIM unicast messages, including CRP advertisement, Register and RegisterStop, are sent and received in raw IP, with PIM protocol number. Each mPMBR must be able to receive a raw IP PIM packet arrived at a non-PIM interface that is MPLS enabled to support PIM-MPLS inter- working. B. Tao et al. Expires September 13, 2013 [Page 12] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 There are no other impacts to PIM's native procedures for unicast messages on an mPMBR, and there are no impacts to other routers other than mPMBRs. 2.4.5 PIM RP Register and RegisterStop Except for the changes common to PIM unicast messages as in the previous subsection, there are no other impacts for PIM RP register and registerStop. For information purpose, a RP may choose to send a (S, G) join toward the source S after an (S, G) register packet is received by the RP, and the resulted tree may go over the MPLS network. In this case, the mechanism and procedures for (S, G) SPT support apply. The details will be in later subsections. 2.4.6 PIM Join/Prune States and In-Band Signaling in MPLS An mPMBR, say mpmbr, can have four(4) types of M-Flow specs corresponding to PIM's upstream states. Except for the M-Flow spec Type-4, each of the rest, say, F at the mpmbr can bind to an MPLS P2MP tunnel in the MPLS network with mpmbr as one of its leaf(egress) LSRs, and the root set to mPMBR_lkup(F). A signaling protocol which is to work under this framework will support the binding of the Type- 1, Type-2, and Type-3 M-Flow specs with its tunnels. A Type-4 M-FLow spec is associated with a Type-2 M-Flow spec, as an (S, G, RPT) state is embedded into a (*, G) state. Therefore there is no separate binding for a Type-4 M-Flow spec. Before an M-Flow spec F is bound to a tunnel, the to-be bound tunnel may have some undetermined information such as a tunnel identifier, but the tunnel signaling procedure uses F and other known tunnel identification data during the tunnel signaling. After the M-Flow spec is bound to a tunnel, tunnel's identification data will be completed. The binding can happen at the leaf, at a transit LSR, or at the root, according to the binding procedure in "Algorithms and Procedures". 2.4.6.4 Aggregating Two Tunnels to Use A Single Tunnel Two tunnels may be aggregated into a single one, if their M-Flow B. Tao et al. Expires September 13, 2013 [Page 13] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 specs can be merged to form a super set of M-Flow specs, without violating each original tunnel's aggregation policy. The policy tests are performed using the algorithms and procedures as defined in Section 3. The merged tunnel can be set up using Make-Before-Break(MBB). They must have the same root in order to be aggregated. The procedure of P2MP MBB is beyond the scope of this draft. 3 Algorithms and Procedures 3.1 Dynamic P2MP Tunnel Creation and Bind An M-Flow Spec To It This section describes the procedure to bind an M-Flow spec to a tunnel. First, each M-Flow spec F has an aggregation policy to restrict aggregating the M-Flow spec into a tunnel. This policy can be configured explicitly by an operator, or is the default policy if it is not configured. An M-Flow spec F has the following attributes: F.agg_policy: An policy to restrict binding and aggregating F into a tunnel. This policy can be configured explicitly by an operator, or is the default policy if it is not configured. F.spec_type: One of the spec types. F.bound_tnl: The MPLS tunnel used by the IP multicasting data which enters and exits the tunnel per F's corresponding PIM forwarding rules. For simplicity purpose, and without implying actual implementations, the framework uses the following macros and functions on each LER or LSR: TS = {all tunnels on a node that supports PIM-MPLS inter-working}; mflow_specs(T) = {set of M-Flow specs that have bound to tunnel T} mflow_spec_type(T) = The type of the M-Flow specs that are bound to tunnel T agg_policy_compatible(F, T) = TRUE if and only if T.agg_policy derives F.agg_policy B. Tao et al. Expires September 13, 2013 [Page 14] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 agg_policy_compatible(T1, T2) = TRUE if and only if T1.agg_policy derives T2.agg_policy bind_candidate(F) { foreach(T in TS) { if ((T' = F.bound_tnl) != NULL && T' signaling is completed) { return T'; } if (F.spec_type == mflow_spec_type(T) && agg_policy_compatible(F, T)) { return T; } } return NULL; } mflow_spec_bind(F, LSR) { if ((T = bind_candidate(F)) != NULL) { mflow_specs_merge(T); F.bound_tnl = T; } else if (I_am_leaf(LSR)) { T = initiate_signal_p2mp_tunnel(F); mflow_specs(T) = {F}; F.bound_tnl = T; } else if (I_am_root(LSR)) { T = continue_signal_p2mp_tunnel(F); mflow_specs(T) = {F}; F.bound_tnl = T; } else //I am transit LSR { T = continue_signal_p2mp_tunnel(F); mflow_specs(T) = {F}; } } init_signal_p2mp_tunnel(F) triggers a P2MP tunnel creation using the local LER as the leaf, and mPMBR_lkup(F) as the root. B. Tao et al. Expires September 13, 2013 [Page 15] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 continue_signal_p2mp_tunnel(F)continues the signaling procedure for the P2MP tunnel that was initiated for F. The following defines M-Flow spec merge operation: mflow_specs_merge(T, F) { switch(F.spec_type) { case Type-1: /* mflow_specs(T) is a set of group ranges each with a list of (S, G, RPT) entries; F must be a group range with a list of its (S, G, RPT) entries */ mflow_specs(T) = mflow_specs(T) union {F}; break; case Type-2: mflow_specs(T).sg_rpt_joins = mflow_specs(T).sg_rpt_joins union F.sg_rpt_joins; mflow_specs(T).sg_rpt_prunes = mflow_specs(T).sg_rpt_prunes intersect F.sg_rpt_prunes /* sg_rpt_joins and sg_rpt_prunes are the lists of G's joined and pruned(S, G, RPT) entries */ break; case Type-3: mflow_specs(T) = mflow_specs(T) union {F}; /* mflow_specs(T) is a set of (S, G) entries */ break; case Type-4: break; /* (S, G, RPT) entries go with wildcards */ } } The actual procedures for initiate_signal_p2mp_tunnel(F) and continue_signal_p2mp_tunnel(F) are MPLS signaling protocol specific and will be out of scope for this document. 3.1.1. In-Band Tunnel Signaling at Leaf LER An M-FLow spec F is instantiated when an mPMBR PIM creates a J/P upstream state. There are three cases under which F may be bound to a P2MP tunnel at the leaf LER: Case 1: F is an M-FLow spec already bound to a tunnel egress. Therefore the corresponding QPI of the tunnel is used B. Tao et al. Expires September 13, 2013 [Page 16] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 for F. Case 2: F is not bound to an existing tunnel yet but F's binding policy is compatible with an M-Flow spec which has been bound to a P2MP tunnel. Therefore, F is then bound to the same tunnel, and its QPI is used for F. The leaf mPMBR does not initiate a new tunnel. Case 3: None of Case 1 and Case 2 is true. Then a tunnel with some unknown identifier is signaled using an extended MPLS protocol, and F as additional data for in-band signaling. Binding does not happen at this time. After the unknown tunnel signaling is completed, an upstream node, either a transit or the root should have bound F to the tunnel. In addition, it should have also determined if the tunnel is a new one or an existing one which this M-Flow spec is bound with. In the former case, a new QPI is created for the new tunnel and bound to F. In the latter case, F is bound to the QPI of the existing tunnel. 3.1.2. In-Band Tunnel Signaling at Transit LSR As a transit LSR receives a P2MP tunnel signaling message for M-Flow spec F, it does the following: Case 1: bind_candidate(F) gives a candidate tunnel T, and T is then bound to F. Therefore the LSR becomes a branching LSR. It does the following: a. Merge F into T.mflow_specs with mflow_specs_merge(T, F) b. The branching LSR MPLS signaling procedure of specific signaling protocol is then performed Case 2: Otherwise, it is still an unknown tunnel. It does: a. Merge F to T.mflow_specs using mflow_specs_merge(T, F); b. The non-branching LSR MPLS signaling procedure of the specific protocol is then performed. B. Tao et al. Expires September 13, 2013 [Page 17] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 3.1.3. In-Band Tunnel Signaling at Root LER Assume an M-FLow spec F is received at the root mPMBR from MPLS backbone. Case 1: F is an M-FLow spec already bound to a tunnel ingress. Therefore the corresponding QPI of the tunnel is used for F. Case 2: F is not bound to an existing tunnel yet but F's binding policy is compatible with an M-Flow spec which has been bound to a P2MP tunnel. Therefore, F can then be bound to the same tunnel, and its QPI is used for F. Case 3: Neither Case 1 or Case 2 can bind the M-Flow spec. a. Determine if a new tunnel or an existing tunnel is used for the M-Flow spec, based on binding policy and other requirements; if it is a new tunnel, complete the rest of tunnel signaling using the signaling protocol; b. Create a QPI for the tunnel and bound it to F; c. The new QPI is added to root mPMBR PIM as an quosi-PIM oif, and F is mapped to PIM's downstream state; d. Complete the rest signaling at root with specific tunnel signaling procedures 3.1.4. Considerations for Load Balance and Traffic Engineering(TE) Each LSR including any transit node in the MPLS backbone uses the combination of aggregation and load-balance policies, as well as traffic engineering requirements to decide if an existing tunnel should be shared for an M-Flow spec, and how to route it if the M- Flow spec is to use a separate tunnel. For example, a transit LSR may decide to merge a new M-Flow spec into an existing P2MP tunnel to avoid allocating new network resources it; or decides to reserve resources initially to be ready for a new tunnel, but once an upstream LSR decides to use an existing tunnel for the M-Flow spec, it will release the resources it has reserved earlier. But if eventually a new tunnel is created, the reserved resources will be used by the new tunnel. 3.2. Operational Procedures for PIM RPT to SPT switch B. Tao et al. Expires September 13, 2013 [Page 18] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 This framework uses mPMBR PIM's native RPT to SPT switch to initiate the corresponding traffic switch from the RPT's P2MP tunnel to the SPT's P2MP tunnel. At the downstream egress mPMBR, when a (S, G, RPT) state is created for the bound QPI, the mPMBR's PIM-MPLS inter- working module adds the corresponding M-Flow spec F of Type-4 to the tunnel's M-Flow specs, using mflow_specs_merge(T, F). The new M-FLow spec is then sent to the root mPMBR. When F is received by the root mPMBR, the native PIM procedure will be performed at the mPMBR to complete the switch. This procedure determines if (S, G) traffic should be stopped on the RPT as traffic now is being received from the SPT. 4. M-Flow Spec Format PIM passes an M-Flow spec to the MPLS signaling protocol when its forwarding state changes. An M-Flow spec is encoded in the following format: 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 | Reserved | Num groups |policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address 1 (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address m (Encoded-Group format) | B. Tao et al. Expires September 13, 2013 [Page 19] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Joined Sources | Number of Pruned Sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Joined Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address 1 (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pruned Source Address n (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An Encoded-Source address takes the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... An Encoded-Group addresses take the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group multicast Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... "Type": 1, 2, 3, or 4 to indicate M-Flow spec type. "Policy" - M-Flow spec and tunnel binding/aggregation policy. Other fields are from [PIM] and must be set according to the PIM specifications. The encoding of each M-Flow spec is specified according to its type: B. Tao et al. Expires September 13, 2013 [Page 20] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 For M-Flow Spec Type-1 (*, *, RP): The Multicast Group Address 1 gives the group range. It is encoded as the Multicast Group Address + Mask Length. A one-entry join or prune source list is used for the group range and the source address of the entry is set to the RP. (S, G, RPT) list can be encoded in by adding them in join/ prune source list for individual specific group. For M-Flow Spec Type-2 (*, G): The Multicast Group Address 1 gives the group address. It is encoded as the Multicast Group Address + full mask length. A source entry in joined or pruned source list is used for the group and the source address of the entry is set to the RP. (S, G, RPT) list may be encoded by adding them in join/prune source list for the specific group. For M-Flow Spec Type-3 (S, G): Multicast Group Address + Full Length Mask Length give the group address G; Source address is encoded into the source list. For M-Flow Spec Type-4 (S, G, RPT): Multicast Group Address + Full Length Mask Length give the group address G. Source address is encoded into the source list with 'R' bit set and 'W' bit cleared. See [PIM-SM]"Source Address" encoding for definition of these bits. 5 OAM&P B. Tao et al. Expires September 13, 2013 [Page 21] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 This section is to be completed in future. B. Tao et al. Expires September 13, 2013 [Page 22] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 6 Security Considerations There is no additional security requirement for this work. 7 IANA Considerations There is no IANA impact from the framework. 8 References 8.1 Normative References [PIM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [mRSVP-TE] R., Li, Q. Zhao, and C. Jacquenet, "Receiver-Driven Multicast Traffic Engineered Label Switched Paths", draft-lzj-mpls- receiver-driven-multicast-rsvp-te-00 (work in progress), March 2012. [mLDP] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,"Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007 8.2 Informative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC6513] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, Feb. 2012. [RFC6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", B. Tao et al. Expires September 13, 2013 [Page 23] INTERNET DRAFT MPLS PIM Inter-working March 12, 2013 RFC 6514, Feb. 2012. [RFC6517] T. Morin, B. Niven-Jenkins, Y. Kamite, R. Zhang, N. Leymann, N. Bitar, "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", RFC 6517, Feb., 2012 [RFC6037] E. Rosen, Y. Cai, and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010. [I-D.Wijnands-mldp-inband] IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala, "Multipoint LDP in-band signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-mldp-in-band-signaling-06, December 1, 2011 [I-D.rekhter-pim-sm-over-mldp] Rekhter, Y., Aggarwal, R., and N. Leymann, "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", draft-rekhter-pim-sm-over-mldp-04, August 2010. [I-D.lin-mrsvp-te-mvpn] L. Han, "Multicast VPN Support by Receiver- Driven Multicast Extensions to RSVP-TE", draft-hlj-l3vpn-mvpn-mrsvp- te-00, July 2012 Authors' Addresses Bisong Tao 2330 Central Expressway Santa Clara, CA 95050 EMail: roberttao@huawei.com Others(TBD) Acknowledgement The author(s) would like to thank the members of Huawei USA IP/MPLS Team for their helpful review comments during the work of this draft. B. Tao et al. Expires September 13, 2013 [Page 24]