idnits 2.17.1 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.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 53 instances of too long lines in the document, the longest one being 3 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 (July 01, 2013) is 3952 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: 'RFC 4875' is mentioned on line 538, but not defined == Missing Reference: 'RFC 2205' is mentioned on line 538, but not defined == Missing Reference: 'RFC 6513' is mentioned on line 900, but not defined == Missing Reference: 'RFC 6514' is mentioned on line 901, but not defined == Missing Reference: 'RFC 4090' is mentioned on line 917, but not defined == Missing Reference: 'I-D.zlj-mpls-mpls-mrsvp-te-frr' is mentioned on line 923, but not defined == Missing Reference: 'TBD' is mentioned on line 931, but not defined == Unused Reference: 'RFC2119' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: 'RFC4420' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 1020, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'I-D.zlj-mpls-mrsvp-te-frr' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC3468' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC3564' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: 'RFC5467' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 1063, 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 4461 ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) == Outdated reference: A later version (-02) exists of draft-zlj-mpls-mrsvp-te-frr-00 -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) Summary: 4 errors (**), 0 flaws (~~), 25 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: January 02, 2014 C. Jacquenet 6 France Telecom Orange 7 E. Metz 8 KPN 9 B. Zhang 10 Telus Communications 11 July 01, 2013 13 Receiver-Driven Multicast Traffic-Engineered Label-Switched Paths 14 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt 16 Abstract 18 This document describes extensions to Resource Reservation Protocol - 19 Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven 20 Traffic-Engineered point-to-multipoint (P2MP) and multipoint-to- 21 multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label 22 Switching (MPLS) and Generalized MPLS (GMPLS)networks. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 02, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Receiver-Driven mRSVP-TE LSP Examples . . . . . . . . . . . . 7 75 2.1. P2MP Example . . . . . . . . . . . . . . . . . . . . . . 7 76 2.2. MP2MP Example . . . . . . . . . . . . . . . . . . . . . . 8 77 3. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 9 78 3.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.1.1. Sessions . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1.2. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . 11 81 3.1.3. Path Originator and Data Receiver . . . . . . . . . . 12 82 3.1.4. Explicit Routing . . . . . . . . . . . . . . . . . . 12 83 3.2. Path Messages . . . . . . . . . . . . . . . . . . . . . . 13 84 3.3. Resv Messages . . . . . . . . . . . . . . . . . . . . . . 14 85 3.4. PathErr Messages . . . . . . . . . . . . . . . . . . . . 14 86 3.5. ResvErr Message . . . . . . . . . . . . . . . . . . . . . 15 87 3.6. PathTear Messages . . . . . . . . . . . . . . . . . . . . 15 88 4. New and Updated Objects . . . . . . . . . . . . . . . . . . . 15 89 4.1. SESSION Objects . . . . . . . . . . . . . . . . . . . . . 15 90 4.1.1. P2MP LSP for IPv4 SESSION Objects . . . . . . . . . . 16 91 4.1.2. MP2MP LSP for IPv4 SESSION Objects . . . . . . . . . 16 92 4.1.3. P2MP LSP for IPv6 SESSION Objects . . . . . . . . . . 16 93 4.1.4. MP2MP LSP for IPv6 SESSION Objects . . . . . . . . . 17 94 4.2. SENDER_TEMPLATE Objects . . . . . . . . . . . . . . . . . 17 95 4.2.1. Multicast LSP IPv4 SENDER_TEMPLATE Objects . . . . . 17 96 4.2.2. Multicast LSP IPv6 SENDER_TEMPLATE Objects . . . . . 18 98 4.3. L2S_SUB_LSP Objects . . . . . . . . . . . . . . . . . . . 18 99 4.3.1. L2S_SUB_LSP IPv4 Objects . . . . . . . . . . . . . . 18 100 4.3.2. L2S_SUB_LSP IPv6 Objects . . . . . . . . . . . . . . 19 101 4.4. FILTER_SPEC Objects . . . . . . . . . . . . . . . . . . . 19 102 4.4.1. mRSVP-TE LSP_IPv4 FILTER_SPEC Objects . . . . . . . . 19 103 4.4.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Objects . . . . . . . . 19 104 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 20 105 5.1. Interwork with PIM . . . . . . . . . . . . . . . . . . . 20 106 5.2. Multicast VPN . . . . . . . . . . . . . . . . . . . . . . 20 107 6. Fast Re-Route Considerations . . . . . . . . . . . . . . . . 20 108 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 21 109 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 113 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 114 11.2. Informative References . . . . . . . . . . . . . . . . . 23 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 117 1. Introduction 119 Multiparty multimedia applications are getting great attentions in 120 the telecom and datacom world. Such applications are QoS-demanding 121 and can therefore benefit from the MPLS traffic engineering 122 capabilities based on dynamic computation and establishment of MPLS 123 LSPs to meet with application-specific QoS requirements. P2MP-TE 124 [RFC4875] defines a procedure to set up point-to-multipoint LSPs from 125 sender to receivers. This procedure works very well if the senders 126 have a priori knowledge of all its receivers. Sometimes multicast 127 data streams are required to get transported over both IP networks 128 and MPLS networks, but MPLS networks have no priori knowledge about 129 senders and receivers. In the IP networks, the receivers can join/ 130 leave a multicast distribution tree by PIM Join/Prune messages, and 131 thus the multicast distribution tree is essentially receiver-driven. 132 When such PIM Join/Prune messages arrive at an MPLS network border, 133 we need a procedure to initiate and set up the multicast distribution 134 tree in MPLS. This document extends RSVP-TE for initiation and setup 135 of P2MP and MP2MP LSPs driven by receivers. 137 1.1. Motivation 139 IP multicast distribution trees are initiated by receivers and 140 dynamic by nature. IP multicast applications are also sensative to 141 bandwidth, especially in the area of residential IPTV services, where 142 the delivery of multicast contents to several hundreds of thousands 143 of IPTV receivers assumes the appropriate level of quality. 145 Current source-driven P2MP LSP establishment, as defined as in 146 [RFC4875], assumes a priori knowledge of receiver locations, and the 147 LSP signalling is initiated and driven by the data sender (headend). 148 The priori knowledge of receiver locations is obtained either through 149 static configuration or by using another protocol to discover such 150 receivers. On the other hand, [RFC4875] does not address the MP2MP 151 LSPs. Actually, there is no straightfoward way to support MP2MP 152 applications by using P2MP LSP unless full-meshed P2MP LSPs are set 153 up independently and separately. 155 The receiver-driven extension to RSVP-TE described in this document 156 will support both P2MP LSPs and MP2MP LSPs. Moreover, it does not 157 require the sender to know all the receivers' locations a priori. 158 The protocols for discovery of receivers are not needed. It provides 159 a natural mechanism to interwork with PIM dynamically. 161 1.2. Terminology 163 The following terms are used in this document: 165 o Sender: Sender refers to the Originator (and hence the Sender) of 166 the content/payload, as defined in [RFC2205]. 168 o Receiver: Receiver refers to the Receiver of the content/payload, 169 as defined in [RFC2205]. 171 o Upstream: The direction of flow from content Receiver toward 172 content Sender, as defined in [RFC2205]. 174 o Downstream: The direction of flow from content Sender toward 175 content Receiver, as defined in [RFC2205]. 177 o Path-Sender: The sender of RSVP PATH messages, with no correlation 178 to the direction of content/payload flows. Its flow direction is 179 irrelevant to that of Sender defined above. All other control 180 messages discussed in this document will use this as the 181 reference. 183 o Path-Receiver: The receiver of RSVP PATH messages, with no 184 correlation to the direction of content/payload flows. 186 o Path-Initiator: The Path-Sender that originated a RSVP PATH 187 message. This is different from Path-Sender in that an 188 intermediate node can be a Path-Sender, but such an intermediate 189 node cannot create and initiate the RSVP PATH message. A Path- 190 Initator is a Path-Sender, but a Path-Sender doesn't have to be a 191 Path-Initiator. 193 o Path-Terminator: The Path-Receiver that does NOT propagate the 194 Path message any further. This is different from Path-Receiver in 195 that an intermediate node can be a Path-Receiver, but such an 196 intermediate node will propagate the Path message to the next hop. 198 o Root: A router where a multcast LSP tree is rooted at. Data 199 enters the root and then is distributed to leaves along the P2MP/ 200 MP2MP LSP. 202 1.3. Overview 204 Although the receiver-driven extensions to RSVP-TE as defined in this 205 document use the existing sender-driven syntax, there are important 206 semantic differences that need to be defined for correct 207 interpretation and interoperability. In the receiver-driven context, 208 we inverted the semantics of RSVP-TE messages, while keeping the 209 syntax unchanged as much as possible. We will use mRSVP-TE to 210 represent the RSVP-TE with receiver-driven extensions described in 211 this document. 213 The following are some key differences that are specific to the 214 receiver-driven paradigm: 216 o The leaf router: the router that receives data/content/payload. 217 In this document, the leaf router will initiate PATH messages. In 218 some sense, the leaf router and the receiver mean the same thing. 219 The term "receiver-driven" also means "leaf-driven". 221 o L2S Destinations: routers where user data payload traffic enters 222 the LSP. L2S means Leaf-to-Source. The source is the sender or 223 root of a multicast stream. 225 o RSVP P2MP PATH messages traverse from receivers to the root. 227 o RSVP P2MP RESV messages traverse from the root to the leaf routers 228 of the P2MP tree strcuture. 230 o For P2MP LSP, a RSVP RESV message received by a router is 231 interpreted as a successful resource reservation made by the 232 upstream node. 234 o For MP2MP LSP, a RSVP RESV message received by a router is 235 interpreted as successful resource reservation made by the 236 downstream node. 238 o After a PATH message is received on an interface for P2MP LSP, 239 label allocation on that interfaces is done prior to sending the 240 corresponding RSVP PATH message upstream. 242 o After a PATH message is received on an interface for MP2MP LSP, 243 label allocation on that interfaces is done prior to sending the 244 corresponding RSVP RESV messages downstream. 246 o For P2MP LSP tree structures, a node receiving a RSVP PATH message 247 first decides if this RSVP PATH message will make the said node a 248 branch LSR or not. If it is not a branch LSR, it is a transit 249 LSR. In the case that it will become a transit LSR because of 250 this PATH message, it will, before sending the RSVP PATH message 251 upstream, allocate required bandwidth on the interface on which 252 the RSVP PATH message is received. The upstream node can send 253 traffic soon after successfully reserving resources on the 254 downstream link, on which the RSVP PATH message SHOULD be 255 received. In the case that the node is already a branch or a 256 transit node before it receives the PATH message, then it will 257 allocate required bandwidth on the interface on which the RSVP 258 PATH message is received, and send the RESV message to the node 259 which sends the PATH message without propagating the PATH message 260 further to the upstream node. For P2MP LSPs, a label is carried 261 by the PATH message and should be used by the upstream node when 262 distributing the data from upstream to downstream. 264 o For MP2MP LSP tree structures, a node will allocate required 265 bandwidth on the interface through which the RSVP PATH message is 266 sent before sending the RSVP PATH message upstream. A node 267 receiving a RSVP PATH message MUST first decide if this RSVP PATH 268 message will make the said node a branch LSR or not. In the case 269 it will become a transit LSR because of this PATH message, then it 270 will allocate required bandwidth on the interface on which the 271 RSVP PATH message is received and will allocate required bandwidth 272 on the interface through which the RSVP PATH message is sent, 273 before sending the RSVP PATH message upstream. The downstream 274 node can send traffic soon after successfully reserving bandwidth 275 on the upstream link through which the RSVP PATH message SHOULD be 276 sent. The upstream node can send traffic soon after successfully 277 reserving bandwidth on the downstream link on which the RSVP PATH 278 message SHOULD be received. In the case that the node is already 279 a branch or a transit node before it receives the PATH message, 280 then it will allocate required resources on the interface on which 281 the RSVP PATH message is received, and send the RESV message to 282 the node which sends the PATH message without propagating the PATH 283 message further to the upstream node. The label carried by the 284 PATH message should be used by the Path-Receiver node to forward 285 data from the Path-Receiver node to the Path-Sender node, and the 286 label carried by RESV messages should be used by its corresponding 287 Path-Sender node to send data from the Path-Sender node to the 288 Path-Receiver node. 290 o For the sake of readability, from now on all mRSVP-TE LSPs will be 291 used to represent all P2MP and/or MP2MP LSPs in receiver-driven 292 (RD) multicast P2MP/MP2MP MPLS environments. We will sometimes 293 use RD P2MP TE LSP or RD MP2MP TE LSP to represent such receiver- 294 driven multicast LSPs. 296 2. Receiver-Driven mRSVP-TE LSP Examples 298 In what follows we describe two examples to show how P2MP and MP2MP 299 are set up, respectively. In both of such examples, Path messages 300 are initiated by data receivers. 302 For the P2MP example, a Path message carries a label for the use of 303 sending data downstream. And for the MP2MP example, both Path 304 message and Resv message carries a label for sending data downstream 305 and upstream. 307 2.1. P2MP Example 309 Sender/Source/Path Terminator/Ingress Router 310 +---------+ 311 | R1 | 312 +-----+---+ 313 _ 314 \ \ /\ 315 \ \ \ Path Message w/ Label OBJECT 316 Resv \ \ \ (msg2) 317 Message \ \ \ 318 (msg3) \ \ \ 319 _\/ \ \ 320 +----------------+ Path Remerge 321 | R3 | Creates Branch Point 322 +----------------+ 323 _ _ 324 / / /\ \ \ /\ 325 / / / \ \ \ Path Message (msg1) 326 Resv Message / / / msg4 \ \ \ w/ Label OBJECT 327 (msg6) / / / \ \ \ 328 / / /Path Msg \ \ \ 329 / / / (msg5) \ \ \ 330 \/_ / / w/Label OBJ _\/ \ \ 331 +----------+ +---+-----+ 332 | R4 | | R5 | 333 +----------+ +---------+ 334 Path Initiator Path Initiator 335 Originator ID = R4 Originator ID = R5 336 L2S Destination = R1 L2S Destination = R1 337 Session = S Session = S 339 Figure 1: P2MP Example 341 In Figure 1, when R5 is added as the first leaf of a mulitcast 342 distribution tree (multicast LSP), the message flow goes as follows: 343 R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the leaf R4 is 344 added, the message flow goes from R4->msg5->R3->msg6->R4. In this 345 case, when R3 receives msg5, R3 finds out that a multicast LSP has 346 already been set up for the same session and the same source. 347 Therefore, R3 finds itself a branch node for leaf R4 and R5, so it 348 will terminate the PATH message and build the corresponding RESV 349 message and send it back to R4. The association of the LSP initiated 350 by R4 to the existing multicast LSP is determined based on the 351 processing of the SESSION object and L2S_SUB_LSP object from the 352 mRSVP-TE message. The SESSION object and the L2S_SUB_LSP objects are 353 documented later in this draft. 355 2.2. MP2MP Example 357 Root/Path Terminator/Ingress Router 358 +---------+ 359 | R1 | 360 +-----+---+ 361 _ 362 \ \ /\ 363 \ \ \ Path-mp2mp Message w/ Label OBJECT 364 Resv \ \ \ (msg2) 365 Message \ \ \ 366 (msg3) \ \ \ 367 w/ Label OBJECT _\/ \ \ 368 +----------------+ Path-mp2mp 369 | R3 | (Branch Point) 370 +----------------+ 371 _ _ 372 / / /\ \ \ /\ 373 / / / \ \ \ Path-mp2mp Message (msg1) 374 Resv Message / / / msg4 \ \ \ (msg1) 375 (msg6) / / / \ \ \ w/ Label OBJECT 376 w/ Label OBJECT/ / /Path-mp2mp \ \ \ 377 / / / Message \ \ \ 378 / / / (msg5) \ \ \ 379 \/_ / / w/ Label OBJ _\/ \ \ 380 +----------+ +---+-----+ 381 | R4 | | R5 | 382 +----------+ +---------+ 383 Path-mp2mp Initiator Path-mp2mp Initiator 384 Originator ID = R4 Originator ID = R5 385 L2S Destination = R1 L2S Destination = R1 386 Session = S Session = S 388 Figure 2: MP2MP Example 390 For MP2MP, the root address should be specified. It is something 391 similar to RP in PIM, but it doesn't need the Register message. In 392 one-to-many applications, the root should be the same as the Sender, 393 while in many-to-many applications, the root could be any router, but 394 should be selected in the same way as RP is selected in PIM. In 395 Figure 2, R1 is specified as the root. When R5 is added as the first 396 leaf (as both a sender and a receiver) of an MP2MP multicast LSP, the 397 message flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. 398 When the leaf R4 ( as both a sender and a receiver)is added, the 399 message flow goes from R4->msg5->R3->msg6->R4. In this case, when R3 400 receives msg5, R3 finds out that an MP2MP mulitcast LSP has already 401 been set up for the same session and the same root and R3 will become 402 the branch LSR for the leaf R4 and R5, so it will terminate the PATH 403 message, build a RESV message and send the RESV message back to R4. 404 The association of the LSP initiated by R4 to the existing MP2MP LSP 405 is determined based on the processing of the SESSION object and the 406 S2L_SUB_LSP from the mRSVP-TE message. The SESSION objects and the 407 L2S_SUB_LSP objects are further documented later in this draft. 409 3. Signaling Protocol Extensions 411 The RSVP-TE with receiver-driven extensions (mRSVP-TE) is similar to 412 the RSVP-TE protocol as specified in [RFC4875], [RFC3473] and 413 [RFC3209], but differs in that the data receivers of an LSP tunnel 414 initiate the Path messages toward the data sender (or the root of a 415 mulitcast LSP). Compared with [RFC4875], mRSVP-TE can also be used 416 to set up MP2MP LSPs. 418 In the context of the receiver-driven RSVP-TE, the Receiver is the 419 Path-Originator. The Path messages go from the Receivers towards the 420 Sender. The Resv messages flow in the opposite direction as compared 421 to the Path messages, i.e. Resv messages are generated by the Sender 422 or a branch LSR. Path messages flow in opposite directions as 423 cmpared with those of the multicast stream distributions, while Resv 424 messages flow in the same directions as the multicast streams. 426 In the context of the receiver-driven RSVP-TE, a Path message will be 427 terminated at the "root" of the multicast distribution tree 428 (multicast LSP) or at an intermediate node if the intermediate node 429 has received another Path message from another receiver for the same 430 multicast distribution tree. When an intermediate node receives two 431 or more Path messages for the same multicast distribution tree, the 432 intermediate node will merge them together. Whether two Path 433 messages should be merged depends on the information encoded in the 434 SESSION and L2S-SUB-LSP objects. The SESSION object encodes 435 multicast group information and the L2S-SUB-LSP (leaf-to-source sub- 436 lsp) object encodes the multicast source or multicast root 437 information. 439 The following sections describe the receiver-driven extensions to the 440 RSVP-TE protocol. When there is no difference in the protocol, the 441 usage of [RFC4875] is assumed. 443 3.1. Mechanisms 445 3.1.1. Sessions 447 As specified in [RFC2205], a session is a data flow with a particular 448 destination and transport-layer protocol. In the context of 449 multicast, the data flow is essentially a multicast distribution tree 450 rooted at the P2MP source or MP2MP root. 452 For the sake of reliability, two or more sources/roots may be 453 deployed to distribute the same multicast streams. A mulitcast 454 stream is often represented by a mulitcast group address. In this 455 document, we will encode the mulitcast group address in the SESSION 456 object and the mulitcast source/root address in the leaf-to-source 457 sub-LSP object. Note that the same session can have different 458 sources/roots, and the same sources/roots can have different 459 sessions. 461 In the context of the receiver-driven mRSVP-TE, the processing of 462 SESSION objects is different from that of SESSION objects in sender- 463 driven RSVP-TE [RFC4875]. In order to distinguish them, we will 464 employ different C-Types of SESSIONs. In this document we will 465 document SESSION objects for native IPv4/IPv6 multicast applications. 466 For new and more applications, new types of SESSION objects will be 467 added. 469 Following the method used by RSVP-TE and P2MP RSVP-TE, this draft 470 documents the use of some new SESSION C-Type as follows: 472 Class Name = SESSION 473 C-Type 474 XX+0 mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type 475 XX+1 mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type 476 XX+2 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type 477 XX+3 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type 479 Where XX is a number to be allocated by IANA. 481 Figure 3: New C-Types of SESSIONs 483 The new SESSION C-Type MUST be used in all receiver-driven P2MP RSVP- 484 TE messages. 486 3.1.2. L2S Sub-LSPs 488 A multicast LSP is composed of one or more leaf-to-source sub-LSPs, 489 which are merged together at the branch nodes. There are two ways to 490 identify each such sub-LSP: 492 o From the Sender's perspective, each sub-LSP is identified by the 493 SESSION object, the SENDER_TEMPLATE object and S2L_SUB_LSP object, 494 as specified in [RFC 4875]. The SESSION object encodes P2MP ID, 495 Tunnel ID, and Extended Tunnel ID. The P2MP ID is unique within 496 the scope of the sender (ingress LSR) and remains constant 497 throughout the lifetime of the P2MP tree structure. The Extended 498 Tunnel ID, which remains constant throughout the lifetime of the 499 P2MP tree structure, and which should contain the sender's address 500 to make sure the identifier is globally unique. Finally, the 501 Tunnel ID, also remains constant throughout the lifetime of the 502 P2MP tree structure. The SENDER_TEMPLATE object contains the 503 ingress LSR source address. The S2L_SUB_LSP contains the 504 destination address of the sub-LSP. 506 o From the Receiver's perspective, each sub-LSP is identified by a 507 new SESSION object, a new SENDER_TEMPLATE object and a new 508 L2S_SUB_LSP object. The SESSION object, different from the one 509 used in typical sender-driven environments, contains information 510 to be used as the key to associate different PATH messages 511 originated from different leaves. The SENDER_TEMPLATE object 512 contains the Path-Originator's address, which is actually the Data 513 Receiver. For P2MP LSP, the L2S_SUB_LSP contains the source 514 address of the sub-LSP, i.e. the data Sender's address. For MP2MP 515 LSP, the L2S_SUB_LSP contains the root address of the sub-LSP. 516 The root address could be any router. The SESSION, 517 SENDER_TEMPLATE and L2S_SUB_LSP all together will identify the 518 multicast stream, the multicast stream's source, and a mulitcast 519 stream's receiver 521 This document takes the approach from the Receiver's perspective. 522 The approach from the Sender's perspective is documented in [RFC 523 4875]. 525 Once an LSR receives a receiver-driven Path message with the SESSION 526 object and L2S_SUB_LSP object, the LSR should be able to use the 527 SESSION object and L2S_SUB_LSP object to determine whether the sub- 528 LSP signaled by this Path message should be merged with existing 529 multicast LSPs. 531 3.1.3. Path Originator and Data Receiver 533 In the context of the receiver-driven RSVP-TE, a Path Originator is 534 also a Data Receiver. This document will document a new type of 535 SENDER_TEMPLATE object, which contains the Path-Originator's IP 536 address and describes the identity of the Path Originator. 538 In [RFC 2205] and [RFC 4875], the "sender" is both a path originator 539 and a data sender. In the receiver-driven context, path originators 540 and data senders may be different. For P2MP, path originators are 541 actually the data receivers. For MP2MP, path originators are also 542 both the data senders and data receivers. 544 In this document, we will use the same Object Class SENDER_TEMPLATE 545 with a different C-Type to represent and identify Path Originator. 546 In the case of P2MP LSP, the SENDER_TEMPLATE describes the identify 547 of a data receiver. In the case of MP2MP, the SENDER_TEMPLATE 548 describes the identify of an LSR which work as both a data sender and 549 a data receiver. 551 All of the SESSION object, L2S_SUB_LSP object and SENDER_TEMPLATE 552 object together contained in a Path message will uniquely identify a 553 leaf-to-source sub-LSP. 555 3.1.4. Explicit Routing 557 An EXPLICIT_ROUTE Object (ERO) is used to optionally specify the 558 explicit route of an L2S sub-LSP. Each signaled ERO corresponds to a 559 particular L2S_SUB_LSP object. Details of explicit route encoding 560 are specified in section 4.5 of [RFC4875], but they are encoded in a 561 reverse order in the receiver-driven context. 563 When a Path message signals a L2S sub-LSP, the EXPLICIT_ROUTE object 564 encodes the path from the leaf to the root LSR. The Path message 565 also includes the L2S_SUB_LSP object for the L2S sub-LSP being 566 signaled. The < [], > tuple represents 567 the L2S sub-LSP and is referred to as the sub-LSP descriptor. 569 The absence of the ERO should be interpreted as requiring hop-by-hop 570 reverse-forwarding for the sub-LSP based on the root address field of 571 the L2S_SUB_LSP object. 573 3.2. Path Messages 575 The mechanism specified in this document allows a multicast P2MP/ 576 MP2MP LSP to be signaled using one or more Path messages. Each Path 577 message may signal one L2S sub-LSPs. 579 A receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the 580 LABEL object upstream from the Receiver towards the Sender. With a 581 receiver-driven usage of the RSVP PATH messages, the LABEL_REQUEST 582 object carried by the PATH message is no longer mandatory, it becomes 583 optional for receiver-driven PATH messages, as specified in Figure 4: 585 ::= [ ] 586 [ [ | ] ...] 587 [ ] 588 589 590 [ ] 591 [ ] 592 [ ] 593 [ ... ] 594 [ ] 595 [ ] 596 [ ] 597 [ ... ] 598 599 [] 601 Figure 4: Path Message Extensions 603 The SESSION object encodes information about the being-signalled 604 multicast stream. The SESSION object together with L2S_SUB_LSP will 605 be used as the key to associate different sub-LSPs to the same 606 multicast LSP. 608 Using [RFC4875] as the base specification, the LABEL object is added 609 to the as specified in Figure 5: 611 ::= 613 [ ] 614 [ ] 615 [ ] 616 [ ] 617