idnits 2.17.1 draft-tao-mpls-pim-interworking-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([PIM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 859 has weird spacing: '...ding to the...' -- The document date (October 2, 2013) is 3858 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4875' is defined on line 927, but no explicit reference was found in the text == Unused Reference: 'RFC6037' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'I-D.rekhter-pim-sm-over-mldp' is defined on line 956, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-mldp-in-band-signaling-06 == Outdated reference: A later version (-01) exists of draft-hlj-l3vpn-mvpn-mrsvp-te-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT B. Tao, Ed. 3 Intended Status: Standards Track Huawei Technologies Inc. 4 Expires: April 2, 2014 Others 5 October 2, 2013 7 MPLS PIM Inter-working 8 draft-tao-mpls-pim-interworking-02 10 Abstract 12 This document describes a framework for the inter-working between 13 Protocol Independent Multicast [PIM] and a leaf-driven MPLS P2MP 14 tunnel signaling protocol so that multiple PIM sites around an MPLS 15 network can form a single PIM domain without compromising PIM's 16 features, scalability, and performance. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2 Purpose of This Work . . . . . . . . . . . . . . . . . . . 5 59 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2. An Overview: PIM MPLS Inter-working . . . . . . . . . . . . . 6 61 2.1 PIM-SM, PIM-SSM and PIM-BiDir States . . . . . . . . . . . . 6 62 2.2 PIM-MPLS Border Router(mPMBR) . . . . . . . . . . . . . . . 7 63 2.3 A Reference Model for PIM-MPLS Inter-working(PMIW) . . . . . 8 64 2.3.1 QPI, MPLS Tunnel and M-Flow Spec Binding . . . . . . . 10 65 2.3.2 PIM Support for QPI and M-Flow Spec Binding . . . . . . 10 66 2.3.3 M-Flow Spec Binding Policies . . . . . . . . . . . . . . 11 67 2.3.4 IP Multicast Packet Forwarding at an mPMBR . . . . . . . 11 68 2.4 Impacted PIM messages and procedures . . . . . . . . . . . . 11 69 2.4.1 PIM Hello and Adjacency Over MPLS Backbone . . . . . . . 11 70 2.4.2 PIM Assert and Message . . . . . . . . . . . . . . . . . 12 71 2.4.3 PIM hop-by-hop Bootstrapping and Message . . . . . . . . 12 72 2.4.4 PIM Unicast Messages and C-RP Advertisement . . . . . . 12 73 2.4.5 PIM RP Register and RegisterStop . . . . . . . . . . . . 13 74 2.4.6 PIM Join/Prune States and In-Band Signaling in MPLS . . 13 75 2.4.6.4 Aggregating Two Tunnels to Use A Single Tunnel . . . 13 76 3 Algorithms and Procedures . . . . . . . . . . . . . . . . . . . 14 77 3.1 Dynamic P2MP Tunnel Creation and Bind An M-Flow Spec To It . 14 78 3.1.1. In-Band Tunnel Signaling at Leaf LER . . . . . . . . . 16 79 3.1.2. In-Band Tunnel Signaling at Transit LSR . . . . . . . . 17 80 3.1.3. In-Band Tunnel Signaling at Root LER . . . . . . . . . 18 81 3.1.4. Considerations for Load Balance and Traffic 82 Engineering(TE) . . . . . . . . . . . . . . . . . . . . 18 83 3.2. Operational Procedures for PIM RPT to SPT switch . . . . . 18 84 4. M-Flow Spec Format . . . . . . . . . . . . . . . . . . . . . . 19 85 5 OAM&P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 87 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 88 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 8.1 Normative References . . . . . . . . . . . . . . . . . . . 23 90 8.2 Informative References . . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 93 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 1 Introduction 97 1.1 Background 99 IP multicast sources and their receivers can be located at multiple 100 separated sites which are around an MPLS network. PIM, the most 101 popular IP multicast protocol, runs in each of these sites. A 102 requirement therefore is to use the MPLS tunnels to "connect" these 103 multiple PIM sites as if they were in a single PIM domain. 105 Currently there are a few standards to achieve this, most of them for 106 multicast VPN(mVPN) cases: 108 a) [RFC6513] and [RFC6514] use a third protocol, the extended 109 BGP, to discover multicast routes and other states from 110 each PIM site, propagate to other sites, and establish 111 P2MP tunnels in the MPLS backbone to support VPN multicast 112 within MPLS backbone. 114 b) [I-D.lin-mrsvp-te-mvpn] uses an mRSVP-TE [mRSVP-TE] 115 tunnel within MPLS to transparently multicast both PIM's 116 control and data traffic to other VPN sites, and if 117 necessary, establishes a separated P2MP tunnel for each 118 individual multicast flow. This is an out-of-band method 119 to signal VPN PIM states over MPLS backbone. In this way, 120 separated PIM sites of a VPN form a single PIM domain in 121 the VPN, and PIM adjacencies each pair of MPLS edge routers 122 are maintained across the MPLS backbone. 124 c) [I-D.Wijnands-mldp-inband] uses in-band signaling to build 125 mLDP P2MP tunnels to support (S, G) and (*, G) multicast 126 states. Currently, the draft only specifies the encoding and 127 decoding for the above two types of multicast states. It 128 relies on a third protocol to signal PIM ASM related states. 130 These methods, however, either depends on using BGP and new 131 extensions, or support only a limited portion of PIM features for a 132 particular MPLS P2MP protocol, or has limited scale and efficiency 133 within MPLS. 135 [RFC6513] extends BGP to support PIM features across an MPLS backbone 136 for multicast VPN cases. This dependency requires the deployment of 137 BGP and its extensions, as well as the associated OAM&P. 139 The extra protocol involvement also introduces more interactions 140 among protocols and thus causes additional overheads to BGP. For 141 example, [RFC6513] uses a BGP discovery phase on a PIM join state 142 before a tunnel can be signaled in the MPLS backbone. This adds a 143 delay to the dynamic tunnel signaling. 145 The out-of-bound method limits itself as a solution for only certain 146 cases because: a) It applies to a particular MPLS signaling protocol 147 [mRSVP-TE]; b) Fully meshed PIM adjacencies make PIM procedures to 148 cross MPLS costly thus limits the solution to be used under limited 149 scale (See [RFC6517]); c) The default tunnel may not be optimally 150 routed within MPLS and its usage prevents flexible load balancing and 151 traffic engineering at tunnel level; only limited aggregation can be 152 done on (S, G) data tunnels; d) For PIM RPT to SPT switch, new 153 procedures and messages are introduced. 155 In the third solution, the supported PIM features are limited and the 156 solution is limited to [mLDP] as the MPLS signaling protocol. 158 See [RFC6517] for more information. 160 1.2 Purpose of This Work 162 In this document, we introduce a PIM-MPLS inter-working framework 163 which provides the following to resolve the current issues: 165 a) Complete the full support of PIM features with only PIM and a 166 point-to-multipoint(P2MP) tunneling protocol involved; 167 b) Neutrally support various tunnel signaling protocols, 168 including [mRSVP-TE] and [mLDP]; PIM states are "in-band" 169 signaled by the tunnel signaling protocol to another PIM site 170 while the signaling protocol itself uses the data to set up 171 the tunnel with optimal routing and traffic engineering; 172 c) Minimize the changes to the two(2) involved protocols and any 173 introduction of new procedures; 174 d) Provide flexible tunnel aggregation and load balancing for 175 scalability and shared resource usage in backbone 176 e) Minimize overheads in the backbone and on the PIM-MPLS border 177 routers without introducing performance and scalability 178 bottlenecks. There is no PIM adjacencies cross over the 179 backbone network 181 It is important to point out that some existing solutions can be made 182 to work with this framework to have complete PIM support. 184 [mRSVP-TE] and [mLDP] are protocols to signal point-to- 185 multipoint(P2MP) and multipoint to multipoint(MP2MP) tunnels in an 186 MPLS network, starting from the leaves of these tunnels. The leaf- 187 driven signaling is in the same direction as PIM builds its multicast 188 forwarding information base, i.e., from the multicast data listeners 189 to the senders. This framework will take advantage of this 190 characteristics to set up the forwarding states in an MPLS backbone 191 with less messages and delays. 193 1.3 Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 2. An Overview: PIM MPLS Inter-working 201 2.1 PIM-SM, PIM-SSM and PIM-BiDir States 203 [PIM] defines four(4) types of Multicast Routing Information 204 Base(MRIB) entries: 206 1. (*, *, RP) 207 2. (*, G) 208 3. (S, G) 209 4. (S, G, rpt) 211 For each MRIB entry, the framework identifies the following PIM 212 forwarding states for our purpose in this document: 214 Downstream Per-interface Join/Prune state: 216 One of {"NoInfo" (NI), "Join" (J)} 218 Upstream non-interface specific Join/Prune state: 220 One of {"NotJoined", "Joined"} 222 For each (*, G), there is a sub-set of states called (S, G, RPT), one 223 for each (S, G) pair. In this draft, we are only concerned with their 224 following states: 226 Downstream Per-interface Join/Prune state: 228 One of {"NoInfo", "Pruned"} 230 Upstream non-interface specific Join/Prune State: 232 One of {"RPTNotJoined(G)", "NotPruned(S,G,rpt)", 233 "Pruned(S,G,rpt)"} 235 For definitions of these states, readers are referred to the [PIM] 236 document. 238 This framework makes these PIM states as part of signaling data for a 239 leaf-driven MPLS protocol to signal its P2MP tunnels to achieve 240 optimal multicast routing within the MPLS network and in highly 241 scalable fashion. On the other hand, the remote PIM site at upstream 242 obtains these states from the MPLS signaling data to set up proper 243 PIM forwarding states for the upstream site. These PIM states are 244 therefore "In-Band" signaled to the remote PIM site by MPLS, while 245 MPLS itself sets up optimized multicast LSPs for the traffic to go 246 through the MPLS backbone. 248 We hereafter call them M-Flow Specs, and for in-band signaling 249 purpose, assign a value to each of the types as the following: 251 M-Flow Spec Type-1(value 1) for (*, *, RP); 252 M-Flow Spec Type-2(value 2) for (*, G); 253 M-Flow Spec Type-3(value 3) for (S, G); 254 M-Flow Spec Type-4(value 4) for (S, G, RPT); 256 2.2 PIM-MPLS Border Router(mPMBR) 258 An mPMBR is a border router where PIM meets the MPLS backbone and 259 inter-works with an MPLS signaling protocol to set up the tunnels, 260 and where IP multicast packets exit an upstream PIM site to enter the 261 MPLS backbone or exit the MPLS backbone to enter a downstream PIM 262 site. An mPMBR can run a multicast member discovery protocol such as 263 IGMP or MLD, besides PIM. Therefore the mPMBR can have local 264 listeners. 266 An mPMBR is called local to a PIM site if it is where the PIM site 267 connects to the MPLS backbone. 269 For convenience in the following discussions, we define the following 270 macro to determine where a P2MP tunnel ingress, or root, will be, for 271 each M-Flow spec F defined previously: 273 mPMBR_lkup(F) = { 274 RP's local mPMBR address, if F is a (*, *, RP) spec; or 275 RP(G)'s local mPMBR adderss if F is a (*, G) spec; or 276 S's local mPMBR address if F is a (S, G) spec; or 277 RP(G)'s local mPMBR if F is a (S, G, RPT) 278 } 280 An mPMBR needs to specify its router ID and advertise it to unicast 281 routing protocol(s) to make the address reachable from all other 282 mPMBRs. It also specifies its PIM interfaces that face a PIM site, as 283 well as one or more MPLS interfaces over which P2MP tunnels can be 284 signaled to support the inter-working functions as defined in this 285 work. In this framework, P2MP tunnels and their sub-LSPs are 286 dynamically created and removed when M-Flow specs are created or 287 removed on mPMBRs. 289 When a tunnel is created for an M-Flow spec, a logic interface is 290 also created at the tunnel's ingress and egress endpoints, 291 respectively. This logic interface will act as if it were a PIM 292 interface but it does not actually run PIM on it. At an P2MP egress 293 mPMBR, PIM builds non-interface upstream states on it using the M- 294 Flow spec created by PIM; at the ingress, or P2MP root mPMBR, PIM 295 builds per-interface downstream states using the M-Flow spec data 296 signaled by the tunnel signaling protocol. 298 An M-FLow spec is said to be "bound" to such a logic interface once 299 the interface is created as above to pass the traffic which will be 300 forwarded per the M-Flow spec by the IP multicast forwarding plane. 301 At a P2MP tunnel's ingress mPMBR, IP multicast packets of the bound 302 M-FLow spec enters this logic interface, which "leads" the packets 303 into the MPLS tunnel. At an egress mPMBR, the packets exit the tunnel 304 and were treated as if they were received from the logic interface as 305 an upstream interface. At this point the packets will be forwarded 306 using the native IP multicast forwarding rules. 308 We call each of these logic interfaces a Quasi-PIM interface(QPI). 310 2.3 A Reference Model for PIM-MPLS Inter-working(PMIW) 312 Figure 1 illustrates the PIM-MPLS inter-working model on an mPMBR. In 313 this model, a QPI is created for an MPLS tunnel at the ingress and 314 egress LSRs, and this QPI is "advertised" to the mPMBR's PIM, so that 315 PIM uses it as if it were a PIM interface except that PIM protocol 316 does not actually run on it, and therefore PIM does not send or 317 receive any PIM protocol control messages over it (i.e. there is no 318 PIM adjacency on a QPI), but can still send and receive IP multicast 319 data packets. 321 The PIM on each mPMBR uses native PIM procedures to work with its PIM 322 site router(s) and build proper PIM control and multicast packet 323 forwarding states over the PIM interfaces as well QPIs. 325 In order for the mPMBR PIM to build proper control and forwarding 326 states for a QPI, PIM procedures must be modified to 328 i) Extend any validation checks to include the QPI to accept 329 IP multicast packets from the backbone; 331 ii) PIM RFP_Interface() macro can return a QPI if the RPF 332 next-hop goes over an IP interface that has MPLS enabled 333 to support the inter-working. 335 <---------PIM------>|<---PMIW--->|<----MPLS----> 336 | | 337 +--------------------------+ 338 +-----+ | PIM | | | 339 ---| PIM |----| |------------| ======== 340 .......................M-Flows................... 341 ---| |----| |------------| ======== 342 +-----+ ^ |MFIB | ^ | | ^ 343 ^ | +-----+--------|---|-------+ | 344 | | ^ | | 345 | | | | | 346 PIM Site | | | | 347 Router | | QPI MPLS Tunnel 348 | | 349 Native PIM mPMBR 350 Interface 352 Figure 1: mPMBR PIM-MPLS Inter-working(PMIW) Reference Model 354 In the Figure 1, an IP multicast packet in mPMBR's PIM segment is 355 forwarded over the PIM interface(s) as well as QPIs using PIM's 356 native forwarding rules; when an IP multicast packet enters a QPI, 357 the packet will be encapsulated with MPLS and enters the 358 corresponding tunnel. When a packet exits the tunnel at the remote 359 mPMBR, the QPI on this receiving mPMBR becomes the incoming interface 360 for the packet, and the packet enters PIM's segment where it will be 361 forwarded under PIM's native rules. 363 2.3.1 QPI, MPLS Tunnel and M-Flow Spec Binding 365 When a P2MP tunnel is created in the MPLS backbone for an M-Flow 366 spec, a QPI is also created as an IP multicast logical interface at 367 each of the egress and ingress mPMBRs, and the M-Flow spec is bound 368 to the QPIs at each of the mPMBRs respectively. At the ingress mPMBR, 369 the QPI is where an IP multicast packet enters the P2MP tunnel with 370 the MPLS header, and is subsequently forwarded along the tunnel. At 371 each egress mPMBR, the QPI associated with the tunnel is where the 372 MPLS packet is de-capsulated, and the resulted IP multicast packet 373 continues to be forwarded using PIM's native forwarding rules. 375 The QPI operational status is the same as the P2MP tunnel operational 376 state. 378 At an ingress mPMBR, an M-Flow spec F is said to be "bound" to a QPI 379 (therefore the tunnel as well) when the ingress mPMBR sets the IP 380 multicast forwarding rules of F to use the QPI as a downstream 381 interface in order to carry the traffic of F to other PIM sites, via 382 the backbone network. 384 At an egress mPMBR, an M-Flow spec F is said to be "bound" to a QPI 385 (therefore the tunnel as well) when the egress mPMBR sets the IP 386 multicast forwarding rules of F to use the QPI as an upstream 387 interface in order to receive the traffic of F from another PIM site, 388 via the backbone network. 390 2.3.2 PIM Support for QPI and M-Flow Spec Binding 392 In this framework, QPIs are made to PIM as if they were a PIM 393 interface, except that PIM control messages do not go over the QPIs. 394 The implementation needs to establish proper PIM per-interface 395 downstream states and upstream states for the QPI and the data 396 signaled by MPLS, which is originated from other PIM interface states 397 and the MPLS signaled data from the remote PIM sites. 399 The actual implementation of the binding on each mPMBR is beyond the 400 scope of this work. 402 The detailed PIM protocol support for the QPI will be completed in a 403 later version. 405 2.3.3 M-Flow Spec Binding Policies 407 This framework introduces two sets of policies to restrict the 408 binding of an M-Flow to a Tunnel. 410 1. Default Policy: AGG_POLICY_0 (value: 0) 411 a. One tunnel per (S, G) M-Flow spec; and 412 b. One tunnel per RP for (*, *, RP) M-Flow spec; and 413 c. One tunnel for all M-Flow specs of (*, G) such that 414 RP(G) gives the same RP 416 The default policy is used by a LSR when no other policy is 417 explicitly specified. It is the finest grained, and MUST be provided 418 by an implementation. 420 2. AGG_POLICY_1 (value: 1): 421 a. A separate P-Tunnel is used to aggregate all (S, G) 422 M-Flow specs such that mPMBR_lkup((S,G)) gives the 423 same mPMBR; and 424 b. A separate P-Tunnel is used to aggregate all 425 (*, *, RP) M-Flow specs such that mPMBR_lkup((*, *,RP)) 426 gives the same mPMBR; and 427 c. A separate P-Tunnel is used to aggregate all (*, G) 428 M-Flow specs such that mPMBR_lkup((*, G)) gives the same 429 mPMBR. 431 AGG_POLICY_1 is the most coarse grained and it, besides others, can 432 be optionally provided by an implementation. 434 2.3.4 IP Multicast Packet Forwarding at an mPMBR 436 If an IP multicast packet arrives at an mPMBR from a PIM interface, 437 it is forwarded using native IP multicast rules. If an oif is a QPI, 438 the QPI makes the packet to be forwarded into the corresponding MPLS 439 P2MP tunnel. 441 If an IP multicast packet arrives at an egress mPMBR from a P2MP 442 tunnel, it is handled by the bound QPI, which acts as an iif for IP 443 multicast flow. If there is no bound QPI, the packet is dropped. 445 2.4 Impacted PIM messages and procedures 447 2.4.1 PIM Hello and Adjacency Over MPLS Backbone 449 An mPMBR does not build any PIM adjacency with any other mPMBR over 450 the MPLS backbone. Instead, relevant PIM states are mapped to and 451 from the MPLS signaling data. The details will be covered in later 452 sections when actual procedures are provided. The PIM downstream per- 453 interface states on a QPI is directly mapped from the corresponding 454 MPLS P2MP tunnel's in-band signaled M-Flow spec data. The PIM 455 upstream states, on the other hand, will be in-band signed to other 456 PIM sites by a P2MP tunneling protocol, and at the same time the 457 signaling protocol sets up optimally routed P2MP tunnel within the 458 MPLS for the multicast flows. 460 There are no impacts to other routers within MPLS backbone or in PIM 461 sites. 463 2.4.2 PIM Assert and Message An implementation following this framework 464 will not need to make any changes to for PIM asserts, as they will be 465 only applicable inside a PIM site locally, and the framework does not 466 let PIM go cross the backbone. 468 There are no impacts to any router in MPLS backbone or in PIM sites. 470 2.4.3 PIM hop-by-hop Bootstrapping and Message 472 A designated multicast channel within MPLS backbone, called Multicast 473 Bootstrap Tunnel(MBT), is used to carry PIM's bootstrap messages 474 among all mPMBRs. This tunnel can be either an MP2MP or a bi- 475 directional P2MP tree. The root is designated by the MPLS network 476 operator and leaves are all mPMBRs. An MPLS packet entered into the 477 MBT from any mPMBR will reach all other mPMBRs. 479 At each mPMBR, PIM sends and receives bootstrap messages to each of 480 the mPMBR's PIM interfaces as well as the MBT. Each mPMBRs must 481 implement the functions to send and receive PIM bootstrap messages 482 over the MBT. 484 There are no other impacts to an mPMBR PIM's native bootstrap 485 procedures, and there are no impacts to other routers other than the 486 mPMBRs. 488 2.4.4 PIM Unicast Messages and C-RP Advertisement 490 PIM unicast messages, including CRP advertisement, Register and 491 RegisterStop, are sent and received in raw IP, with PIM protocol 492 number. 494 Each mPMBR must be able to receive a raw IP PIM packet arrived at a 495 non-PIM interface that is MPLS enabled to support PIM-MPLS inter- 496 working. 498 There are no other impacts to PIM's native procedures for unicast 499 messages on an mPMBR, and there are no impacts to other routers other 500 than mPMBRs. 502 2.4.5 PIM RP Register and RegisterStop 504 Except for the changes common to PIM unicast messages as in the 505 previous subsection, there are no other impacts for PIM RP register 506 and registerStop. 508 For information purpose, a RP may choose to send a (S, G) join toward 509 the source S after an (S, G) register packet is received by the RP, 510 and the resulted tree may go over the MPLS network. In this case, the 511 mechanism and procedures for (S, G) SPT support apply. The details 512 will be in later subsections. 514 2.4.6 PIM Join/Prune States and In-Band Signaling in MPLS 516 An mPMBR, say mpmbr, can have four(4) types of M-Flow specs 517 corresponding to PIM's upstream states. Except for the M-Flow spec 518 Type-4, each of the rest, say, F at the mpmbr can bind to an MPLS 519 P2MP tunnel in the MPLS network with mpmbr as one of its leaf(egress) 520 LSRs, and the root set to mPMBR_lkup(F). A signaling protocol which 521 is to work under this framework will support the binding of the Type- 522 1, Type-2, and Type-3 M-Flow specs with its tunnels. A Type-4 M-FLow 523 spec is associated with a Type-2 M-Flow spec, as an (S, G, RPT) state 524 is embedded into a (*, G) state. Therefore there is no separate 525 binding for a Type-4 M-Flow spec. 527 Before an M-Flow spec F is bound to a tunnel, the to-be bound tunnel 528 may have some undetermined information such as a tunnel identifier, 529 but the tunnel signaling procedure uses F and other known tunnel 530 identification data during the tunnel signaling. After the M-Flow 531 spec is bound to a tunnel, tunnel's identification data will be 532 completed. 534 The binding can happen at the leaf, at a transit LSR, or at the root, 535 according to the binding procedure in "Algorithms and Procedures". 537 2.4.6.4 Aggregating Two Tunnels to Use A Single Tunnel 539 Two tunnels may be aggregated into a single one, if their M-Flow 540 specs can be merged to form a super set of M-Flow specs, without 541 violating each original tunnel's aggregation policy. The policy tests 542 are performed using the algorithms and procedures as defined in 543 Section 3. 545 The merged tunnel can be set up using Make-Before-Break(MBB). They 546 must have the same root in order to be aggregated. The procedure of 547 P2MP MBB is beyond the scope of this draft. 549 3 Algorithms and Procedures 551 3.1 Dynamic P2MP Tunnel Creation and Bind An M-Flow Spec To It 553 This section describes the procedure to bind an M-Flow spec to a 554 tunnel. 556 First, each M-Flow spec F has an aggregation policy to restrict 557 aggregating the M-Flow spec into a tunnel. This policy can be 558 configured explicitly by an operator, or is the default policy if it 559 is not configured. 561 An M-Flow spec F has the following attributes: 562 F.agg_policy: An policy to restrict binding and aggregating 563 F into a tunnel. This policy can be configured 564 explicitly by an operator, or is the default 565 policy if it is not configured. 567 F.spec_type: One of the spec types. 569 F.bound_tnl: The MPLS tunnel used by the IP multicasting 570 data which enters and exits the tunnel per F's 571 corresponding PIM forwarding rules. 573 For simplicity purpose, and without implying actual implementations, 574 the framework uses the following macros and functions on each LER or 575 LSR: 577 TS = {all tunnels on a node that supports PIM-MPLS 578 inter-working}; 579 mflow_specs(T) = {set of M-Flow specs that have bound to 580 tunnel T} 581 mflow_spec_type(T) = The type of the M-Flow specs that are 582 bound to tunnel T 584 agg_policy_compatible(F, T) = TRUE if and only if 585 T.agg_policy derives F.agg_policy 587 agg_policy_compatible(T1, T2) = TRUE if and only if 588 T1.agg_policy derives T2.agg_policy 590 bind_candidate(F) { 591 foreach(T in TS) { 592 if ((T' = F.bound_tnl) != NULL && T' signaling is 593 completed) 594 { 595 return T'; 596 } 597 if (F.spec_type == mflow_spec_type(T) && 598 agg_policy_compatible(F, T)) 599 { 600 return T; 601 } 602 } 603 return NULL; 604 } 606 mflow_spec_bind(F, LSR) { 607 if ((T = bind_candidate(F)) != NULL) 608 { 609 mflow_specs_merge(T); 610 F.bound_tnl = T; 611 } 612 else if (I_am_leaf(LSR)) 613 { 614 T = initiate_signal_p2mp_tunnel(F); 615 mflow_specs(T) = {F}; 616 F.bound_tnl = T; 618 } 619 else if (I_am_root(LSR)) 620 { 621 T = continue_signal_p2mp_tunnel(F); 622 mflow_specs(T) = {F}; 623 F.bound_tnl = T; 624 } 625 else //I am transit LSR 626 { 627 T = continue_signal_p2mp_tunnel(F); 628 mflow_specs(T) = {F}; 629 } 630 } 632 init_signal_p2mp_tunnel(F) triggers a P2MP tunnel creation 633 using the local LER as the leaf, and mPMBR_lkup(F) as the 634 root. 636 continue_signal_p2mp_tunnel(F)continues the signaling 637 procedure for the P2MP tunnel that was initiated for F. 639 The following defines M-Flow spec merge operation: 641 mflow_specs_merge(T, F) 642 { 643 switch(F.spec_type) 644 { 645 case Type-1: 646 /* mflow_specs(T) is a set of group ranges each with 647 a list of (S, G, RPT) entries; F must be a group 648 range with a list of its (S, G, RPT) entries */ 649 mflow_specs(T) = mflow_specs(T) union {F}; 650 break; 651 case Type-2: 652 mflow_specs(T).sg_rpt_joins = 653 mflow_specs(T).sg_rpt_joins union F.sg_rpt_joins; 654 mflow_specs(T).sg_rpt_prunes = 655 mflow_specs(T).sg_rpt_prunes intersect 656 F.sg_rpt_prunes 657 /* sg_rpt_joins and sg_rpt_prunes are the lists of G's 658 joined and pruned(S, G, RPT) entries */ 659 break; 660 case Type-3: 661 mflow_specs(T) = mflow_specs(T) union {F}; 662 /* mflow_specs(T) is a set of (S, G) entries */ 663 break; 664 case Type-4: 665 break; /* (S, G, RPT) entries go with wildcards */ 666 } 667 } 669 The actual procedures for initiate_signal_p2mp_tunnel(F) and 670 continue_signal_p2mp_tunnel(F) are MPLS signaling protocol specific 671 and will be out of scope for this document. 673 3.1.1. In-Band Tunnel Signaling at Leaf LER 675 An M-FLow spec F is instantiated when an mPMBR PIM creates a J/P 676 upstream state. There are three cases under which F may be bound to a 677 P2MP tunnel at the leaf LER: 679 Case 1: F is an M-FLow spec already bound to a tunnel egress. 680 Therefore the corresponding QPI of the tunnel is used 681 for F. 683 Case 2: F is not bound to an existing tunnel yet but F's 684 binding policy is compatible with an M-Flow spec which 685 has been bound to a P2MP tunnel. Therefore, F is then 686 bound to the same tunnel, and its QPI is used for F. 687 The leaf mPMBR does not initiate a new tunnel. 689 Case 3: None of Case 1 and Case 2 is true. Then a tunnel with 690 some unknown identifier is signaled using an extended 691 MPLS protocol, and F as additional data for in-band 692 signaling. Binding does not happen at this time. 694 After the unknown tunnel signaling is completed, an 695 upstream node, either a transit or the root should have 696 bound F to the tunnel. In addition, it should have also 697 determined if the tunnel is a new one or an existing 698 one which this M-Flow spec is bound with. 700 In the former case, a new QPI is created for the new 701 tunnel and bound to F. In the latter case, F is bound 702 to the QPI of the existing tunnel. 704 3.1.2. In-Band Tunnel Signaling at Transit LSR 706 As a transit LSR receives a P2MP tunnel signaling message for M-Flow 707 spec F, it does the following: 708 Case 1: bind_candidate(F) gives a candidate tunnel T, and T 709 is then bound to F. Therefore the LSR becomes a 710 branching LSR. It does the following: 712 a. Merge F into T.mflow_specs with 713 mflow_specs_merge(T, F) 715 b. The branching LSR MPLS signaling procedure of 716 specific signaling protocol is then performed 718 Case 2: Otherwise, it is still an unknown tunnel. It does: 720 a. Merge F to T.mflow_specs using 721 mflow_specs_merge(T, F); 723 b. The non-branching LSR MPLS signaling procedure of 724 the specific protocol is then performed. 726 3.1.3. In-Band Tunnel Signaling at Root LER 728 Assume an M-FLow spec F is received at the root mPMBR from MPLS 729 backbone. 731 Case 1: F is an M-FLow spec already bound to a tunnel ingress. 732 Therefore the corresponding QPI of the tunnel is used 733 for F. 735 Case 2: F is not bound to an existing tunnel yet but F's 736 binding policy is compatible with an M-Flow spec which 737 has been bound to a P2MP tunnel. Therefore, F can then 738 be bound to the same tunnel, and its QPI is used for F. 740 Case 3: Neither Case 1 or Case 2 can bind the M-Flow spec. 742 a. Determine if a new tunnel or an existing tunnel is 743 used for the M-Flow spec, based on binding policy 744 and other requirements; if it is a new 745 tunnel, complete the rest of tunnel signaling using 746 the signaling protocol; 747 b. Create a QPI for the tunnel and bound it to F; 748 c. The new QPI is added to root mPMBR PIM as an 749 quosi-PIM oif, and F is mapped to PIM's downstream 750 state; 751 d. Complete the rest signaling at root with specific 752 tunnel signaling procedures 754 3.1.4. Considerations for Load Balance and Traffic Engineering(TE) 756 Each LSR including any transit node in the MPLS backbone uses the 757 combination of aggregation and load-balance policies, as well as 758 traffic engineering requirements to decide if an existing tunnel 759 should be shared for an M-Flow spec, and how to route it if the M- 760 Flow spec is to use a separate tunnel. 762 For example, a transit LSR may decide to merge a new M-Flow spec into 763 an existing P2MP tunnel to avoid allocating new network resources it; 764 or decides to reserve resources initially to be ready for a new 765 tunnel, but once an upstream LSR decides to use an existing tunnel 766 for the M-Flow spec, it will release the resources it has reserved 767 earlier. But if eventually a new tunnel is created, the reserved 768 resources will be used by the new tunnel. 770 3.2. Operational Procedures for PIM RPT to SPT switch 771 This framework uses mPMBR PIM's native RPT to SPT switch to initiate 772 the corresponding traffic switch from the RPT's P2MP tunnel to the 773 SPT's P2MP tunnel. At the downstream egress mPMBR, when a (S, G, RPT) 774 state is created for the bound QPI, the mPMBR's PIM-MPLS inter- 775 working module adds the corresponding M-Flow spec F of Type-4 to the 776 tunnel's M-Flow specs, using mflow_specs_merge(T, F). The new M-FLow 777 spec is then sent to the root mPMBR. 779 When F is received by the root mPMBR, the native PIM procedure will 780 be performed at the mPMBR to complete the switch. This procedure 781 determines if (S, G) traffic should be stopped on the RPT as traffic 782 now is being received from the SPT. 784 4. M-Flow Spec Format 786 PIM passes an M-Flow spec to the MPLS signaling protocol when its 787 forwarding state changes. 789 An M-Flow spec is encoded in the following format: 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 |Type | Reserved | Num groups |policy | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Multicast Group Address 1 (Encoded-Group format) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Number of Joined Sources | Number of Pruned Sources | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Joined Source Address 1 (Encoded-Source format) | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+ 802 | . | 803 | . | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Joined Source Address n (Encoded-Source format) | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Pruned Source Address 1 (Encoded-Source format) | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | . | 810 | . | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Pruned Source Address n (Encoded-Source format) | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | . | 815 | . | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Multicast Group Address m (Encoded-Group format) | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Number of Joined Sources | Number of Pruned Sources | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Joined Source Address 1 (Encoded-Source format) | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | . | 824 | . | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Joined Source Address n (Encoded-Source format) | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Pruned Source Address 1 (Encoded-Source format) | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | . | 831 | . | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Pruned Source Address n (Encoded-Source format) | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 An Encoded-Source address takes the following format: 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Source Address 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 846 An Encoded-Group addresses take the following format: 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Group multicast Address 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 856 "Type": 1, 2, 3, or 4 to indicate M-Flow spec type. "Policy" - 857 M-Flow spec and tunnel binding/aggregation policy. 859 Other fields are from [PIM] and must be set according to the 860 PIM specifications. 862 The encoding of each M-Flow spec is specified according to its type: 864 For M-Flow Spec Type-1 (*, *, RP): 865 The Multicast Group Address 1 gives the group range. It is 866 encoded as the Multicast Group Address + Mask Length. 868 A one-entry join or prune source list is used for the group 869 range and the source address of the entry is set to the RP. 871 (S, G, RPT) list can be encoded in by adding them in join/ 872 prune source list for individual specific group. 874 For M-Flow Spec Type-2 (*, G): 876 The Multicast Group Address 1 gives the group address. It is 877 encoded as the Multicast Group Address + full mask length. 879 A source entry in joined or pruned source list is used for the 880 group and the source address of the entry is set to the RP. 882 (S, G, RPT) list may be encoded by adding them in join/prune 883 source list for the specific group. 885 For M-Flow Spec Type-3 (S, G): 886 Multicast Group Address + Full Length Mask Length give the 887 group address G; 889 Source address is encoded into the source list. 891 For M-Flow Spec Type-4 (S, G, RPT): 892 Multicast Group Address + Full Length Mask Length give the 893 group address G. 895 Source address is encoded into the source list with 'R' bit 896 set and 'W' bit cleared. See [PIM-SM]"Source Address" encoding 897 for definition of these bits. 899 5 OAM&P 900 This section is to be completed in future. 902 6 Security Considerations 904 There is no additional security requirement for this work. 906 7 IANA Considerations 908 There is no IANA impact from the framework. 910 8 References 912 8.1 Normative References 914 [PIM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 915 Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification 916 (Revised)", RFC 4601, August 2006. 918 [mRSVP-TE] R., Li, Q. Zhao, and C. Jacquenet, "Receiver-Driven 919 Multicast Traffic Engineered Label Switched Paths", draft-lzj-mpls- 920 receiver-driven-multicast-rsvp-te-00 (work in progress), March 2012. 922 [mLDP] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,"Label 923 Distribution Protocol Extensions for Point-to- Multipoint and 924 Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 925 2011. 927 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, "Extensions to 928 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for 929 Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 930 2007 932 8.2 Informative References 934 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 935 Requirement Levels", RFC 2119, March 1997. 937 [RFC6513] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 938 RFC 6513, Feb. 2012. 940 [RFC6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP 941 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", 942 RFC 6514, Feb. 2012. 944 [RFC6517] T. Morin, B. Niven-Jenkins, Y. Kamite, R. Zhang, N. 945 Leymann, N. Bitar, "Mandatory Features in a Layer 3 Multicast 946 BGP/MPLS VPN Solution", RFC 6517, Feb., 2012 948 [RFC6037] E. Rosen, Y. Cai, and IJ. Wijnands, "Cisco Systems' 949 Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010. 951 [I-D.Wijnands-mldp-inband] IJ. Wijnands, Ed., T. Eckert, N. Leymann, 952 M. Napierala, "Multipoint LDP in-band signaling for Point-to- 953 Multipoint and Multipoint-to-Multipoint Label Switched Paths", 954 draft-ietf-mpls-mldp-in-band-signaling-06, December 1, 2011 956 [I-D.rekhter-pim-sm-over-mldp] Rekhter, Y., Aggarwal, R., and N. 957 Leymann, "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", 958 draft-rekhter-pim-sm-over-mldp-04, August 2010. 960 [I-D.lin-mrsvp-te-mvpn] L. Han, "Multicast VPN Support by Receiver- 961 Driven Multicast Extensions to RSVP-TE", draft-hlj-l3vpn-mvpn-mrsvp- 962 te-00, July 2012 964 Authors' Addresses 966 Bisong Tao 967 2330 Central Expressway 968 Santa Clara, CA 95050 969 EMail: roberttao@huawei.com 971 Others(TBD) 973 Acknowledgement 975 The author(s) would like to thank the members of Huawei USA IP/MPLS 976 Team for their helpful review comments during the work of this draft.