idnits 2.17.1 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (October 23, 2012) is 4202 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) == Missing Reference: 'TBD' is mentioned on line 1200, but not defined == Unused Reference: 'RFC2119' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 1257, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1265, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 1272, but no explicit reference was found in the text == Unused Reference: 'RFC4420' is defined on line 1281, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1299, but no explicit reference was found in the text == Unused Reference: 'RFC3468' is defined on line 1309, but no explicit reference was found in the text == Unused Reference: 'RFC3564' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'RFC5467' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 1325, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 1328, but no explicit reference was found in the text == Unused Reference: 'RFC6517' is defined on line 1332, but no explicit reference was found in the text == Unused Reference: 'I-D.jacquenet-mpls-rd-p2mp-te-requirements' is defined on line 1348, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Downref: Normative reference to an Informational RFC: RFC 2209 ** Downref: Normative reference to an Informational RFC: RFC 4461 ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) == Outdated reference: A later version (-02) exists of draft-zlj-mpls-mrsvp-te-frr-00 == Outdated reference: A later version (-02) exists of draft-tao-mpls-pim-interworking-00 == Outdated reference: A later version (-03) exists of draft-jacquenet-mpls-rd-p2mp-te-requirements-02 Summary: 6 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Li 3 Internet-Draft Q. Zhao 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 26, 2013 C. Jacquenet 6 France Telecom Orange 7 R. Tao 8 Huawei Technologies 9 B. Zhang 10 Telus Communications 11 October 23, 2012 13 Receiver-Driven Multicast Traffic-Engineered Label-Switched Paths 14 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-02.txt 16 Abstract 18 This document describes the receiver-driven RSVP-TE P2MP LSP 19 signaling protocol (mRSVP-TE) which is an extension to the Resource 20 Reservation Protocol - Traffic Engineering (RSVP-TE) for the 21 computation and establishment of Receiver-Driven Traffic-Engineered 22 point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label 23 Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and 24 Generalized MPLS (GMPLS) networks. The document also describes the 25 mRSVP-TE extensions and procedures for the interworking between 26 mRSVP-TE and the Protocol Independent Multicast (PIM) protocol. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 26, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1.1. mRSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1.2. The Need For PIM and mRSVP-TE Interworking . . . . . . 5 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 79 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 2. Receiver-Driven mRSVP-TE LSP Examples . . . . . . . . . . . . 9 81 2.1. RD P2MP LSP Example . . . . . . . . . . . . . . . . . . . 9 82 2.2. RD MP2MP LSP Example . . . . . . . . . . . . . . . . . . . 11 83 3. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 12 84 3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.1.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.1.2. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . 13 87 3.1.3. Path Originator and Data Receiver . . . . . . . . . . 14 88 3.1.4. Explicit Routing . . . . . . . . . . . . . . . . . . . 14 89 3.2. PIM-mRSVP TE Interworking Operation . . . . . . . . . . . 15 90 3.2.1. New M-Flow Spec Types . . . . . . . . . . . . . . . . 15 91 3.2.2. Signaling An Unidentified Sub-LSP . . . . . . . . . . 16 92 3.3. Path Messages . . . . . . . . . . . . . . . . . . . . . . 17 93 3.4. Resv Messages . . . . . . . . . . . . . . . . . . . . . . 18 94 3.5. PathErr Messages . . . . . . . . . . . . . . . . . . . . . 19 95 3.6. ResvErr Message . . . . . . . . . . . . . . . . . . . . . 19 96 3.7. PathTear Messages . . . . . . . . . . . . . . . . . . . . 19 97 4. New and Updated Objects . . . . . . . . . . . . . . . . . . . 19 98 4.1. SESSION Object . . . . . . . . . . . . . . . . . . . . . . 19 99 4.1.1. mRSVP-TE IPv4 LSP Tunnel SESSION Object . . . . . . . 20 100 4.1.2. mRSVP-TE IPv6 LSP Tunnel SESSION Object . . . . . . . 21 101 4.2. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 21 102 4.2.1. mRSVP-TE LSP IPv4 Tunnel SENDER_TEMPLATE Object . . . 21 103 4.2.2. SENDER_TEMPLATE Objects . . . . . . . . . . . . . . . 22 104 4.3. L2S_SUB_LSP Objects . . . . . . . . . . . . . . . . . . . 23 105 4.3.1. L2S_SUB_LSP IPv4 Objects . . . . . . . . . . . . . . . 23 106 4.3.2. L2S_SUB_LSP IPv6 Objects . . . . . . . . . . . . . . . 24 107 4.4. FILTER_SPEC Objects . . . . . . . . . . . . . . . . . . . 24 108 4.4.1. mRSVP-TE LSP_IPv4 FILTER_SPEC Objects . . . . . . . . 24 109 4.4.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Objects . . . . . . . . 24 110 4.5. MFLOW Object . . . . . . . . . . . . . . . . . . . . . . . 24 111 5. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 27 112 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 28 113 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 118 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 121 1. Introduction 123 The dramatic growth of multicast-based IP services such as live TV 124 broadcasting raises new challenges for network operators. The sole 125 use of IP multicast becomes challenging, given the QoS-demanding 126 nature of the applications. The specification of traffic-engineered, 127 MPLS-based, Point-to-Multi-Point (P2MP) tree structures ([RFC4875] is 128 meant to address both quality and robustness issues, but failed to be 129 massively adopted and deployed so far, mostly because the current 130 standard assumes a priori knowledge of all the routers involved in 131 the establishment and the maintenance of the tree structure, at the 132 cost of extra management complexity. 134 However, it is possible and intuitively more efficient to start the 135 signaling of a LSP as soon as a receiver notifies interest about a 136 multicast content. Thus, the signaling path relies upon a receiver- 137 initiated paradigm, all the way from the receiver to the source. 138 This means that the information conveyed in IGMP/MLD Report messages 139 sent by the receiver towards the IGMP/MLD Querier which is often 140 embedded in the PIM Designated Router that is located as close to the 141 receiver as possible and typically at the edge of the PIM network 142 will be used to compute the receiver-initiated, PIM-derived signaled, 143 P2MP MPLS LSP. 145 This document extends RSVP-TE for the dynamic computation of 146 receiver- driven P2MP and MP2MP LSP tree structures. It also 147 specifies the mRSVP-TE extenstions and procedures for the 148 interworking between mRSVP-TE and the Protocol Independent Multicast 149 PIM protocol [RFC4601]. 151 1.1. Motivation 153 1.1.1. mRSVP-TE 155 IP multicast distribution trees are receiver-initiated and dynamic by 156 nature. IP multicast-enabled applications are also bandwidth savvy, 157 especially in the area of residential IPTV services, where the 158 delivery of multicast contents to several hundreds of thousands of 159 IPTV receivers assumes the appropriate level of quality. 161 Current source-driven P2MP LSP establishment, as defined as in 162 [RFC4875], assumes a priori knowledge of receiver locations. 163 Typically, the LSP signaling is initiated by the MPLS router 164 connected to the source (headend) in such environments. The a priori 165 knowledge of receiver locations is obtained either through static 166 configuration or by using another protocol to discover the receivers 167 and their Join/Prune states for each data stream. On the other hand, 168 there is no straightforward way to support MP2MP applications by 169 using P2MP LSP unless full-meshed P2MP LSPs are set up. 171 The receiver-driven extension to RSVP-TE defined in this document 172 will support both P2MP LSPs and MP2MP LSPs. Moreover, it does not 173 require the root router to know all the receivers' locations a 174 priori. A protocol for receiver discovery is therefore not needed. 176 1.1.2. The Need For PIM and mRSVP-TE Interworking 178 Service providers use IP multicast for the delivery of live TV 179 broadcasting services. IP multicast traffic is generally forwarded 180 over core MPLS infrastructures, along PIM- computed multicast 181 distribution trees. 183 For the sake of overall service performance, scalability and 184 robustness, it is recognized that the PIM machinery should be 185 restricted to the edge of the MPLS network, while IP multicast 186 traffic is forwarded along P2MP MPLS LSP paths in the MPLS core 187 network. Such a design assumes that: 189 o PIM multicast trees are dynamically computed and established at 190 PIM edge(s), and 192 o MPLS P2MP LSPs are dynamically computed and established according 193 to the information conveyed in PIM signaling messages. 195 Subsequently, IP multicast traffic is forwarded along a PIM multicast 196 tree from a source connected somewhere at the edge of the MPLS 197 network, then forwarded along the corresponding Receiver-Driven P2MP 198 LSP within the MPLS network so that it ultimately reaches receivers 199 through PIM Designated Routers connected somewhere at the edge of the 200 MPLS network. 202 The purpose of such design that combine the dynamics of PIM signaling 203 with the robustness of traffic-engineered P2MP MPLS tree structures 204 is to encourage PIM-free core infrastructures for the sake of 205 operational simplification and performance optimization. 207 In this document we describe PIM/mRSVP-TE interworking procedures 208 derived from the framework documented in 209 [I-D.tao-mpls-pim-interworking]]. [I-D.tao-mpls-pim-interworking]] 210 defines a framework for interworking procedures between PIM and an 211 MPLS P2MP LSP signaling protocol to accommodate all PIM operations 212 with an MPLS network in an optimal and scalable manner, thereby 213 avoiding the need for a third protocol to dynamically discover and 214 propagate PIM multicast states across the MPLS network. 216 The general interworking mechanisms and procedures are those defined 217 in [I-D.tao-mpls-pim-interworking] and MUST be implemented as part of 218 the interworking solution. Therefore, this document only describes 219 the mRSVP-TE-specific procedures to be implemented. 221 1.2. Terminology 223 The following terms are used in this document: 225 o Sender: Sender refers to the Originator (and hence the Sender) of 226 the content/payload, as defined in [RFC2205]. 228 o Receiver: Receiver refers to the Receiver of the content/payload, 229 as defined in [RFC2205]. 231 o Upstream: The direction of flow from content Receiver toward 232 content Sender, as defined in [RFC2205]. 234 o Downstream: The direction of flow from content Sender toward 235 content Receiver, as defined in [RFC2205]. 237 o Path-Sender: The sender of RSVP PATH messages, with no correlation 238 to the direction of multicast content flows. Its flow direction 239 is irrelevant to that of the Sender, as defined above. 241 o Path-Receiver: The receiver of RSVP PATH messages, with no 242 correlation to the direction of multicast content flows. 244 o Path-Initiator: The Path-Sender that originated a RSVP PATH 245 message. A Path-Initiator is different from a Path-Sender in that 246 an intermediate node can be a Path-Sender, but such an 247 intermediate node cannot create and initiate RSVP PATH messages. 248 A Path-Initator is a Path-Sender, but a Path-Sender doesn't have 249 to be a Path-Initiator. 251 o Path-Terminator: The Path-Receiver that does NOT propagate the 252 Path message any further. A Path-Terminator is different from a 253 Path-Receiver in that an intermediate node can be a Path-Receiver, 254 but such an intermediate node will propagate the Path message to 255 the next hop. 257 o Root: A router where a RD P2MP LSP is rooted at. Multicast 258 content data enter are forwarded along the RD P2MP LSP from the 259 root to the leaves. 261 o mPMBR: MPLS-PIM Multicast Border Router where MPLS-PIM 262 interworking takes place. 264 o Leaf or Leaf mPMBR: In the context of a RD P2MP LSP, it is the 265 mPMBR acting as a leaf for the said LSP. 267 o Root or Root mPMBR: In the context of a RD P2MP LSP, it is the 268 mPMBR acting as the root of the said LSP. 270 o M-Flow Spec: The Multicast Flow Spec (from a mRSVP TE standpoint) 271 that corresponds to a PIM forwarding rule 273 1.3. Overview 275 Although the receiver-driven extensions to RSVP-TE as defined in this 276 document use the existing sender-driven syntax, there are important 277 semantic differences that need to be defined for correct 278 interpretation and interoperability purposes. In the receiver-driven 279 context, some semantics of RSVP-TE messages are inverted, but the 280 syntax remains unchanged as much as possible. 282 In this document, mRSVP-TE denotes the use of the receiver-driven 283 multicast extensions to RSVP-TE. 285 The following are some key differences that are specific to the 286 receiver-driven paradigm: 288 o The leaf router: The router that receives multicast contents which 289 will be eventually delivered to the receiver. In this document, 290 the leaf router will initiate PATH messages. 292 o L2S (Leaf-To-Source) Destinations: Routers where multicast content 293 data enter the RD P2MP LSP. 295 o RSVP P2MP PATH messages are sent by leaf routers of the RD P2MP 296 LSP towards the root of the said LSP. 298 o RSVP P2MP RESV messages are sent by the root towards the leaf 299 routers of the RD P2MP tree structure. 301 o A RSVP RESV message received by a router is interpreted as a 302 successful resource reservation made by the upstream node for the 303 establishment of the RD P2MP tree structure. 305 o A RSVP RESV message received by a router is interpreted as 306 successful resource reservation made by the downstream node for 307 the establishment of an RD MP2MP tree structure. 309 o Label allocation on incoming interfaces is done prior to sending 310 RSVP PATH messages upstream for RD P2MP tree structures. 312 o Label allocation on incoming interfaces is done prior to sending 313 RSVP RESV messages upstream for RD MP2MP tree structures. 315 o For RD P2MP LSP tree structures, a node receiving a RSVP PATH 316 message first decides if this RSVP PATH message will make the said 317 node a branch LSR or not. If it is not a branch LSR, it is a 318 transit LSR. In the case that it will become a transit LSR 319 because of this PATH message, it will, before sending the RSVP 320 PATH message upstream, allocate the requested bandwidth as 321 signaled in the RSVP PATH message on the interface on which the 322 RSVP PATH message is received. The upstream node can send traffic 323 soon after successfully reserving resources on the downstream 324 link, on which the RSVP PATH message SHOULD be received. In the 325 case that the node is already a branch or a transit node for a 326 given multicast group before it receives the PATH message, it will 327 then allocate the requested bandwidth on the interface on which 328 the RSVP PATH message is received, and send the RESV message to 329 the node which sends the PATH message without propagating the PATH 330 message further to the upstream node. For RD P2MP LSPs, a label 331 is carried by the PATH message and should be used by the upstream 332 node to forward multicast content downstream. 334 o For RD MP2MP LSP tree structures, a node will allocate the 335 requested bandwidth on the interface through which the RSVP PATH 336 message is sent before sending the RSVP PATH message upstream. A 337 node receiving a RSVP PATH message MUST first decide if this RSVP 338 PATH message will make the said node a branch LSR or not. In the 339 case it will become a transit LSR because of this PATH message, it 340 will then allocate the requested bandwidth on the interface on 341 which the RSVP PATH message is received as well as on the 342 interface through which the RSVP PATH message is sent, before 343 sending the RSVP PATH message upstream. The downstream node can 344 send traffic soon after successfully reserving bandwidth on the 345 upstream link through which the RSVP PATH message SHOULD be sent. 346 The upstream node can send traffic soon after successfully 347 reserving bandwidth on the downstream link on which the RSVP PATH 348 message SHOULD be received. In the case that the node is already 349 a branch or a transit node for a given multicast group before it 350 receives the PATH message, it will then allocate the requested 351 resources on the interface on which the RSVP PATH message is 352 received, and send back the RESV message to the node that sent the 353 PATH message without propagating the PATH message further to the 354 upstream node. The label carried by the PATH message should be 355 used by the Path-Receiver node to forward data from the Path- 356 Receiver node to the Path-Sender node, and the label carried by 357 RESV messages should be used by its corresponding Path-Sender node 358 to send data from the Path-Sender node to the Path-Receiver node. 360 2. Receiver-Driven mRSVP-TE LSP Examples 362 This section illustrates by two examples how RD P2MP and RD MP2MP LSP 363 paths are set up, respectively. In both examples, RSVP PATH messages 364 are initiated by the leaf routers of the LSP. 366 For the RD P2MP example, a RSVP PATH message carries a label for 367 sending multicast data downstream. And for the RD MP2MP example, 368 both RSVP PATH and RESV messages carry a label for sending data 369 downstream and upstream. 371 2.1. RD P2MP LSP Example 373 Sender/Source/Path Terminator/Ingress Router 374 +---------+ 375 | R1 | 376 +-----+---+ 377 _ 378 \ \ /\ 379 \ \ \ Path Message w/ Label OBJECT 380 Resv \ \ \ (msg2) 381 Message \ \ \ 382 (msg3) \ \ \ 383 _\/ \ \ 384 +----------------+ Path Remerge 385 | R3 | Creates Branch Point 386 +----------------+ 387 _ _ 388 / / /\ \ \ /\ 389 / / / \ \ \ Path Message (msg1) 390 Resv Message / / / msg4 \ \ \ w/ Label OBJECT 391 (msg6) / / / \ \ \ 392 / / /Path Msg \ \ \ 393 / / / (msg5) \ \ \ 394 \/_ / / w/Label OBJ _\/ \ \ 395 +----------+ +---+-----+ 396 | R4 | | R5 | 397 +----------+ +---------+ 398 Path Initiator Path Initiator 399 Originator ID = R4 Originator ID = R5 400 L2S Destination = R1 L2S Destination = R1 401 Session = S Session = S 403 Figure 1: RD P2MP LSP Example 405 In Figure 1, when R5 is added as the first leaf of a mulitcast 406 distribution tree (multicast LSP), the message flow goes as follows: 407 R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. 409 When the leaf R4 is added, the message flow goes from 410 R4->msg5->R3->msg6->R4. In this case, when R3 receives msg5, R3 411 finds out that a RD P2MP LSP has already been set up for the same 412 multicast group (and the same source). Therefore, R3 is a branch 413 node for leaves R4 and R5, and R3 will therefore be the last router 414 to receive and process the PATH message. R3 will then build the 415 corresponding RESV message and send it back to R4. 417 The association of the LSP initiated by R4 to the existing RD P2MP 418 LSP is determined based upon the processing of the SESSION and 419 L2S_SUB_LSP objects conveyed in the mRSVP-TE messages. The SESSION 420 and the L2S_SUB_LSP objects are documented later in this draft. 422 2.2. RD MP2MP LSP Example 424 Root/Path Terminator/Ingress Router 425 +---------+ 426 | R1 | 427 +-----+---+ 428 _ 429 \ \ /\ 430 \ \ \ Path-mp2mp Message w/ Label OBJECT 431 Resv \ \ \ (msg2) 432 Message \ \ \ 433 (msg3) \ \ \ 434 w/ Label OBJECT _\/ \ \ 435 +----------------+ Path-mp2mp 436 | R3 | (Branch Point) 437 +----------------+ 438 _ _ 439 / / /\ \ \ /\ 440 / / / \ \ \ Path-mp2mp Message (msg1) 441 Resv Message / / / msg4 \ \ \ (msg1) 442 (msg6) / / / \ \ \ w/ Label OBJECT 443 w/ Label OBJECT/ / /Path-mp2mp \ \ \ 444 / / / Message \ \ \ 445 / / / (msg5) \ \ \ 446 \/_ / / w/ Label OBJ _\/ \ \ 447 +----------+ +---+-----+ 448 | R4 | | R5 | 449 +----------+ +---------+ 450 Path-mp2mp Initiator Path-mp2mp Initiator 451 Originator ID = R4 Originator ID = R5 452 L2S Destination = R1 L2S Destination = R1 453 Session = S Session = S 455 Figure 2: RD MP2MP LSP Example 457 In Figure 2, when R5 is added as the first leaf (acting as both a 458 sender and a receiver of multicast content) of a RD MP2MP LSP, the 459 message flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. 460 When the leaf R4 is added, the message flow goes from 461 R4->msg5->R3->msg6->R4. 463 In this case, when R3 receives msg5, R3 finds out that a RD MP2MP LSP 464 has already been set up for the same multicast group, and R3 465 therefore becomes a branch LSR for leaves R4 and R5. R3 will be the 466 last router to receive and process the corresponding PATH message, R3 467 will then build a RESV message accordingly, and send it back to R4. 469 The association of the LSP initiated by R4 to the existing RD MP2MP 470 LSP is determined based upon the processing of the SESSION and the 471 S2L_SUB_LSP objects conveyed in the mRSVP-TE messages. The SESSION 472 and the L2S_SUB_LSP objects are documented in this draft. 474 3. Signaling Protocol Extensions 476 The mRSVP-TE protocol is similar to RSVP-TE protocol as specified in 477 [RFC4875], [RFC3473], and [RFC3209]. The main difference is that the 478 leaf routers of a P2MP LSP initiate the RSVP PATH messages toward the 479 root of the said LSP. Unlike [RFC4875], mRSVP-TE can also be used to 480 set up RD MP2MP LSPs. 482 In the context of the mRSVP-TE, the leaf router is the Path- 483 Originator. The RSVP RESV messages flow in the opposite direction, 484 and are generated by the root or a branch LSR. RSVP PATH messages 485 are forwarded in the opposite direction of the multicast traffic. 487 A RSVP PATH message will be terminated at the root of the RD P2MP LSP 488 or at an intermediate node if this intermediate node has already 489 received another PATH message from another leaf router for the same 490 multicast group. When an intermediate node receives two or more PATH 491 messages for the same multicast group, the intermediate node will 492 merge them together. Whether two PATH messages should be merged 493 depends on the information encoded in the SESSION and L2S-SUB-LSP 494 objects. The SESSION object encodes multicast group information and 495 the L2S-SUB-LSP (leaf-to-source sub-LSP) object encodes the multicast 496 source or multicast root information. 498 The following sections describe the receiver-driven extensions to the 499 RSVP-TE protocol. When there is no difference in the protocol, the 500 usage of [RFC4875] is assumed. 502 3.1. Operation 504 3.1.1. Sessions 506 As specified in [RFC2205], a session is a data flow with a particular 507 destination and transport-layer protocol. In the context of 508 multicast, the data flow is essentially a multicast distribution tree 509 rooted at the RD P2MP LSP or RD MP2MP LSP sources. 511 For the sake of reliability, two or more sources/roots may be 512 deployed to distribute the same multicast streams identified by a 513 mulitcast group address (and possibly the address of the multicast 514 source, in typical SSM environments). In this document, the 515 mulitcast group address is encoded in the SESSION object and the 516 mulitcast source/root address in the Leaf-to-Source (L2S) sub-LSP 517 object. Note that the same session can have different sources/roots, 518 and the same sources/roots can have different sessions. 520 The processing of SESSION objects in mRSVP TE is different from that 521 of SESSION objects in RSVP-TE [RFC4875]. In order to uniquely 522 identify mRSVP TE SESSION objects, different C-Types of SESSION 523 objects are introduced. This draft documents SESSION objects for 524 native IPv4/IPv6 multicast applications. Additional SESSION object 525 types MAY be added in the future. 527 The new SESSION C-Types are described as follows: 529 Class Name = SESSION 530 C-Type 531 XX+0 mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type 532 XX+1 mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type 533 XX+2 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type 534 XX+3 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type 536 Where XX is a number to be allocated by IANA. 538 Figure 3: New SESSION C-Types 540 The new SESSION C-Type MUST be used in all mRSVP-TE messages. 542 3.1.2. L2S Sub-LSPs 544 A RD P2MP LSP is composed of one or more L2S sub-LSPs, which are 545 merged together at the branch nodes. There are two ways to identify 546 each L2S sub-LSP: 548 o From the Sender's perspective, each sub-LSP is identified by the 549 SESSION object, the SENDER_TEMPLATE object and S2L_SUB_LSP object, 550 as specified in [RFC4875]. The SESSION object encodes the P2MP 551 ID, Tunnel ID, and Extended Tunnel ID. The P2MP ID is unique 552 within the scope of the sender (ingress LSR) and remains constant 553 throughout the lifetime of the RD P2MP tree structure. The 554 Extended Tunnel ID, which remains constant throughout the lifetime 555 of the RD P2MP tree structure, contains the sender's address to 556 make sure the identifier is globally unique. Finally, the Tunnel 557 ID also remains constant throughout the lifetime of the RD P2MP 558 tree structure. The SENDER_TEMPLATE object contains the ingress 559 LSR source address. The S2L_SUB_LSP object contains the 560 destination address of the sub-LSP. 562 o From the Receiver's perspective, each sub-LSP is identified by a 563 new SESSION object, a new SENDER_TEMPLATE object and a new 564 L2S_SUB_LSP object. The SESSION object, different from the one 565 used in typical sender-driven environments, contains information 566 to be used as the key to associate different PATH messages 567 originated from different leaves. The SENDER_TEMPLATE object 568 contains the Path-Originator's address, which is actually the leaf 569 router of the corresponding RD P2MP LSP. The L2S_SUB_LSP object 570 contains the source or root address of the sub-LSP, i.e., the data 571 Sender's address. The SESSION, SENDER_TEMPLATE and L2S_SUB_LSP 572 objects all together will identify the multicast group address, 573 the multicast address source, and a mulitcast leaf router. 575 This document assumes the receiver-driven approach. 577 Once an LSR receives a receiver-driven PATH message that contains 578 both the SESSION and L2S_SUB_LSP objects, the LSR will use these 579 objects to determine whether the sub-LSP signaled by this PATH 580 message should be merged with an existing RD P2MP LSP. 582 3.1.3. Path Originator and Data Receiver 584 This draft documents a new type of SENDER_TEMPLATE object, which 585 contains the Path-Originator's IP address and describes the identity 586 of the Path Originator. 588 In [RFC2205] and [RFC4875], the sender is a Path Originator that also 589 forwards multicast data. In the receiver-driven context, Path 590 Originators and data senders may be different. For RD P2MP LSPs, 591 Path Originators are actually the leaf routers. For RD MP2MP LSPs, 592 Path Originators are also both the data senders and leaf routers. 594 In this document, the same Object Class SENDER_TEMPLATE with a 595 different C-Type is used to represent and identify a Path Originator. 596 In the case of RD P2MP LSPs, the SENDER_TEMPLATE object describes the 597 identify of a leaf router. In the case of RD MP2MP LSPs, the 598 SENDER_TEMPLATE object describes the identify of an LSR that behaves 599 as both a data sender and a data receiver. 601 All the SESSION, L2S_SUB_LSP and SENDER_TEMPLATE objects together 602 contained in a RSVP PATH message will uniquely identify a L2S sub- 603 LSP. 605 3.1.4. Explicit Routing 607 An EXPLICIT_ROUTE Object (ERO) is used to optionally specify the 608 explicit route of an L2S sub-LSP. Each signaled ERO corresponds to a 609 particular L2S_SUB_LSP object. Details of ERO encoding are specified 610 in Section 4.5 of [RFC4875]. Within the Receiver-Driven context, ERO 611 objects are encoded in a reverse order. 613 When a RSVP PATH message signals a L2S sub-LSP, the EXPLICIT_ROUTE 614 object encodes the path from the leaf to the root LSR. The PATH 615 message also includes the L2S_SUB_LSP object for the L2S sub-LSP 616 being signaled. The < [], > tuple 617 represents the L2S sub-LSP and is referred to as the sub-LSP 618 descriptor. 620 The absence of an ERO should be interpreted as requiring hop-by-hop 621 reverse forwarding for the sub-LSP based on the root address field of 622 the L2S_SUB_LSP object. 624 3.2. PIM-mRSVP TE Interworking Operation 626 3.2.1. New M-Flow Spec Types 628 [I-D.tao-mpls-pim-interworking] introduces four types of M-Flow 629 specs, each corresponding to a type of PIM forwarding state: 631 o M-Flow Spec Type-1(value 1) for (*, *, RP); 633 o M-Flow Spec Type-2(value 2) for (*, G); 635 o M-Flow Spec Type-3(value 3) for (S, G); 637 o M-Flow Spec Type-4(value 4) for (S, G, RPT); 639 These M-Flow Spec types will be signaled in-band across the MPLS 640 network by mRSVP-TE. Their formats are specified in 641 [I-D.tao-mpls-pim-interworking]. mRSVP-TE is used to (1) initiate the 642 signaling of a RD P2MP LSP or a sub-LSP, (2) merge a sub-LSP into an 643 existing LSP, or (3) delete it when a downstream router does not need 644 it, based upon the information conveyed in the said M-Flow Specs. 645 This implies that: 647 o M-Flow specs are encapsulated into mRSVP-TE PATH messages, and 649 o M-Flow specs are used to identify a given multicast session so 650 that a receiver-driven, traffic-engineered P2MP LSP path will be 651 computed and established accordingly. 653 When an M-Flow spec is generated and passed to mRSVP-TE based upon 654 the MPLS-PIM interworking procedures enforced by an mPMBR, mRSVP-TE 655 first determines if this M-Flow spec leads to the grafting of an 656 additional sub-LSP, by using the procedure described in 657 [I-D.tao-mpls-pim-interworking]. If the contents of the signaled 658 M-Flow Spec does not mandate the grafting of an additional sub-LSP, 659 the M-Flow is then bound to an existing RD P2MP LSP. 661 If a new sub-LSP needs to be grafted to an existing receiver-driven, 662 traffic engineered P2MP MPLS LSP according to the information 663 conveyed in the M-Flow spec, the procedures documented in the 664 following subsections MUST be followed. 666 3.2.2. Signaling An Unidentified Sub-LSP 668 When a sub-LSP is signaled from a leaf mPMBR towards the root, 669 mRSVP-TE may not have determined if this sub-LSP would lead to the 670 computation and the establishment of a new RD P2MP LSP or the 671 grafting of an additional sub-LSP to an existing RD P2MP MPLS LSP. 672 This sub-LSP is denoted as an "Unidentified" sub-LSP. 674 mRSVP-TE then works as follows to signal an unidentified sub-LSP. 676 3.2.2.1. Sending A Path Message For An Unidentified Sub-LSP 678 o Set 0 as the tunnel ID field in the session object 680 o Set the "Tunnel Identifier with M-Flow Spec Session" attribute 681 flag to 1 683 o Encode the M-Flow spec in the mflow spec object list according to 684 the "Path Message Change and Encoding". 686 3.2.2.2. Receiving A Path Message For An Unidentified Sub-LSP 688 When a LSR receives a PATH message with 0 as the tunnel ID and the 689 "Tunnel Identifier with MFLOW spec" flag set to 1, it processes the 690 sub-LSP grafting request as an unidentified sub-LSP as follows: 692 o Use the included M-Flow spec and binding policy to determine which 693 RD P2MP LSP the sub-LSP belongs to. See Sections 3.1.2 and 3.1.3 694 of [I-D.tao-mpls-pim-interworking]. 696 o When the sub-LSP does not merge into an existing RD P2MP MPLS LSP, 697 the PATH message will reach the root, which can then determine if 698 the sub-LSP assumes the computation of a new RD P2MP MPLS LSP, or 699 merges into an existing RD P2MP MPLS LSP. 701 o The sub-LSP is then assigned the tunnel ID. The root sets the 702 "Tunnel Identifier with MFLOW spec" session attribute flag to 0, 703 and completes the rest of the signaling using mRSVP-TE procedures. 705 o Each LSR merges the M-Flow spec in the mflow spec object list 706 using mflow_specs_merge(T, F) when the tunnel is identified. 708 3.3. Path Messages 710 The mechanism specified in this document allows a RD P2MP/MP2MP LSP 711 to be signaled using one or more RSVP PATH messages. Each PATH 712 message MAY signal one or several L2S sub-LSPs. 714 A receiver-driven P2MP MPLS LSP uses the PATH message to carry the 715 LABEL object upstream from the leaf router towards the Sender. With 716 a receiver-driven usage of the RSVP PATH messages, the LABEL_REQUEST 717 object carried by the PATH message is no longer mandatory. It 718 becomes optional for receiver-driven PATH messages, as specified in 719 Figure 4 below. 721 The PIM/mRSVP-TE inter-working procedures introduce a new session 722 attribute called "Tunnel Identifier with MFLOW spec". By default, it 723 is set to 0. For an unidentified sub-LSP, the attribute is set by 724 the Path Sender to indicate that a router receiving this message must 725 process the information conveyed in M-Flow specs to identify the 726 corresponding session and make a decision accordingly (e.g., 727 contribute to the grafting of a new sub-LSP to the relevant RD P2MP 728 MPLS LSP). 730 The mRSVP-TE PATH message is extended to include a list of M-Flow 731 Spec Objects: 733 ::= [ ] 734 [ [ | ] ...] 735 [ ] 736 737 738 [ ] 739 [ ] 740 [ ] 741 [ ... ] 742 [ ] 743 [ ] 744 [ ] 745 [ ... ] 746 747 [] 748 [mflow spec list] 749 < mflow spec list > ::= [< mflow spec list >] 751 Figure 4: Path Message Extensions 753 The SESSION object encodes information about the being-signalled 754 multicast group address. The SESSION object together with the 755 L2S_SUB_LSP object will be used as the key to associate different 756 sub-LSPs to the same RD P2MP LSP. 758 Using [RFC4875] as the reference specification, the LABEL object is 759 added to the as specified in Figure 5. 761 ::= 762 [ ] 763 [ ] 764 [ ] 765 [ ] 766