idnits 2.17.1 draft-hlj-l3vpn-mvpn-mrsvp-te-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2012) is 4278 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-03) exists of draft-lzj-mpls-receiver-driven-multicast-rsvp-te-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group L. Han, Ed. 3 Internet-Draft R. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 31, 2013 July 30, 2012 7 Multicast VPN Support by Receiver-Driven Multicast Extensions to RSVP-TE 8 draft-hlj-l3vpn-mvpn-mrsvp-te-01 10 Abstract 12 This document describes a method to support multicast VPN (MVPN) by a 13 receiver-driven multicast extension to RSVP-TE (mRSVP-TE). This 14 method is desirable and applicable to MVPN applications when QoS 15 assurance and traffic-engineered tunnels are desired. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 31, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Multicast LSP . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. PIM States, PIM Interfaces and PMSI . . . . . . . . . . . 7 69 3.3. Reverse-Path Forwarding . . . . . . . . . . . . . . . . . 8 70 3.4. Default mLSP . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.4.1. Establishment of Default mLSP . . . . . . . . . . . . 9 72 3.4.2. Virtual PIM Interface for Default mLSP . . . . . . . . 10 73 3.4.3. PIM signaling over Default mLSP . . . . . . . . . . . 10 74 3.4.4. PIM state with Default mLSP . . . . . . . . . . . . . 12 75 3.4.5. Multicast data over default mLSP . . . . . . . . . . . 13 76 3.5. Data mLSP . . . . . . . . . . . . . . . . . . . . . . . . 13 77 3.5.1. Establishment of Data mLSP . . . . . . . . . . . . . . 13 78 3.5.2. Virtual PIM interface for Data mLSP . . . . . . . . . 14 79 3.5.3. mLSP ID and data mLSP mapping . . . . . . . . . . . . 14 80 3.5.4. Switching of Data mLSP . . . . . . . . . . . . . . . . 15 81 3.5.5. PIM Prune Impact to Data mLSP . . . . . . . . . . . . 15 82 3.5.6. Deletion of Data mLSP . . . . . . . . . . . . . . . . 16 83 3.5.7. PIM (S,G) signaling after Data mLSP is created . . . . 16 84 4. PIM-SSM Solutions . . . . . . . . . . . . . . . . . . . . . . 16 85 4.1. Option 1 . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 4.2. Option 2 . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 4.3. Option 3 . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 5. PIM-SM solutions . . . . . . . . . . . . . . . . . . . . . . . 18 89 5.1. RP-PE mLSP . . . . . . . . . . . . . . . . . . . . . . . . 18 90 5.2. Source-PE mLSP . . . . . . . . . . . . . . . . . . . . . . 18 91 5.3. PIM register process . . . . . . . . . . . . . . . . . . . 18 92 5.3.1. Scenario 1: The multicast source and RP are behind 93 the same PE . . . . . . . . . . . . . . . . . . . . . 18 94 5.3.2. Scenario 2: The multicast source and RP are behind 95 the different PE . . . . . . . . . . . . . . . . . . . 19 97 5.4. SPT switching . . . . . . . . . . . . . . . . . . . . . . 21 98 5.5. RPT prune . . . . . . . . . . . . . . . . . . . . . . . . 21 99 5.6. Data mLSP switching . . . . . . . . . . . . . . . . . . . 21 100 5.7. PIM state at Receiver-PE . . . . . . . . . . . . . . . . . 22 101 6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 6.1. Aggregation by Default mLSP . . . . . . . . . . . . . . . 23 103 6.2. Aggregation by Data mLSP . . . . . . . . . . . . . . . . . 23 104 7. Non-VPN multicast support . . . . . . . . . . . . . . . . . . 23 105 8. Message Format and Constants . . . . . . . . . . . . . . . . . 24 106 8.1. Path session object for PIM-SSM option 1 (IPv4) . . . . . 24 107 8.2. Path session object for PIM-SSM option 1 (IPv6) . . . . . 25 108 8.3. Path session object for other PIM modes (IPv4) . . . . . . 26 109 8.4. Path session object for other PIM modes (IPv6) . . . . . . 27 110 8.5. mLSP TLV Message format for IPv4 . . . . . . . . . . . . . 27 111 8.6. mLSP TLV Message format for IPv6 . . . . . . . . . . . . . 28 112 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 113 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 114 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 116 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 117 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 120 1. Introduction 122 A L3VPN service that supports multicast is known as a Multicast VPN, 123 or MVPN for short. There have been different proposed messages, 124 procedures and mechanisms to support MVPN. These methods differ in 125 protocols used in the service provider's network, for example, the 126 mGRE-based MVPN, BGP extensions to transport customer's PIM signaling 127 and P2MP RSVP-TE extensions to transport multicast data streams, and 128 mLDP-based MVPN, as summarized as follows: 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Type | Data Plane| Protocols for core | Standard| 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | 1 | mGRE | PIM, BGP(with MDT_SAFI) | RFC6037 | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | 2 | MPLS | P2MP RSVP-TE, BGP(with extension) | RFC6513 | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | 3 | MPLS | mLDP | No | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Table 1. Existing mVPN Solutions 142 Type 1 solution requires to run PIM in the service provider's 143 network. 145 Both Type 2 and Type 3 require an MPLS data forwarding plane, but 146 they differ in protocols used in the service provider's network. 147 Type 2 uses RSVP-TE with a P2MP extension [RFC4875] for multicast 148 data streams and BGP extensions with multicast encodings and 149 procedures [RFC6514] for PIM signaling, or use mLDP [RFC6388] for 150 both control plane signaling and multicast data streams. Type 3 is 151 simpler than type 2 in terms of required protocols and provisioning. 153 With Type 2 solution, multicast traffic is carried over MPLS-TE 154 tunnels, QoS and traffic engineering are supported for mVPN 155 applications. It is an advantage of Type 2 over Type 3. 157 However, for Type 2 solution, BGP has to be extended with seven (7) 158 types of MCAST-VPN NLRIs together with four (4) new BGP attributes. 159 In some scenarios, multiple P2MP RSVP-TE tunnels are used. And 160 therefore, it requires to upgrade both BGP and RSVP-TE, which brings 161 more complexity and operational inconvenience. 163 In addition to the above-mentioned three methods, do we have any 164 alternative method which is expected to be simpler and more scalable, 165 but can still provide QoS assurance and traffic-engineered transport? 167 This document specifies a new method to implement multicast VPN by 168 receiver-driven multicast extensions to RSVP-TE (mRSVP-TE) specified 169 in [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]. mRSVP-TE is a 170 new extension to RSVP-TE for multicast applications in MPLS networks, 171 whose behavior is closer to IP PIM since both of them work by sending 172 control messages from the data receivers to the data senders. The 173 receiver-driven nature of the mRSVP-TE makes it more adaptive and 174 easier to be integrated with PIM for multicast applications including 175 multicast VPN. 177 As an extension to RSVP-TE, mRSVP-TE inherits all the desirable 178 features from RSVP-TE such as QoS assurance and traffic-engineered 179 paths, which makes it to distinguish from mLDP used in Type 3. 181 By using an MP2MP tunnel created by mRSVP-TE to carry the customer's 182 PIM signaling, we do not need to use BGP multicast extension to 183 signal customer's multicast information. 185 The MVPN method described in the document supports both PIM-SSM and 186 PIM-SM. For PIM-SM, this method supports multicast source, receiver, 187 Rendezvous Point (RP) located at any place including PE, CE or any 188 device connected to CE. It can also support Bootstrap Router (BSR) 189 Mechanism [RFC5059]. 191 2. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119] and 196 indicate requirement levels for compliant MVPN implementations. 198 2.1. Definitions 200 In what follows we describe some terminologies which are widely used 201 in this document. 203 Source-PE 204 Source-PE is a PE which is connected to a MVPN CE and the 205 multicast source is on or behind the CE. 207 Receiver-PE 208 Receiver-PE is a PE which is connected to a MVPN CE and the 209 multicast receiver is on or behind the CE 211 RP-PE 212 RP PE is a PE which is connected to a MVPN CE and the multicast 213 Rendezvous Point for PIM-SM is on or behind the CE 215 PE type 216 A PE can be either Source-PE, Receiver-PE or RP-PE for 217 different MVPN and different (S,G). Its type can also be the 218 mixture of any combination of the three PE type. 220 MDT 221 Multicast Distribution Tree, introduced in [RFC6037] for the IP 222 backbone based MVPN. MDT is composed of mGRE tunnels. There 223 are default MDT and data MDT 225 mLSP 226 Multicast-Label-Switched-Path. It is the equivalent of MDT in 227 MPLS networks, and sometimes we will use mLSP and MDT 228 interchangeably. The same as MDT, we also have default mLSP 229 and data mLSP. 231 Source-PE mLSP 232 mLSP whose header-end is a Source-PE. 234 RP-PE mLSP 235 mLSP whose header-end is a RP-PE. 237 MI-PMSI(MVPN_ID) 238 It corresponds to the MI-PMSI [RFC6513] for a MVPN (ID is 239 MVPN_ID), it is the Multidirectional Inclusive P-Multicast 240 Service interface for the default mLSP or the MP2MP tunnel at 241 either tail-end or header-end. 243 S-PMSI(MVPN_ID, mLSP_ID) 244 It corresponds to a S-PMSI [RFC6513] for a MVPN (ID is MVPN_ID) 245 and the mLSP ID is mLSP_ID, it is the Selective P-Multicast 246 Service interface for the P2MP tunnel for (S,G) at either tail- 247 end or header-end. 249 OIF 250 Outgoing Interface for PIM state 252 IIF 253 Incoming Interface for PIM state 255 Olist 256 Outgoing Interface list for PIM state 258 3. Overview 259 3.1. Multicast LSP 261 Multicast-Label-Switched-Path (mLSP) is an MPLS tree in MPLS network 262 to distribute multicast data to different receivers who are 263 interested in particular multicasted data stream(s). An mLSP is 264 composed of multiple Sub-Label-Switched-Paths (sub-LSP) which connect 265 different Label Switch Routers (LSRs) to form an MPLS multicast 266 network. There are two basic types of mLSPs: P2MP LSP and MP2MP LSP. 267 In the case of P2MP LSP, the header-end of an mLSP is the Source-PE 268 which connects the source device of multicast traffic, and its tail- 269 ends are the Receiver-PEs which connect the destination device of 270 multicast traffic. The joint points on an mLSP are called "Branch 271 LSR" where the MPLS packets are replicated and then forwarded to 272 different downstream LSRs. In the case of MP2MP LSP, there is a 273 special LSR which serves as the root of the mLSP, and all the leaf 274 nodes are both the Source-PE and Receiver-PEs. 276 For mVPN multicast traffic, it travels on a multicast tree which 277 spans over two different networks: MPLS network operated by service 278 providers and IP network on the customer's sites. The mVPN multicast 279 traffic always starts from one customer's site as IP multicast, and 280 then is transported over the MPLS network to other customer's sites. 281 The traffic on customer's sites is distributed over a PIM multicast 282 distribution tree, while in service provider's MPLS network it is 283 distributed by mLSP tunnels. The mLSP and the PIM distribution tree 284 SHOULD be seamlessly integrated. The IP multicast data received from 285 a CE is encapsulated as MPLS packet at the Source-PE of an mLSP tree, 286 and then transported over the mLSP. The MPLS packet is replicated at 287 the branch LSRs and delivered to the different Receiver-PEs, where 288 the MPLS packet is de-capsulated to IP multicast packet and forwarded 289 to the connected IP multicast tree, then it is distributed to the 290 particular receivers. 292 3.2. PIM States, PIM Interfaces and PMSI 294 It is assumed that PIM is used on customer's sites and mRSVP-TE is 295 used in service provider's network without PIM being enabled in 296 service provider's network. In order to set up customer's multicast 297 distribution trees across a service provider's MPLS network, it is 298 desired that the customer's PIM SHOULD inter-work with service 299 provider's mRSVP-TE, which brings up some new requirements about PIM 300 states and interfaces. 302 The most important factors for PIM states are the IIF and OIF, both 303 of which are PIM-enabled interfaces. A PIM interface appearing in an 304 PIM state is characterized as follows: 306 o It has an IP address configured 308 o It has the PIM protocol enabled and running 310 o It has one or more PIM adjacencies 312 Since the customer's PIM adjacencies MUST be established between PEs, 313 virtual interfaces associated with the MPLS tunnels connecting PEs 314 are introduced. Such virtual interfaces are also called PMSI for 315 Provider Multicast Service Interface. In this document we will use 316 two types of PMSI: MI-PMSI and S-PMSI. 318 3.3. Reverse-Path Forwarding 320 For multicast forwarding by a PIM state (S,G), we need to check if 321 the packet is coming from the expected interface which is the egress 322 interface to reach the source S based on the unicast routing table. 323 The expected interface is called RPF interface, or the IIF (Incoming 324 interface). In this document, we will consider the following two 325 modes: 327 o PIM-SSM mode: the state to forward traffic is (S,G), so there is 328 only one IIF for a (S,G). 330 o PIM-SM mode: RP will have (*,G) before the traffic is received and 331 (S,G) after the register processing is finished. Other routers 332 have (*,G) before the SPT switching and (S,G) after the SPT 333 switching. For the (*,G), the RPF is the interface to reach RP by 334 unicast routing. 336 In the context of mVPN, PE is the boundary router between customer's 337 IP network and service provider's MPLS network, and thus needs to 338 handle the RPF issue as follows: 340 o For a Source-PE, the RPF checking for any (S,G) does not have any 341 change since the IIF is still a normal IP interface. 343 o For a Receiver-PE, the RPF interface for any (S,G) or (*,G) is not 344 derived from the unicast routing table for the multicast source S 345 or RP for a multicast stream. Instead, we MUST force the RPF 346 interface to be the PIM interface which is associated with either 347 an MI-PMSI or an S-PMSI. 349 o For a RP-PE, before traffic starts, the RPF interface is not set 350 for (*,G) since the multicast source is unknown. After the PIM 351 register process is completed, the (S,G) state will be created. 352 Then we MUST force the RPF interface to be the PIM interface which 353 is associated with the MI-PMSI for the MVPN. 355 RPF does not apply to the multicast forwarding in MPLS network by 356 mLSP. mLSP established by mRSVP-TE protocol can guarantee the loop- 357 free for packet forwarding which is the whole purpose of RPF 358 checking. 360 3.4. Default mLSP 362 To each mVPN, we associate an mLSP, called its default mLSP. Given 363 an mVPN, its default mLSP is a multi-directional shared tree with all 364 the PEs as its leaf nodes. Default mLSP is a MP2MP tunnel which can 365 provide a multi-directional transportation for any data. The default 366 mLSP is used for the following two purposes: 368 o Cusomer's PIM signaling: Cusomer's PIM signaling is transported 369 over such default mLSP 371 o Default customer's multicast data distribution: Customer's 372 multicast data are transported and distributed over such mLSP by 373 default. 375 3.4.1. Establishment of Default mLSP 377 The construction of default mLSP does not depend on the existence of 378 multicast traffic for a MVPN; it is built up before any such 379 multicast traffic is seen. 381 Default mLSP is established when a VPN attached to a PE enables MVPN 382 service. After the MVPN is enabled, the mRSVP-TE stack MUST send the 383 mRSVP-TE path message continuously. The time interval to send the 384 path message at each PE could be default value or configurable. If 385 it is configurable, different PE's interval value MUST be proper to 386 guarantee the mLSP state is steady without any flapping. 388 To enable MVPN service on a PE, root node(s) IP address MUST be 389 given. Root node is normally a P router inside the backbone network. 391 The location of root node may impact the efficiency of a MP2MP 392 tunnel. How to choose a root node to establish a MP2MP tunnel to 393 obtain the efficient multicast replication in MPLS network is out of 394 scope of the document. 396 In addition to the root node, explicit nodes from any PE to the root 397 node P MAY be applied as an option if user wants the path from the 398 root node P to a PE goes through some expected routers. 400 For the details of root node and explicit node in a MP2MP tunnel, 401 please refer to the [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]. 403 If the redundancy for the root node is desired to protect the failure 404 of root node, multiple root nodes may be given to construct multiple 405 default mLSP. The redundancy for root node is out of scope of this 406 document. 408 With the method herein, there is only one default mLSP for each MVPN, 409 or two for root redundancy case, 411 3.4.2. Virtual PIM Interface for Default mLSP 413 A MI-MPSI interface SHOULD be created at both Source-PE and 414 Receiver-PE when the default mLSP for a MVPN is established. This is 415 a PIM enabled interface for a MVPN. It is used for PIM adjacency, 416 PIM state keeping, and PIM IIF and OIF representation for the MPLS 417 packet forwarding over MPLS network. 419 MI-PMSI is a joint point of IP multicast tree and mLSP. If a MI-PMSI 420 is one OIF in the Olist for a multicast forwarding entry (S,G), it 421 means the IP multicast stream (S,G) will be replicated for the MI- 422 PMSI and sent to the interface. If a MI-PMSI is the IIF for a 423 multicast forwarding entry (S,G), it means the MPLS packet received 424 from MI-PMSI will be forwarded by the forwarding entry (S,G) if the 425 de-capsulated MPLS packet is IP packet, and source and group are S 426 and G respectively. 428 MI-PMSI is a PIM interface and its IP address will be the address for 429 the PIM peering. This address on one PE MUST be reachable from all 430 other PEs. When PIM adjacency are established between PEs, one PE 431 can see all its PIM adjacency's MI-PMSI are up. For the convenience, 432 it is RECOMMENDED to use the BGP source address for the BGP session 433 between PEs for MI-PMSI. The BGP session here refers to the BGP for 434 unicast VPN service. 436 All PIM hello variables for a virtual interface MI-PMSI, such as 437 timer, are default value when the interface is created. But they 438 could be configurable and this is up to the implementation. 440 3.4.3. PIM signaling over Default mLSP 442 For MVPN attached PE, PIM is enabled for the interfaces connecting 443 different CEs which may belong to the same or different VPNs. Each 444 interface has a MVPN instance associated with it. After a MI- 445 PMSI(MVPN_ID) is created for a default mLSP, it MUST join the same 446 PIM domain for the particular MVPN. 448 The default mLSP SHOULD support all PIM multicast messages: 450 o HELLO message 452 o JOIN/PRUNE message 454 o ASSERT 456 o BOOTSTRAP 458 For the following PIM unicast message, they SHOULD NOT be sent to the 459 default mLSP, instead, they SHOULD be sent over a unicast MPLS tunnel 460 to the destination PE. 462 o REGISTER message 464 o REGISTER-STOP message 466 o GRAFT 468 o GRAFT-ACK 470 o CANDIDATE-RP-ADV 472 For one MVPN at a PE, PIM signaling (multicast) messages SHOULD be 473 multicasted to all PIM interfaces for that particular MVPN including 474 MI-PMSI. PIM messages are sent to a MI-PMSI(MVPN_ID) immediately 475 after the interface is created. The messages are encapsulated to 476 MPLS packets and will be distributed to all other receiver-PEs in the 477 same MVPN through the default mLSP. 479 At Receiver-PE, the MPLS packets are de-capsulated and delivered to a 480 particular MVPN, the MVPN ID is determined by the MPLS label which 481 was allocated locally on Receiver-PE when the PE initializes the 482 default mLSP by sending mRSVP-TE path message to the root node. The 483 popped MPLS label from the received MPLS packet can associate the 484 packet with a MI-PMSI(MVPN_ID) interface as incoming interface, So, 485 the MI-PMSI(MVPN_ID) interface at Receiver-PE can be used for RPF 486 checking of multicast forwarding. 488 Receiver-PE SHOULD punt PIM signaling message to PIM protocol stack 489 for the particular MVPN. After all PIM HELLO messages are exchanged 490 between PEs, PIM adjacencies are established between multiple PEs 491 through each PE's MI-PMSI(MVPN_ID) which is associated with a 492 particular MVPN. 494 As the result of PIM adjacency over the default mLSP, the details of 495 MPLS backbone network topology is hidden for PIM. It will make the 496 MVPN PIM virtually run over a virtual muti-access interface which is 497 composed of multiple MI-PMSI(MVPN_ID) from different PEs. 499 3.4.4. PIM state with Default mLSP 501 Since the MI-PMSI interface is a PIM enabled interface, all PIM 502 multicast messages, Hello, Join, Prune, Bootstrap and Assert, can be 503 sent to or received from the MI-PMSI interface. PIM protocol can 504 create and update the appropriate state for a MVPN accordingly. MI- 505 PMSI can behavior as a normal PIM interface to join or exit the Olist 506 for PIM state. 508 Below is the detail of the PIM processing for different PIM modes and 509 join messages. All behaviors are based on the PIM protocol and some 510 PIM changes are required for MVPN solution described in this 511 document. 513 (S,G) join for PIM-SSM 514 When a Receiver-PE receives PIM (S,G) join message from 515 attached CE, it SHOULD send the join message through MI- 516 PMSI(MVPN_ID) interface to the default mLSP. Meanwhile, if PIM 517 (S,G) state was not created on the Receiver-PE, PIM MUST create 518 a (S,G) state for which the MI-PMSI(MVPN_ID) is IIF. As a 519 result of sending PIM join message to MI-PMSI(MVPN_ID) 520 interface, the message will be populated to all PEs connected 521 to the same default mLSP. However, only Source-PE SHOULD 522 process the PIM join message. The Source-PE is derived from 523 the BGP next hop of source address S. All other PEs SHOULD 524 ignore the join message. After the Source-PE receives the 525 (S,G) join from a default mLSP, if the PIM (S,G) state was not 526 created, PIM SHOULD create a PIM (S,G) state for multicast 527 routing table, the entry SHOULD add MI-PMSI(MVPN_ID) to its 528 Olist. After the 1st PIM join message is processed at both 529 Receiver-PE and Source-PE, the subsequent PIM join message will 530 only reset the PIM timer and will not change the PIM (S,G) 531 state. This behavior is same as PIM in IP network. 533 (*,G,RP) join for PIM-SM 534 PIM-SM (*,G) join message will be populated through default 535 mLSP to all PEs attached to the same mLSP. The behavior for 536 PIM (*,G) join is the same as PIM-SSM. The only difference is 537 that (*,G) join is sent to RP (Rendezvous Points). As a 538 result, only RP-PE SHOULD process the PIM join message. The 539 RP-PE is derived from the BGP next hop of RP address. All 540 other PEs SHOULD ignore the join message. After the PIM (*,G) 541 join message is sent from Receiver-PE and received by RP-PE. 542 PIM SHOULD create a (*,G) state on Receiver-PE, for which the 543 MI-PMSI(MVPN_ID) is IIF. PIM SHOULD create a (*,G) state at 544 RP-PE and add the MI-PMSI(MVPN_ID) to its Olist. 546 PIM prune message processing has no change on PE, it may lead to the 547 interface state change for a PIM state, or a PIM state deletion. 548 When a PIM state is deleted on a receiver-PE, it MUST send the PIM 549 prune message to the default mLSP to forward the prune message to 550 source-PE or RP-PE. When a Source-PE or RP-PE receives a prune 551 message from the default mLSP, it MUST prune the MI-PMSI from the PIM 552 state's Olist. 554 3.4.5. Multicast data over default mLSP 556 If a default mLSP is used to carry user's multicast data, it will 557 send the multicast data to all PEs connected to the default mLSP, no 558 matter if a PE is intended or not to receive the particular multicast 559 traffic. The PIM join or prune does not start or stop the traffic 560 over the default mLSP. This is normally used for the beginning of 561 the multicast traffic flowing when the traffic rate is low. 562 Obviously, there are two drawbacks for it 564 o Some PE may not want to receive some multicast traffic, this will 565 be wasteful for the bandwidth and resource for routers. 567 o Too much multicast data shares one tree can congest the MP2MP 568 tunnel. 570 To overcome above problems, data mLSP is used to offload the data 571 traffic from the default mLSP. 573 3.5. Data mLSP 575 Data mLSP is used to offload some data stream from the default mLSP. 576 It is a P2MP tunnel corresponding to a (S,G) entry in a MVPN. Data 577 mLSP is built up either statically or dynamically depending on the 578 solutions for different PIM modes. Section 4 and 5 will discuss 579 details. 581 3.5.1. Establishment of Data mLSP 583 Static data mLSP establishment is triggered by a Receiver-PE to send 584 the mRSVP-TE P2MP path message to a Source-PE. It will be described 585 in section 4.1. 587 Dynamical data mLSP establishment is driven by the multicast traffic. 588 The mechanism is similar to the data MDT described in [RFC6037]. 590 Source-PE MUST monitor the rate of all multicast streams passing 591 through it. As for how to monitor the traffic rate, it is out of the 592 scope of the document. 594 When a Source-PE detects the rate of a MVPN multicast stream (S,G) 595 exceeds the pre-configured threshold, it MUST send a data mLSP join 596 TLV to the default data mLSP. The format of data mLSP join TLV is 597 defined in section 8.5 and 8.6. 599 The data mLSP join TLV will be flooded to all PE connected to the 600 same default mLSP. When a PE receives the data mLSP join TLV and if 601 the PE has joined the group G, it MUST initialize the setup of P2MP 602 tunnel by sending the mRSVP-TE P2MP path message to the Source-PE for 603 (S,G). Source-PE address is derived from the BGP nexhop of the VPN 604 address S. 606 The periodically sending of mRSVP-TE path message from receiver-PE to 607 Source-PE is driven by the periodically received mLSP join TLV 608 message at receiver-PE 610 The operation of data mLSP is similar to the operation of data MDT 611 for mGRE based mVPN. It has four timer defined to govern the data 612 mLSP: MDT_DATA_DELAY, MDT_DATA_TIMEOUT, MDT_DATA_HOLDDOWN, 613 MDT_INTERVAL. For the detailed definition of those timers and 614 operations, please refer to [RFC6037]. 616 Since the interval to receive mLSP join TLV message will determine 617 the interval to send mRSVP-TE path message, we SHOULD make sure the 618 interval of mLSP join TLV is less than the timeout value of sub-LSP 619 created by the mRSVP-TE path message. 621 3.5.2. Virtual PIM interface for Data mLSP 623 After a data mLSP is created, the S-PMSI(MVPN_ID,mLSP_ID) MUST be 624 instantiated. S-PMSI(MVPN_ID,mLSP_ID) is only used for Incoming 625 Interface (IIF) at Receiver-PE and Outgoing Interface (OIF) at 626 Source-PE for the multicast forwarding, it is not used for PIM 627 signaling. 629 The mLSP_ID is "mLSP ID" shown in Fig.3 which is assigned at 630 Source-PE. 632 S-PMSI(MVPN_ID,mLSP_ID) points to the same PIM interface as MI- 633 PMSI(MVPN_ID). It only adds extra L2 rewriting information block to 634 the PIM interface for the packet forwarding purpose. 636 3.5.3. mLSP ID and data mLSP mapping 638 Data mLSP is identified by "mLSP ID" which is defined in section 8.3 639 and 8.4. mLSP ID is a 4 byte value starting from 1 for data mLSP. 640 mLSP ID 0 is reserved for the default mLSP. mLSP ID is to distinguish 641 different data mLSP (P2MP tunnel) at Source-PE side. During the data 642 mLSP building, the mLSP ID allocated at a Source-PE MUST be notified 643 to all Receiver-PE by the mLSP join TLV. 645 When a Source-PE detects the rate of a MVPN multicast stream (S,G) 646 exceeds the pre-configured threshold, it MUST assign a mLSP ID from 647 its mLSP pool for the (S,G). And the mLSP join TLV message binds 648 (S,G) with mLSP ID. The Receiver-PE receiving the mLSP join TLV will 649 know the binding relationship. As a result, both Source-PE and 650 Receiver-PE will have a mapping for the mLSP ID and data mLSP, this 651 is used for the switching of data MDT for a stream (S,G). 653 After a data MLSP is deleted, the associated mLSP ID MUST be returned 654 to the mLSP pool. 656 3.5.4. Switching of Data mLSP 658 The Source-PE SHOULD switch the traffic from default mLSP to data 659 mLSP after it created the data mLSP for a multicast stream (S,G). 660 The mLSP ID and data mLSP mapping information will tell which data 661 mLSP is used for which stream (S,G). From the PIM state point of 662 view, at Source-PE, the PIM state (S,G) SHOULD change the OIF from 663 MI-PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). Since MI-PMSI(MVPN_ID) 664 and S-PMSI(MVPN_ID, mLSP_ID) share the same PIM interface, the 665 switching essentially means the MPLS forwarding is switched from the 666 MP2MP tunnel to P2MP tunnel. There is no PIM interface changing for 667 PIM signaling during and after the data mLSP switching 669 After switching, Receiver-PE MUST use the correct data mLSP 670 associated S-PMSI(MVPN_ID, mLSP_ID) for the RPF checking for a stream 671 (S,G). 673 The data mLSP switching is associated with the change of forwarding 674 state for (S,G) as following 676 o Source-PE MUST modify the OIF from MI-PMSI(MVPN_ID) to 677 S-PMSI(MVPN_ID, mLSP_ID). 679 o Receiver-PE MUST modify the IIF from MI-PMSI(MVPN_ID) to 680 S-PMSI(MVPN_ID, mLSP_ID). 682 3.5.5. PIM Prune Impact to Data mLSP 684 When the multicast data is transported over a data mLSP, the PIM 685 prune may cause the prune of the data mLSP tree. After a Receiver-PE 686 receives PIM prune message and if the prune message leads to the IIF 687 prune for a PIM state, it MUST update the PIM state in such that the 688 IIF represented by the S-PMSI(MVPN_ID,mLSP_ID) is pruned. And the 689 Receiver-PE MUST send the mRSVP-TE PATHTEAR message to the upstream 690 LSR to prune the data mLSP tree. If a Source-PE receives the 691 mRSVP-TE PATHTEAR message, the whole data mLSP is deleted and 692 Source-PE MUST stop flooding the mLSP join TLV to the default mLSP. 694 3.5.6. Deletion of Data mLSP 696 Data mLSP join TLV will be flooded through default mLSP periodically 697 by the interval of MDT_INTERVAL [RFC6037], if during the timeout 698 period defined by MDT_DATA_TIMEOUT [RFC6037], there is no mLSP join 699 TLV received for a receiver-PE, the receiver-PE will start to delete 700 the P2MP leaf from the data mLSP. This is done by sending mRSVP-TE 701 PATHTEAR message to the upstream LSR. After the whole data mLSP is 702 deleted, the traffic will be switched back to the default mLSP. 704 3.5.7. PIM (S,G) signaling after Data mLSP is created 706 When a data mLSP is created for a particular multicast stream (S,G), 707 the PIM signaling is not changed. PIM join, prune for (S,G) is still 708 going through the default mLSP. 710 4. PIM-SSM Solutions 712 To support PIM-SSM by mRSVP, we have three options. 714 4.1. Option 1 716 PIM (S,G) join message received at Receiver-PE MUST trigger the data 717 mLSP setup by sending a mRSVP-TE P2MP path message to the Source-PE, 718 if the data mLSP was not created before. Source-PE address is the 719 BGP next hop of the address S. The mRSVP-TE path message MUST embed 720 the (S,G) information as shown in Fig. 1. 722 PIM join message is sent to default mLSP and received by the 723 Source-PE. This SHOULD trigger the PIM (S,G) state created at 724 Source-PE and Receiver-PE. The (S,G) state at Source-PE MUST add the 725 S-PMSI(MVPN_ID,mLSP_ID) for the data mLSP to its Olist; The (S,G) 726 state at reveier-PE SHOULD set the S-PMSI(MVPN_ID,mLSP_ID) as IIF. 728 After the PIM (S,G) state created at Source-PE, the traffic can be 729 sent to data mLSP immediately. 731 The P2MP mRSVP-TE path message for data mLSP MUST include the ERO 732 objects when the explicit path is given for the source S. 734 There is no default mLSP to data mLSP switching for this option. 736 4.2. Option 2 738 PIM (S,G) join message received at Receiver-PE MUST be sent to the 739 default mLSP and received by the Source-PE. This SHOULD trigger the 740 PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM 741 state was not created before. The PIM (S,G) state at Source-PE 742 SHOULD add the MI-PMSI(MVPN_ID) as OIF; The (S,G) state at 743 receiver-PE SHOULD add the MI-PMSI(MVPN_ID) as IIF. 745 After the (S,G) state created at source-PE, the traffic can be sent 746 to the default mLSP. 748 Source-PE MUST detects the rate for the multicast stream (S,G) in a 749 MVPN. If the traffic rate for (S,G) exceeds the configured 750 threshold, the Source-PE MUST flood the mLSP join TLV to all PEs. 751 Each PE, if it is interested to receive the traffic for (S,G), MUST 752 initialize a mRSVP-TE P2MP path message to the Source-PE. 754 The P2MP path message MUST include the ERO objects when the explicit 755 path is given for the source S. 757 After the Source-PE creates a data mLSP for (S,G), it MUST switch the 758 traffic from default mLSP to data mLSP. 760 4.3. Option 3 762 PIM (S,G) join message received at Receiver-PE MUST be sent to the 763 default mLSP and received by the Source-PE. This SHOULD trigger the 764 PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM 765 state was not created before. Unlike the option 2, PIM does not add 766 the default mLSP interface MI-PMSI(MVPN_ID) as the IIF and OIF for 767 (S,G) state. In stead, Source-PE MUST trigger a mLSP join TLV 768 flooded to all PEs. Each PE, if it is interested to receive the 769 traffic for (S,G), MUST initialize a mRSVP-TE P2MP path message to 770 the Source-PE to build up a data mLSP. 772 As the result of data mLSP setup, The PIM (S,G) state at receiver-PE 773 MUST add the S-PMSI(MVPN_ID, mLSP_ID) as IIF. At the Source-PE, 774 after the data mLSP is created. The PIM (S,G) state MUST add the 775 S-PMSI(MVPN_ID, mLSP_ID) as OIF; 777 The P2MP path message MUST include the ERO objects when the explicit 778 path is given for the source S. 780 There is no default mLSP to data mLSP switching for this option. 782 5. PIM-SM solutions 784 PIM-SM supporting is different to the PIM-SSM. It involves some 785 extra process like PIM register, register stop, RPT and SPT 786 switching, etc [RFC4601]. Following describes the details of 787 different scenarios for MVPN PIM-SM. 789 5.1. RP-PE mLSP 791 RP-PE mLSP is a mLSP whose header-end is at the RP-PE, and multiple 792 tail-ends at different Receiver-PEs. RP-PE mLSP is the equivalence 793 of RPT (RP tree or shared tree) of IP PIM in MPLS network. RP-PE 794 mLSP will use the default mLSP in the method specified in this 795 document. 797 PIM (*,G,RP) join message received at Receiver-PE MUST be sent to the 798 default mLSP and finally reach the RP-PE. Then, the Source-PE and 799 RP-PE can create the PIM state for (*,G). The (*, G) state at RP-PE 800 MUST have the MI-PMSI(MVPN_ID) as its OIF, and the (*, G) state at 801 Receiver-PE MUST have the MI-PMSI(MVPN_ID) as its IIF. 803 5.2. Source-PE mLSP 805 Source-PE mLSP is a mLSP whose header-end is at a Source-PE. 806 Depending on the location of tail-end, we have Source-PE to RP-PE 807 mLSP, and Source-PE to Receiver-PE mLSP. Source-PE to RP-PE mLSP is 808 the tree whose header-end is at the source-PE, and the tail-ends at 809 RP-PE. It is constructed after the PIM register process is finished 810 but before the PIM SPT switching or data mLSP switching. Source-PE 811 to receiver-PE mLSP is the tree whose header-end is at the source-PE, 812 and the tail-ends at receiver-PEs. It is built after SPT switching 813 or data mLSP switching. By the method specified in this document, 814 Source-PE to RP-PE mLSP also use the default mLSP like RP-PE mLSP. 815 source-PE to receiver-PE mLSP will use the data mLSP. 817 When the Source-PE and RP-PE are same (scenario 1 in section 6.3.1), 818 there is no Source-PE to RP-PE mLSP. 820 5.3. PIM register process 822 PIM register process is between multicast source and RP. Depending 823 on the PR location, we can have different scenarios. 825 5.3.1. Scenario 1: The multicast source and RP are behind the same PE 827 For this scenario, both RP and the multicast source are behind the 828 same PE for the same MVPN. In another words, the unicast path from 829 the multicast source to the multicast RP for a particular MVPN does 830 not need to go through one PE to another PE and cross the MPLS 831 network. So, the RP-PE is also the Source-PE. The PIM register 832 process does not cross different PEs in the core MPLS network. Both 833 RP-PE and source-PE are not aware of the PIM register process. There 834 is no particular design consideration for MPLS tunnels. 836 Before PIM register process, the PIM (*,G) join message from 837 different Receiver-PE MUST be forwarded to the RP-PE. As a result, 838 the PIM (*,G) state MUST be created on both RP-PE and Receiver-PE. 839 The state (*,G) at RP-PE has the MI-PMSI(MVPN_ID) as its OIF, and the 840 state (*,G) at Receiver-PE has the MI-PMSI(MVPN_ID) as its IIF. 842 After the PIM register process is finished, PIM state on RP-PE will 843 be changed to (S,G) which inherits all OIF from its parent (*,G). 844 There is no change for PIM state for (*,G) at Receiver-PE. The 845 multicast traffic will be flooded to all Receiver-PE through the RP- 846 mLSP, or default mLSP. the Receiver-PE SHOULD drop the traffic if it 847 does not have the (*,G) state created before. 849 5.3.2. Scenario 2: The multicast source and RP are behind the different 850 PE 852 For this scenario, RP and the multicast source are behind the 853 different PEs for the same MVPN. The unicast path from the multicast 854 source to the multicast RP MUST go through source-PE to RP-PE and 855 cross the MPLS network. 857 After the PIM(*,G) join is forwarded to the RP-PE through the default 858 mLSP from different Receiver-PE, Only the RP-PE and receiver-PE have 859 the state (*,G) created. The state at RP-PE has the default mLSP as 860 its OIF, and the interface connecting to a CE as the IIF, which CE is 861 the nexthop to reach RP from the RP-PE. The state at receiver-PE has 862 the default mLSP as IIF. 864 At Source-PE, there is no forwarding state. Multicast source S MUST 865 start the register process by sending data packet to RP. The PIM 866 register message is IP unicast message (encapsulated multicast data) 867 which destination is to RP from source S, it SHOULD go through a 868 unicast MPLS tunnel from Source-PE to RP-PE. The creation of unicast 869 MPLS tunnel is out of scope of this document. 871 When RP-PE receives register message which is encapsulated in MPLS 872 format, following things SHOULD happen: 874 o RP-PE MUST de-capsulate the MPLS packet and forward the PIM 875 register message to RP behind the RP-PE. RP then MUST forward the 876 multicast packet (de-capsulated from PIM register message) to all 877 Receiver-PE. This is done through the (*,G) state created before 878 PIM register process. The traffic from RP will be forwarded back 879 to RP-PE from the interface connecting to CE, and then RP-PE will 880 forward the traffic to RP-mLSP, or the default mLSP. 882 o All PEs attached to the default mLSP SHOULD receive the traffic. 883 Source-PE and receiver-PE which did not join the group G SHOULD 884 drop the traffic. 886 o RP initialize a PIM (S,G) join to source S. S address is retrieved 887 from the received data traffic from PIM register message. The 888 (S,G) join message MUST be forwarded from RP to RP-PE, and then 889 RP-PE MUST forward the join through the default mLSP to the 890 Source-PE. The address of Source-PE is determined by the BGP next 891 hop of the VPN address S. 893 o The Source-PE and RP-PE MUST create a PIM (S,G) state as a result 894 of PIM (S,G) join message processing, PIM (S,G) state at Source-PE 895 MUST have the MI-PMSI(MVPN_ID) as OIF, PIM (S,G) state at RP-PE 896 MUST inherit all OIF from the previous (*,G) state, and adds the 897 MI-PMSI(MVPN_ID) as IIF. Note, the OIF for old (*,G) state has 898 had the MI-PMSI(MVPN_ID) as OIF, this OIF MUST NOT be inherited 899 for (S,G). 901 o At Source-PE, the multicast traffic received from a multicast 902 source behind Source-PE, MUST be forwarded through the source-PE 903 to RP-PE mLSP represented by the OIF of MI-PMSI(MVPN_ID). The 904 "source-PE to RP-PE mLSP" is the default mLSP. Meanwhile, 905 multicast source S still embeds the traffic as the PIM register 906 message and send it to RP through the unicast MPLS tunnel. 908 o After the RP-PE receives the traffic from the source-PE to RP-PE 909 mLSP (default mLSP) during the PIM register process, following 910 events SHOULD happen 912 1. RP-PE SHOULD forward the traffic to RP. 914 2. After RP receives the native multicast traffic from the 915 interface which was used to forward the PIM (S,G) join message 916 to multicast source S, RP SHOULD stop de-capsulating the PIM 917 register message. All received PIM register message will be 918 discarded. 920 3. RP Sends a PIM register-stop (unicast) message to multicast 921 source S. 923 o After the multicast source receives register-stop message, it MUST 924 stop to send PIM register message to RP, and all multicast data is 925 natively forwarded by the (S,G) state to flood to the source-PE to 926 RP-PE mLSP, or the default mLSP. 928 5.4. SPT switching 930 After Receiver-PE receive multicast traffic from the default mLSP. 931 Each Receiver-PE SHOULD forward the traffic to some attached CEs by 932 the PIM state (*,G) created when the PIM (*,G) join was received from 933 the attached CEs. 935 After the traffic reaches the Last Hop Router (LHR), LHR can 936 initialize the Shortest Path Tree (SPT) switching by checking the 937 traffic rate. If the rate exceeds the pre-configured threshold, LHR 938 SHOULD send the PIM (S,G) join to the multicast source. 940 With the above solution for SPT switching, the Receiver-PE MUST still 941 forward the PIM (S,G) join to the default mLSP. And the PIM (S,G) 942 state SHOULD be created at the Receiver-PE and the state SHOULD 943 inherit all Olist from the previously created (*,G) state. 945 As a result of this SPT switching solution, only Receiver-PE has the 946 PIM state change. The traffic will be forwarded by (S,G) instead of 947 (*,G). Source-PE has no change to the PIM state (S,G). There is no 948 MPLS LSP changes for the traffic forwarding path in MPLS core 949 network. The traffic is still forwarded to the default mLSP at 950 source-PE. 952 5.5. RPT prune 954 Using the above method, the SPT switching does not lead to the 955 traffic receiving interface change on the receiver PE, so, there is 956 no RPT prune message triggered. 958 5.6. Data mLSP switching 960 As described in above section, the SPT switching does not change the 961 MPLS path for multicast forwarding. Some receiver-PEs still receive 962 the traffic even there is no intention to join the specific group G. 963 We will use data mLSP switching to serve the similar purpose for MPLS 964 network as SPT switching in IP network. By data mLSP switching, the 965 multicast forwarding path in MPLS network can be changed from a 966 shared tree (default mLSP) to a 968 o Shortest MPLS path from receiver to source, if the explicit path 969 is not configured for the source S, and the QoS is not required. 971 o User defined path, if the explicit path is configured for the 972 source S, or the QoS reservation is required. 974 If the traffic rate for the stream (S,G) exceeds the threshold, the 975 Source-PE MUST flood the mLSP join TLV to all PEs. Each PE, if it 976 has already created the PIM state for group G, MUST initialize a 977 mRSVP-TE P2MP path message to the Source-PE. The Source-PE is found 978 by the BGP next hop address for S. 980 The Receiver-PE MUST update its IIF for state (S,G) from MI- 981 PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). 983 After the data mLSP is constructed at Source-PE, the PIM state (S,G) 984 MUST add S-PMSI(MVPN_ID, mLSP_ID) to its Olist and prune the old OIF 985 MI-PMSI(MVPN_ID). Note, at this moment, the traffic is still sent to 986 the default mLSP from the Source-PE. 988 As a result of OIF updating for (S,G) at Source-PE, the traffic is 989 switched from the default mLSP to the data mLSP for (S,G). 991 5.7. PIM state at Receiver-PE 993 PIM state at Receiver-PE may be different due to the rate threshold 994 configuration of SPT switching and data mLSP switching. 996 o If the rate threshold for mLSP data switching is less than the 997 rate threshold for SPT switching, the data mLSP will be switched 998 earlier than the SPT switching in IP. The multicast distribution 999 tree in MPLS could be switched to a shortest path tree but the 1000 tree in IP network is still a shared tree. As a result, the 1001 traffic is carried by a P2MP tunnel in MPLS network. But at the 1002 receiver-PE, the de-capsulated MPLS traffic MUST be still 1003 forwarded by a PIM state (*,G) which is corresponding to a shared 1004 tree. 1006 o If the rate threshold for mLSP data switching is greater than the 1007 rate threshold for SPT switching, the data mLSP will be switched 1008 later than the SPT switching in IP. The tree in IP network is 1009 switched to a shortest path tree but the multicast distribution 1010 tree in MPLS is still a default mLSP. So, the traffic is carried 1011 by a MP2MP tunnel in MPLS network, and at the receiver-PE, the de- 1012 capsulated MPLS traffic will be forwarded by a PIM state (S,G) 1013 which is corresponding to a shortest path tree. 1015 6. Aggregation 1017 With the method described above, there is one data mLSP per multicast 1018 stream (S,G). This may not be feasible if the stream number is big, 1019 or, there is limit for MPLS label for multicast in a network. Under 1020 those scenarios, traffic aggregation in MPLS network is desired. 1022 Aggregation can save the MPLS tunnel, but always with trade off. 1023 When multiple MPLS multicast trees are not completely overlapped, to 1024 aggregate them will lead to some sub-LSP waste the bandwidth. For 1025 example, if two trees have different set of receiver-PEs, some 1026 traffic has to be dropped on a PE if it does not have the (S,G) state 1027 created before. 1029 6.1. Aggregation by Default mLSP 1031 The aggregation by the default mLSP is straightforward. If we do not 1032 set the data mLSP for any (S,G), the traffic of (S,G) will be kept in 1033 the default mLSP forever. The aggregation for selective (S,G) can be 1034 done at CLI level by ACL (Access List) or any other kind of tool to 1035 make the streams which satisfy some conditions to stay in the default 1036 mLSP. 1038 6.2. Aggregation by Data mLSP 1040 The aggregation by the data mLSP can be achieved by the following 1041 ways 1043 o Source-PE assigns the same mLSP ID for the streams expected to be 1044 aggregated, and keeps the mapping for the mLSP ID to different 1045 (S,G). 1047 o Source-PE floods the mLSP join TLV for each (S,G) with the same 1048 mLSP ID to default mLSP. 1050 o Receiver-PE receives the mLSP join TLV and checks if the data mLSP 1051 corresponding to the mLSP ID is created already. If yes, 1052 receiver-PE SHOULD only update its mapping for the mLSP ID to an 1053 new (S,G) but SHOULD NOT initialize the new path message to 1054 source-PE. 1056 o Source-PE SHOULD switch multiple streams which were assigned with 1057 the same mLSP ID to the same data mLSP after it is created. 1059 The aggregation by data mLSP essentially aggregates multicast streams 1060 which share the same source-PE even they have different multicast 1061 source. 1063 7. Non-VPN multicast support 1065 The method specified in this document can also apply to the non-VPN 1066 multicast support. 1068 For the non-VPN multicast case, we will take the same approach as VPN 1069 multicast case. Basically, we will treat the public table with a 1070 special VPN ID = 0 (see section 9 for VPN ID). By such treatment, 1071 the multicast in public domain becomes the multicast in a special 1072 table, and it can be supported as normal mVPN. 1074 8. Message Format and Constants 1076 Two types of new message format have to be introduced to support mVPN 1077 by mRSVP-TE. One is the SESSION-object message format for mRSVP-TE. 1078 Another is the mLSP join TLV message format. 1080 The SESSION-object defined in mRSVP-TE is a opaque value (Fig. 7 in 1081 [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]). So, we can define 1082 the details of the opaque value based on the mVPN requirement. For 1083 the PIM-SSM support option 1 (Fig. 1, Fig. 2), we can embed the 1084 "c-source" and "c-group" directly into the SESSION-object. But for 1085 PIM-SM support, and PIM-SSM support option 2/3, we can embed the 1086 "mLSP ID" into the SESSION-object (Fig. 3). "mLSP ID" can map to 1087 different "c-source" and "c-group" at PEs. 1089 The mLSP join TLV message format is similar to the MDT defined in 1090 section 7.2 and 7.3 [RFC6037]. Both use UDP to encapsulate the join 1091 TLV message, and the IP destination address are also same, it is ALL- 1092 PIM-ROUTERS (224.0.0.13) for IPv4 and ALL-PIM-ROUTERS (ff02::d) for 1093 IPv6. But there are some difference for MDT and mLSP. The 1st 1094 difference is that we have to use a value (mLSP ID) other than "P 1095 Group" for MPLS case since we do not have "P Group" for MPLS core 1096 network. The 2nd difference is that we have to use different port 1097 number instead of 3232 assigned to mGRE based MDT. The exact UDP 1098 port number is TBD. 1100 8.1. Path session object for PIM-SSM option 1 (IPv4) 1102 The MVPN mRSVP path message for PIM-SSM option 1 for IPv4 has the 1103 following format. 1105 Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | | 1110 + VPN ID + 1111 | | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | C-source | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | C-group | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 Fig. 1 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv4) 1120 VPN ID: 1121 This is the ID for MVPN, it MUST be same for the same VPN cross 1122 a MPLS network. VRF RD (Route Distinguisher) or any other 1123 unique value in a MPLS network can be used for VPN ID. 0 is 1124 reserved for the global MPLS multicast or non MVPN case 1126 C-source (32 bits): 1127 the IPv4 address of the traffic source in the VPN. 1129 C-group (32 bits): 1130 the IPv4 address of the multicast traffic destination address 1131 in the VPN. 1133 8.2. Path session object for PIM-SSM option 1 (IPv6) 1135 The MVPN mRSVP path message for PIM-SSM option 1 for IPv6 has the 1136 following format. 1138 Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD 1139 0 1 2 3 1140 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 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | | 1143 + VPN ID + 1144 | | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | | 1147 | C-source | 1148 | | 1149 | | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | | 1152 | C-group | 1153 | | 1154 | | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Fig. 2 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv6) 1159 VPN ID: 1160 Same definition as in Fig. 1 1162 C-source (128 bits): 1163 the IPv6 address of the traffic source in the VPN. 1165 C-group (128 bits): 1166 the IPv6 address of the multicast traffic destination address 1167 in the VPN. 1169 8.3. Path session object for other PIM modes (IPv4) 1171 The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3) 1172 for IPv4 has the following format. 1174 Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | | 1179 + VPN ID + 1180 | | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | mLSP ID | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 Fig. 3 mVPN mRSVP-TE path session object for PIM-SM, PIM-SSM (Option 1186 2 and 3) 1188 VPN ID: 1189 Same definition as in Fig. 1 1191 mLSP ID: 1192 the mLSP ID corresponding to a tunnel, 0 is reserved for 1193 default mLSP. For all non-zero mLSP ID, it SHOULD come from 1194 the mLSP join TLV message, see Fig. 4 and Fig. 5 1196 8.4. Path session object for other PIM modes (IPv6) 1198 The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3) 1199 for IPv6 has the following format. 1201 Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD 1203 The session object format is the same as for IPv4 shown in Fig 3. 1205 8.5. mLSP TLV Message format for IPv4 1207 The mLSP Join TLV for IPv4 streams has the following format. 1209 0 1 2 3 1210 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 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Type | Length | Reserved | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | C-source | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | C-group | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | mLSP ID | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 Fig. 4 mLSP join TLV message format for IPv4 1222 Type (8 bits): 1223 MUST be set to 1. 1225 Length (16 bits): 1226 MUST be set to 16. 1228 Reserved (8 bits): 1229 for future use. 1231 C-source (32 bits): 1232 the IPv4 address of the traffic source in the VPN. 1234 C-group (32 bits): 1235 the IPv4 address of the multicast traffic destination address 1236 in the VPN. 1238 mLSP ID (32 bits): 1239 the mLSP ID corresponding to the data mLSP carrying the flow 1240 (C-source, C-group). 1242 8.6. mLSP TLV Message format for IPv6 1244 The mLSP Join TLV for IPv6 streams has the following format. 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Type | Length | Reserved | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | | 1252 | C-source | 1253 | | 1254 | | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | | 1257 | C-group | 1258 | | 1259 | | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | mLSP ID | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 Fig. 5 mLSP join TLV message format for IPv6 1266 Type (8 bits): 1267 MUST be set to 4. 1269 Length (16 bits): 1270 MUST be set to 40. 1272 Reserved (8 bits): 1273 for future use. 1275 C-source (128 bits): 1276 the IPv6 address of the traffic source in the VPN. 1278 C-group (128 bits): 1279 the IPv6 address of the multicast traffic destination address 1280 in the VPN. 1282 mLSP ID (32 bits): 1283 the mLSP ID corresponding to the data mLSP carrying the flow 1284 (C-source, C-group). 1286 9. Acknowledgements 1288 We would like to thank Katherine Zhao and Quintin Zhao for comments 1289 on early drafts of this work. 1291 10. IANA Considerations 1293 There is no change with regards to IANA 1295 11. Security Considerations 1297 There is no change with regards to the security for PIM protocol and 1298 mRSVP-TE after the MVPN is provided 1300 12. References 1302 12.1. Normative References 1304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1305 Requirement Levels", BCP 14, RFC 2119, March 1997. 1307 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1308 "Extensions to Resource Reservation Protocol - Traffic 1309 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1310 Switched Paths (LSPs)", RFC 4875, May 2007. 1312 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1313 "Label Distribution Protocol Extensions for Point-to- 1314 Multipoint and Multipoint-to-Multipoint Label Switched 1315 Paths", RFC 6388, November 2011. 1317 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1318 VPNs", RFC 6513, February 2012. 1320 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1321 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1322 Protocol Specification (Revised)", RFC 4601, August 2006. 1324 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 1325 "Bootstrap Router (BSR) Mechanism for Protocol Independent 1326 Multicast (PIM)", RFC 5059, January 2008. 1328 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1329 Encodings and Procedures for Multicast in MPLS/BGP IP 1330 VPNs", RFC 6514, February 2012. 1332 [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te] 1333 Li, R., Zhao, Q., and C. Jacquenet, "Receiver-Driven 1334 Multicast Traffic-Engineered Label-Switched Paths", 1335 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-01 (work 1336 in progress), July 2012. 1338 12.2. Informative References 1340 [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' 1341 Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, 1342 October 2010. 1344 Authors' Addresses 1346 Lin Han (editor) 1347 Huawei Technologies 1348 2330 Central Expressway 1349 Santa Clara, CA 95050 1350 USA 1352 Phone: +10 408 330 4613 1353 Email: lin.han@huawei.com 1354 Renwei Li 1355 Huawei Technologies 1356 2330 Central Expressway 1357 Santa Clara, CA 95050 1358 USA 1360 Phone: 1361 Email: renwei.li@huawei.com