idnits 2.17.1 draft-ietf-mpls-rsvp-te-p2mp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2383. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 55 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As described above one case in which the Sub-Group Originator ID of a received Path message is changed is that of fragmentation of a Path message at a transit node. Another case is when the Sub-Group Originator ID of a received Path message may be changed in the outgoing Path message and set to that of the LSR originating the Path message based on a local policy. For instance an LSR may decide to always change the Sub-Group Originator ID while performing ERO expansion. The Sub-Group ID MUST not be changed if the Sub-Group Originator ID is not changed. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Considerations about the reservation style in a Resv message apply as described in [RFC3209]. The reservation style in the Resv messages can be either FF or SE. All P2MP LSPs that belong to the same P2MP Tunnel MUST be signaled with the same reservation style. Irrespective of whether the reservation style is FF or SE, the S2L sub-LSPs that belong to the same P2MP LSP SHOULD share labels where they share hops. If the S2L sub-LSPs that belong to the same P2MP LSP share labels then they MUST share resources. If the reservation style is FF then S2L sub-LSPs that belong to different P2MP LSPs MUST NOT share resources or labels. If the reservation style is SE then S2L sub-LSPs that belong to different P2MP LSPs and the same P2MP Tunnel SHOULD share resources where they share hops, but MUST not share labels in packet environments. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2007) is 6282 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 4420 (Obsoleted by RFC 5420) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-05 == Outdated reference: A later version (-07) exists of draft-ietf-bfd-mpls-02 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-lsp-stitching-03 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-te-node-cap-01 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal (Editor) 3 Internet Draft Juniper Networks 4 Expiration Date: July 2007 5 D. Papadimitriou (Editor) 6 Alcatel 8 S. Yasukawa (Editor) 9 NTT 11 January 2007 13 Extensions to RSVP-TE for Point-to-Multipoint TE LSPs 15 draft-ietf-mpls-rsvp-te-p2mp-07.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes extensions to Resource Reservation Protocol - 43 Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered 44 (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- 45 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 46 networks. The solution relies on RSVP-TE without requiring a 47 multicast routing protocol in the Service Provider core. Protocol 48 elements and procedures for this solution are described. 50 There can be various applications for P2MP TE LSPs such as IP 51 multicast. Specification of how such applications will use a P2MP TE 52 LSP is outside the scope of this document. 54 Table of Contents 56 1 Conventions used in this document ..................... 5 57 2 Terminology ........................................... 5 58 3 Introduction .......................................... 5 59 4 Mechanism ............................................. 6 60 4.1 P2MP Tunnels .......................................... 6 61 4.2 P2MP LSP ............................................. 6 62 4.3 Sub-Groups ............................................ 7 63 4.4 S2L Sub-LSPs .......................................... 7 64 4.4.1 Representation of an S2L Sub-LSP ...................... 7 65 4.4.2 S2L Sub-LSPs and Path Messages ........................ 8 66 4.5 Explicit Routing ...................................... 8 67 5 Path Message .......................................... 11 68 5.1 Path Message Format ................................... 11 69 5.2 Path Message Processing ............................... 12 70 5.2.1 Multiple Path Messages ................................ 12 71 5.2.2 Multiple S2L Sub-LSPs in one Path message ............. 13 72 5.2.3 Transit Fragmentation of Path State Information ....... 15 73 5.2.4 Control of Branch Fate Sharing ........................ 16 74 5.3 Grafting .............................................. 16 75 6 Resv Message .......................................... 17 76 6.1 Resv Message Format ................................... 17 77 6.2 Resv Message Processing ............................... 18 78 6.2.1 Resv Message Throttling ............................... 19 79 6.3 Route Recording ....................................... 20 80 6.3.1 RRO Processing ........................................ 20 81 6.4 Reservation Style ..................................... 20 82 7 PathTear Message ...................................... 21 83 7.1 PathTear Message Format ............................... 21 84 7.2 Pruning ............................................... 21 85 7.2.1 Implicit S2L Sub-LSP Teardown ......................... 21 86 7.2.2 Explicit S2L Sub-LSP Teardown ........................ 22 87 8 Notify and ResvConf Messages .......................... 22 88 8.1 Notify Messages ....................................... 22 89 8.2 ResvConf Messages ..................................... 24 90 9 Refresh Reduction ..................................... 25 91 10 State Management ...................................... 25 92 10.1 Incremental State Update .............................. 25 93 10.2 Combining Multiple Path Messages ...................... 26 94 11 Error Processing ...................................... 27 95 11.1 PathErr Messages ...................................... 27 96 11.2 ResvErr Messages ...................................... 28 97 11.3 Branch Failure Handling ............................... 29 98 12 Admin Status Change ................................... 30 99 13 Label Allocation on LANs with Multiple Downstream Nodes ..30 100 14 P2MP LSP and Sub-LSP Re-optimization .................. 30 101 14.1 Make-before-break ..................................... 30 102 14.2 Sub-Group Based Re-optimization ....................... 31 103 15 Fast Reroute .......................................... 31 104 15.1 Facility Backup ....................................... 32 105 15.1.1 Link Protection ....................................... 32 106 15.1.2 Node Protection ....................................... 32 107 15.2 one-to-one Backup ..................................... 33 108 16 Support for LSRs that are not P2MP Capable ............ 34 109 17 Reduction in Control Plane Processing with LSP Hierarchy. 36 110 18 P2MP LSP Remerging and Cross-Over ..................... 36 111 18.1 Procedures ............................................ 37 112 18.1.1 Re-Merge Procedures ................................... 38 113 19 New and Updated Message Objects ....................... 40 114 19.1 SESSION Object ........................................ 40 115 19.1.1 P2MP LSP Tunnel IPv4 SESSION Object ................... 40 116 19.1.2 P2MP LSP Tunnel IPv6 SESSION Object ................... 41 117 19.2 SENDER_TEMPLATE object ................................ 41 118 19.2.1 P2MP LSP Tunnel IPv4 SENDER_TEMPLATE Object ........... 42 119 19.2.2 P2MP LSP Tunnel IPv6 SENDER_TEMPLATE Object ........... 42 120 19.3 S2L_SUB_LSP Object .................................... 43 121 19.3.1 S2L_SUB_LSP IPv4 Object ............................... 44 122 19.3.2 S2L_SUB_LSP IPv6 Object ............................... 44 123 19.4 FILTER_SPEC Object .................................... 44 124 19.4.1 P2MP LSP_IPv4 FILTER_SPEC Object ...................... 44 125 19.4.2 P2MP LSP_IPv6 FILTER_SPEC Object ...................... 45 126 19.5 P2MP SECONDARY_EXPLICIT_ROUTE Object (SERO) ........... 45 127 19.6 P2MP SECONDARY_RECORD_ROUTE Object (SRRO) ............. 45 128 20 IANA Considerations ................................... 45 129 20.1 New Class Numbers ..................................... 45 130 20.2 New Class Types ....................................... 46 131 20.3 New Error Values ...................................... 46 132 20.4 LSP Attributes Flags .................................. 47 133 21 Security Considerations ............................... 47 134 22 Acknowledgements ...................................... 48 135 23 References ............................................ 48 136 23.1 Normative References .................................. 48 137 23.2 Informative References ................................ 49 138 24 Appendix .............................................. 50 139 24.1 Example ............................................... 50 140 25 Author Information .................................... 51 141 25.1 Editor Information .................................... 51 142 25.2 Contributor Information ............................... 52 143 26 Intellectual Property ................................. 54 144 27 Full Copyright Statement .............................. 54 145 28 Acknowledgement ....................................... 55 146 1. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC-2119 [RFC2119]. 152 2. Terminology 154 This document uses terminologies defined in [RFC3031], [RFC2205], 155 [RFC3209], [RFC3473], [RFC4461] and [RFC4090]. 157 3. Introduction 159 [RFC3209] defines a mechanism for setting up point-to-point (P2P) 160 Traffic Engineered (TE) Label Switched Paths (LSPs) in Multi-Protocol 161 Label Switching (MPLS) networks. [RFC3473] defines extensions to 162 [RFC3209] for setting up P2P TE LSPs in Generalized MPLS (GMPLS) 163 networks. However these specifications do not provide a mechanism 164 for building point-to-multipoint (P2MP) TE LSPs. 166 This document defines extensions to the RSVP-TE protocol [RFC3209], 167 [RFC3473] to support P2MP TE LSPs satisfying the set of requirements 168 described in [RFC4461]. 170 This document relies on the semantics of the Resource Reservation 171 Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs. A P2MP 172 LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L 173 sub-LSPs are set up between the ingress and egress-LSRs and are 174 appropriately combined by the branch LSRs using RSVP semantics to 175 result in a P2MP TE LSP. One Path message may signal one or multiple 176 S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging 177 to a P2MP LSP can be signaled using one Path message or split across 178 multiple Path messages. 180 There are various applications for P2MP TE LSPs and the signaling 181 techniques described in this document can be used, sometimes in 182 combination with other techniques, to support different applications. 184 Specification of how applications will use P2MP TE LSPs and how the 185 paths of P2MP TE LSPs are computed is outside the scope of this 186 document. 188 4. Mechanism 190 This document describes a solution that optimizes data replication by 191 allowing non-ingress nodes in the network to be replication/branch 192 nodes. A branch node is an LSR that replicates the incoming data on 193 to one or more outgoing interfaces. The solution relies on RSVP-TE in 194 the network for setting up a P2MP TE LSP. 196 The P2MP TE LSP is set up by associating multiple S2L sub-LSPs and 197 relying on data replication at branch nodes. This is described 198 further in the following sub-sections by describing P2MP Tunnels and 199 how they relate to S2L sub-LSPs. 201 4.1. P2MP Tunnels 203 The defining feature of a P2MP TE LSP is the action required at 204 branch nodes where data replication occurs. Incoming MPLS labeled 205 data is replicated to outgoing interfaces which may use different 206 labels for the data. 208 A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is 209 identified by a P2MP SESSION object. This object contains the 210 identifier of the P2MP Session which includes the P2MP Identifier 211 (P2MP ID), a tunnel Identifier (Tunnel ID) and an extended tunnel 212 identifier (Extended Tunnel ID). The P2MP ID is a four octet number 213 and is unique within the scope of the ingress LSR. 215 The tuple provides an 216 identifier for the set of destinations of the P2MP TE Tunnel. 218 The fields of the P2MP SESSION object are identical to those of the 219 SESSION object defined in [RFC3209] except that the Tunnel Endpoint 220 Address field is replaced by the P2MP ID field. The P2MP SESSION 221 object is defined in section 19.1 223 4.2. P2MP LSP 225 A P2MP LSP is identified by the combination of the P2MP ID, Tunnel ID 226 and Extended Tunnel ID that are part of the P2MP SESSION object, and 227 the tunnel sender address and LSP ID fields of the P2MP 228 SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is 229 defined in section 19.2. 231 4.3. Sub-Groups 233 As with all other RSVP controlled LSPs, P2MP LSP state is managed 234 using RSVP messages. While the use of RSVP messages is the same, P2MP 235 LSP state differs from P2P LSP state in a number of ways. A P2MP LSP 236 comprises multiple S2L Sub-LSPs and as a result of this it may not be 237 possible to represent full state in a single IP packet. It must also 238 be possible to efficiently add and remove endpoints to and from P2MP 239 TE LSPs. An additional issue is that the P2MP LSP must also handle 240 the state "remerge" problem, see [RFC4461] and section 18. 242 These differences in P2MP state are addressed through the addition of 243 a sub-group identifier (Sub-Group ID) and sub-group originator (Sub- 244 Group Originator ID) to the SENDER_TEMPLATE and FILTER_SPEC objects. 245 Taken together the Sub-Group ID and Sub-Group Originator ID are 246 referred to as the Sub-Group fields. 248 The Sub-Group fields, together with rest of the SENDER_TEMPLATE and 249 SESSION objects, are used to represent a portion of a P2MP LSP's 250 state. This portion of a P2MP LSP's state refers only to signaling 251 state and not data plane replication or branching. For example, it is 252 possible for a node to "branch" signaling state for a P2MP LSP, but 253 to not branch the data associated with the P2MP LSP. Typical 254 applications for generation and use of multiple sub-groups are adding 255 an egress, and semantic fragmentation to ensure that a Path message 256 remains within a single IP packet. 258 4.4. S2L Sub-LSPs 260 A P2MP LSP is constituted of one or more S2L sub-LSPs. 262 4.4.1. Representation of an S2L Sub-LSP 264 An S2L sub-LSP exists within the context of a P2MP LSP. Thus it is 265 identified by the P2MP ID, Tunnel ID, and Extended Tunnel ID that are 266 part of the P2MP SESSION, the tunnel sender address and LSP ID fields 267 of the P2MP SENDER_TEMPLATE object, and the S2L sub-LSP destination 268 address that is part of the S2L_SUB_LSP object. The S2L_SUB_LSP 269 object is defined in section 19.3. 271 An EXPLICIT_ROUTE Object (ERO) or P2MP_SECONDARY_EXPLICIT_ROUTE 272 Object (SERO) is used to optionally specify the explicit route of a 273 S2L sub-LSP. Each ERO or SERO that is signaled corresponds to a 274 particular S2L_SUB_LSP object. Details of explicit route encoding 275 are specified in section 4.5. The SECONDARY_EXPLICIT_ROUTE Object is 276 defined in [RECOVERY], a new P2MP SECONDARY_EXPLICIT_ROUTE Object C- 277 type is defined in Section 19.5 and a matching 278 P2MP_SECONDARY_RECORD_ROUTE Object C-type is defined in Section 19.6. 280 4.4.2. S2L Sub-LSPs and Path Messages 282 The mechanism in this document allows a P2MP LSP to be signaled using 283 one or more Path messages. Each Path message may signal one or more 284 S2L sub-LSPs. Support for multiple Path messages is desirable as one 285 Path message may not be large enough to contain all the S2L sub-LSPs; 286 and they also allow separate manipulation of sub-trees of the P2MP 287 LSP. The reason for allowing a single Path message, to signal 288 multiple S2L sub-LSPs, is to optimize the number of control messages 289 needed to set up a P2MP LSP. 291 4.5. Explicit Routing 293 When a Path message signals a single S2L sub-LSP (that is, the Path 294 message is only targeting a single leaf in the P2MP tree), the 295 EXPLICIT_ROUTE object encodes the path to the egress-LSR. The Path 296 message also includes the S2L_SUB_LSP object for the S2L sub-LSP 297 being signaled. The < [], > tuple 298 represents the S2L sub-LSP and is referred to as the sub-LSP 299 descriptor. The absence of the ERO should be interpreted as 300 requiring hop-by-hop routing for the sub-LSP based on the S2L sub-LSP 301 destination address field of the S2L_SUB_LSP object. 303 When a Path message signals multiple S2L sub-LSPs the path of the 304 first S2L sub-LSP, to the egress-LSR, is encoded in the ERO. The 305 first S2L sub-LSP is the one that corresponds to the first 306 S2L_SUB_LSP object in the Path message. The S2L sub-LSPs 307 corresponding to the S2L_SUB_LSP objects that follow are termed as 308 subsequent S2L sub-LSPs. 310 The path of each subsequent S2L sub-LSP is encoded in a 311 P2MP_SECONDARY_EXPLICIT_ROUTE object (SERO). The format of the SERO 312 is the same as an ERO (as defined in [RFC3209] and [RFC3473]). Each 313 subsequent S2L sub-LSP is represented by tuples of the form < [] >. An SERO for a particular 315 S2L sub-LSP includes only the path from a branch LSR to the egress- 316 LSR of that S2L sub-LSP. The branch MUST appear as an explicit hop 317 in the ERO or some other SERO. The absence of an SERO should be 318 interpreted as requiring hop-by-hop routing for that S2L sub-LSP. 319 Note that the destination address is carried in the S2L sub-LSP 320 object. The encoding of the SERO and S2L_SUB_LSP object are described 321 in detail in section 19. 323 In order to avoid the potential repetition of path information for 324 the parts of S2L sub-LSPs that share hops, this information is 325 deduced from the explicit routes of other S2L sub-LSPs using explicit 326 route compression in SEROs. 328 Explicit route compression is illustrated using Figure 1. 330 A 331 | 332 | 333 B 334 | 335 | 336 C----D----E 337 | | | 338 | | | 339 F G H-------I 340 | |\ | 341 | | \ | 342 J K L M 343 | | | | 344 | | | | 345 N O P Q--R 347 Figure 1. Explicit Route Compression 349 Figure 1. shows a P2MP LSP with LSR A as the ingress-LSR and six 350 egress LSRs: (F, N, O, P, Q and R). When all the six S2L sub-LSPs are 351 signaled in one Path message let us assume that the S2L sub-LSP to 352 LSR F is the first S2L sub-LSP and the rest are subsequent S2L sub- 353 LSPs. The following encoding is one way for the ingress-LSR A to 354 encode the S2L sub-LSP explicit routes using compression: 356 S2L sub-LSP-F: ERO = {B, E, D, C, F}, object-F 357 S2L sub-LSP-N: SERO = {D, G, J, N}, object-N 358 S2L sub-LSP-O: SERO = {E, H, K, O}, object-O 359 S2L sub-LSP-P: SERO = {H, L, P}, object-P, 360 S2L sub-LSP-Q: SERO = {H, I, M, Q}, object-Q, 361 S2L sub-LSP-R: SERO = {Q, R}, object-R, 363 After LSR E processes the incoming Path message from LSR B it sends a 364 Path message to LSR D with the S2L sub-LSP explicit routes encoded as 365 follows: 367 S2L sub-LSP-F: ERO = {D, C, F}, object-F 368 S2L sub-LSP-N: SERO = {D, G, J, N}, object-N 370 LSR E also sends a Path message to LSR H and following is one way to 371 encode the S2L sub-LSP explicit routes using compression: 373 S2L sub-LSP-O: ERO = {H, K, O}, object-O 374 S2L sub-LSP-P: SERO = {H, L, P}, S2L_SUB_LSP object-P, 375 S2L sub-LSP-Q: SERO = {H, I, M, Q}, object-Q, 376 S2L sub-LSP-R: SERO = {Q, R}, object-R, 378 After LSR H processes the incoming Path message from E it sends a 379 Path message to LSR K, LSR L and LSR I. The encoding for the Path 380 message to LSR K is as follows: 382 S2L sub-LSP-O: ERO = {K, O}, object-O 384 The encoding of the Path message sent by LSR H to LSR L is as 385 follows: 387 S2L sub-LSP-P: ERO = {L, P}, object-P, 389 The following encoding is one way for LSR H to encode the S2L sub-LSP 390 explicit routes in the Path message sent to LSR I: 392 S2L sub-LSP-Q: ERO = {I, M, Q}, object-Q, 393 S2L sub-LSP-R: SERO = {Q, R}, object-R, 395 The explicit route encodings in the Path messages sent by LSRs D and 396 Q are left as an exercise for the reader. 398 This compression mechanism reduces the Path message size. It also 399 reduces extra processing that can result if explicit routes are 400 encoded from ingress to egress for each S2L sub-LSP. No assumptions 401 are placed on the ordering of the subsequent S2L sub-LSPs and hence 402 on the ordering of the SEROs in the Path message. All LSRs need to 403 process the ERO corresponding to the first S2L sub-LSP. An LSR needs 404 to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP 405 only if the first hop in the corresponding SERO is a local address of 406 that LSR. The branch LSR that is the first hop of an SERO propagates 407 the corresponding S2L sub-LSP downstream. 409 5. Path Message 411 5.1. Path Message Format 413 This section describes modifications made to the Path message format 414 as specified in [RFC3209] and [RFC3473]. The Path message is enhanced 415 to signal one or more S2L sub-LSPs. This is done by including the S2L 416 sub-LSP descriptor list in the Path message as shown below. 418 ::= [ ] 419 [ [ | ] ...] 420 [ ] 421 422 423 [ ] 424 425 [ ] 426 [ ... ] 427 [ ] 428 [ ] 429 [ ] 430 [ ... ] 431 432 [] 434 Following is the format of the S2L sub-LSP descriptor list. 436 ::= 437 [ ] 439 ::= 440 [ ] 442 Each LSR MUST use the common objects in the Path message and the S2L 443 sub-LSP descriptors to process each S2L sub-LSP represented by the 444 S2L_SUB_LSP object and the SECONDARY-/EXPLICIT_ROUTE object 445 combination. 447 Per the definition of , each S2L_SUB_LSP 448 object MAY be followed by a corresponding SERO. The first S2L_SUB_LSP 449 object is a special case, and its explicit route is specified by the 450 ERO. Therefore, the first S2L_SUB_LSP object SHOULD NOT be followed 451 by an SERO, and if one is present it MUST be ignored. 453 The RRO in the sender descriptor contains the upstream hops traversed 454 by the Path message and applies to all the S2L sub-LSPs signaled in 455 the Path message. 457 An IF_ID RSVP_HOP object MUST be used on links where there is not a 458 one-to-one association of a control channel to a data channel 459 [RFC3471]. An RSVP_HOP object defined in [RFC2205] SHOULD be used 460 otherwise. 462 Path message processing is described in the next section. 464 5.2. Path Message Processing 466 The ingress-LSR initiates the setup of an S2L sub-LSP to each egress- 467 LSR that is a destination of the P2MP LSP. Each S2L sub-LSP is 468 associated with the same P2MP LSP using common P2MP SESSION object 469 and fields in the P2MP SENDER_TEMPLATE 470 object. Hence it can be combined with other S2L sub-LSPs to form a 471 P2MP LSP. Another S2L sub-LSP belonging to the same instance of this 472 S2L sub-LSP (i.e. the same P2MP LSP) SHOULD share resources with 473 this S2L sub-LSP. The session corresponding to the P2MP TE tunnel is 474 determined based on the P2MP SESSION object. Each S2L sub-LSP is 475 identified using the S2L_SUB_LSP object. Explicit routing for the S2L 476 sub-LSPs is achieved using the ERO and SEROs. 478 As mentioned earlier, it is possible to signal S2L sub-LSPs for a 479 given P2MP LSP in one or more Path messages and a given Path message 480 can contain one or more S2L sub-LSPs. An LSR that supports RSVP-TE 481 signaled P2MP LSPs MUST be able to receive and process multiple Path 482 messages for the same P2MP LSP and multiple S2L sub-LSPs in one Path 483 message. This implies that such an LSR MUST be able to receive and 484 process all objects listed in section 19. 486 5.2.1. Multiple Path Messages 488 As described in section 4, either the < [] 489 > or the < [] 490 > tuple is used to specify an S2L sub-LSP. Multiple 491 Path messages can be used to signal a P2MP LSP. Each Path message can 492 signal one or more S2L sub-LSPs. If a Path message contains only one 493 S2L sub-LSP, each LSR along the S2L sub-LSP follows [RFC3209] 494 procedures for processing the Path message besides the S2L_SUB_LSP 495 object processing described in this document. 497 Processing of Path messages containing more than one S2L sub-LSP is 498 described in Section 5.2.2. 500 An ingress-LSR MAY use multiple Path messages for signaling a P2MP 501 LSP. This may be because a single Path message may not be large 502 enough to signal the P2MP LSP. Or it may be while adding leaves to 503 the P2MP LSP the new leaves are signaled in a new Path message. Or an 504 ingress LSR MAY choose to break the P2MP tree into separate 505 manageable P2MP trees. These trees share the same root and may share 506 the trunk and certain branches. The scope of this management 507 decomposition of P2MP trees is bounded by a single tree (the P2MP 508 Tree) and multiple trees with a single leaf each (S2L sub-LSPs). Per 509 [RFC4461], a P2MP LSP MUST have consistent attributes across all 510 portions of a tree. This implies that each Path message that is used 511 to signal a P2MP LSP is signaled using the same signaling attributes 512 with the exception of the S2L sub-LSP descriptors and Sub-Group 513 identifier. 515 The resulting sub-LSPs from the different Path messages belonging to 516 the same P2MP LSP SHOULD share labels and resources where they share 517 hops to prevent multiple copies of the data being sent. 519 In certain cases a transit LSR may need to generate multiple Path 520 messages to signal state corresponding to a single received Path 521 message. For instance ERO expansion may result in an overflow of the 522 resultant Path message. In this case the message can be decomposed 523 into multiple Path messages such that each message carries a subset 524 of the X2L sub-tree carried by the incoming message. 526 Multiple Path messages generated by an LSR that signal state for the 527 same P2MP LSP are signaled with the same SESSION object and have the 528 same in the SENDER_TEMPLATE object. In order 529 to disambiguate these Path messages a tuple is introduced (also referred to as the Sub-Group 531 fields) and encoded in the SENDER_TEMPLATE object. Multiple Path 532 messages generated by an LSR to signal state for the same P2MP LSP 533 have the same Sub-Group Originator ID and have a different sub-Group 534 ID. The Sub-Group Originator ID MUST be set to the TE Router ID of 535 the LSR that originates the Path message. Cases when a transit LSR 536 may change the Sub-Group Originator ID of an incoming Path message 537 are described below. The Sub-Group Originator ID is globally unique. 538 The sub-Group ID space is specific to the Sub-Group Originator ID. 540 5.2.2. Multiple S2L Sub-LSPs in one Path message 542 The S2L sub-LSP descriptor list allows the signaling of one or more 543 S2L sub-LSPs in one Path message. Each S2L sub-LSP descriptor 544 describes a single S2L sub-LSP. 546 All LSRs MUST process the ERO corresponding to the first S2L sub-LSP 547 if the ERO is present. If one or more SEROs are present an ERO MUST 548 be present. The first S2L sub-LSP MUST be propagated in a Path 549 message by each LSR along the explicit route specified by the ERO, if 550 the ERO is present. Else it MUST be propagated using hop-by-hop 551 routing towards the destination identified by the S2L_SUB_LSP object. 553 An LSR MUST process a S2L sub-LSP descriptor for a subsequent S2L 554 sub-LSP as follows: 556 If the S2L_SUB_LSP object is followed by an SERO, the LSR MUST 557 check the first hop in the SERO: 558 - If the first hop of the SERO identifies a local address of the 559 LSR, and the LSR is also the egress identified by the 560 S2L_SUB_LSP object, the descriptor MUST NOT be propagated 561 downstream, but the SERO may be used for egress control per 562 [RFC4003]. 563 - If the first hop of the SERO identifies a local address of the 564 LSR, and the LSR is not the egress as identified by the 565 S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST be 566 included in a Path message sent to the next-hop determined 567 from the SERO. 568 - If the first hop of the SERO is not a local address of the LSR, 569 the S2L sub-LSP descriptor MUST be included in the Path message 570 sent to the LSR that is the next hop to reach the first hop in 571 the SERO. This next hop is determined by using the ERO or other 572 SEROs that encode the path to the SERO's first hop. 574 If the S2L_SUB_LSP object is not followed by an SERO, the LSR MUST 575 examine the S2L_SUB_LSP object: 576 - If this LSR is the egress as identified by the 577 S2L_SUB_LSP object, the S2L sub-LSP descriptor MUST 578 NOT be propagated downstream. 579 - If this LSR is not the egress as identified by the 580 S2L_SUB_LSP object, the LSR MUST make a routing decision 581 to determine the next hop towards the egress, and MUST 582 include the S2L sub-LSP descriptor in a Path message sent 583 to the next-hop towards the egress. In this case, the LSR 584 MAY insert an SERO into the S2L sub-LSP descriptor. 586 Hence a branch LSR MUST only propagate the relevant S2L sub-LSP 587 descriptors to each downstream hop. An S2L sub-LSP descriptor list 588 that is propagated on a downstream link MUST only contain those S2L 589 sub-LSPs that are routed using that hop. This processing MAY result 590 in a subsequent S2L sub-LSP in an incoming Path message becoming the 591 first S2L sub-LSP in an outgoing Path message. 593 Note that if one or more SEROs contain loose hops, expansion of such 594 loose hops MAY result in overflowing the Path message size. Section 595 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split 596 across more than one Path message. 598 The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path 599 message and applies to all the S2L sub-LSPs signaled in the Path 600 message. A transit LSR MUST append its address in an incoming RRO and 601 propagate it downstream. A branch LSR MUST form a new RRO for each of 602 the outgoing Path messages by copying the RRO from the incoming Path 603 message and appending its address. Each such updated RRO MUST be 604 formed using the rules in [RFC3209] updated by [RFC3473] as 605 appropriate. 607 If an LSR is unable to support an S2L sub-LSP in a Path message (for 608 example, it is unable to route towards the destination using the 609 SERO), a PathErr message MUST be sent for the impacted S2L sub-LSP, 610 and normal processing of the rest of the P2MP LSP SHOULD continue. 611 The default behavior is that the remainder of the LSP is not impacted 612 (that is, all other branches are allowed to set up) and the failed 613 branches are reported in PathErr messages in which the 614 Path_State_Removed flag MUST NOT be set. However, the ingress-LSR 615 may set an LSP Integrity flag to request that if there is a setup 616 failure on any branch the entire LSP should fail to set up. This is 617 described further in sections 5.2.4 and 11. 619 5.2.3. Transit Fragmentation of Path State Information 621 In certain cases a transit LSR may need to generate multiple Path 622 messages to signal state corresponding to a single received Path 623 message. For instance ERO expansion may result in an overflow of the 624 resultant Path message. RSVP [RFC2205] disallows the use of IP 625 fragmentation and thus IP fragmentation MUST be avoided in this case. 626 In order to achieve this, the multiple Path messages generated by the 627 transit LSR, are signaled with the Sub-Group Originator ID set to the 628 TE Router ID of the transit LSR and a distinct Sub-Group ID for each 629 Path message. Thus each distinct Path message that is generated by 630 the transit LSR for the P2MP LSP carries a distinct tuple. 633 When multiple Path messages are used by an ingress or transit node, 634 each Path message SHOULD be identical with the exception of the S2L 635 sub-LSP related descriptor (e.g., SERO), message and hop information 636 (e.g., INTEGRITY, MESSAGE_ID and RSVP_HOP), and the sub-group fields 637 of the SENDER_TEMPLATE objects. Except when performing a make- 638 before-break operation as specified in section 14.1, the tunnel 639 sender address and LSP ID fields MUST be the same in each message, 640 and for transit nodes, the same as the values in the received Path 641 message. 643 As described above one case in which the Sub-Group Originator ID of a 644 received Path message is changed is that of fragmentation of a Path 645 message at a transit node. Another case is when the Sub-Group 646 Originator ID of a received Path message may be changed in the 647 outgoing Path message and set to that of the LSR originating the Path 648 message based on a local policy. For instance an LSR may decide to 649 always change the Sub-Group Originator ID while performing ERO 650 expansion. The Sub-Group ID MUST not be changed if the Sub-Group 651 Originator ID is not changed. 653 5.2.4. Control of Branch Fate Sharing 655 An ingress-LSR can control the behavior of an LSP if there is a 656 failure during LSP setup or after an LSP has been established. The 657 default behavior is that only the branches downstream of the failure 658 are not established, but the ingress may request 'LSP integrity' such 659 that any failure anywhere within the LSP tree causes the entire P2MP 660 LSP to fail. 662 The ingress LSP may request 'LSP integrity' by setting bit TBD of the 663 Attributes Flags TLV. (RFC Editor, please replace "TBD" with the bit 664 number allocated by IANA per section 20.4. Please remove this note.) 665 The bit is set if LSP integrity is required. 667 It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES Object 668 [RFC4420]. 670 A branch LSR that supports the Attributes Flags TLV and recognizes 671 this bit MUST support LSP integrity or reject the LSP setup with a 672 PathErr message carrying the error "Routing Error"/"Unsupported LSP 673 Integrity" 675 5.3. Grafting 677 The operation of adding egress-LSR(s) to an existing P2MP LSP is 678 termed as grafting. This operation allows egress nodes to join a P2MP 679 LSP at different points in time. 681 There are two methods to add S2L sub-LSPs to a P2MP LSP. The first 682 is to add new S2L sub-LSPs to the P2MP LSP by adding them to an 683 existing Path message and refreshing the entire Path message. Path 684 message processing described in section 4 results in adding these S2L 685 sub-LSPs to the P2MP LSP. Note that as a result of adding one or more 686 S2L sub-LSPs to a Path message the ERO compression encoding may have 687 to be recomputed. 689 The second is to use incremental updates described in section 10.1. 690 The egress LSRs can be added by signaling only the impacted S2L sub- 691 LSPs in a new Path message. Hence other S2L sub-LSPs do not have to 692 be re-signaled. 694 6. Resv Message 696 6.1. Resv Message Format 698 The Resv message follows the [RFC3209] and [RFC3473] format: 700 ::= [ ] 701 [ [ | ] ... ] 702 [ ] 703 704 705 [ ] [ ] 706 [ ] 707 [ ] 708 [ ... ] 709