idnits 2.17.1 draft-chen-pce-label-x-domains-14.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 2 instances of too long lines in the document, the longest one being 2 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (10 January 2022) is 808 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: 'RFC5441' is mentioned on line 158, but not defined == Unused Reference: 'RFC2119' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track A. Liu 5 Expires: 14 July 2022 Ciena 6 M. Toy 7 Verizon 8 V. Liu 9 10 January 2022 11 Extensions to PCEP for Distributing Label Cross Domains 12 draft-chen-pce-label-x-domains-14 14 Abstract 16 This document specifies extensions to PCEP for distributing labels 17 crossing domains for an inter-domain Point-to-Point (P2P) or Point- 18 to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path 19 (LSP). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 14 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 57 4. Label Distribution . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. An Exmaple . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 5 61 5.2. Label Object . . . . . . . . . . . . . . . . . . . . . . 6 62 5.3. LSP Tunnel Object . . . . . . . . . . . . . . . . . . . . 7 63 5.4. Request Message Extension . . . . . . . . . . . . . . . . 9 64 5.5. Reply Message Extension . . . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 9 68 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 9.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 After a path crossing multiple domains is computed, an inter-domain 77 Traffic Engineering (TE) Label Switched Path (LSP) tunnel may be set 78 up along the path by a number of tunnel central controllers (TCCs). 79 Each of the domains through which the path goes may be controlled by 80 a tunnel central controller (TCC), which sets up the segment of the 81 TE LSP tunnel in the domain. When the TCC sets up the segment of the 82 TE LSP tunnel in its domain that is not a domain containing the tail 83 end of the tunnel, it needs a label and an interface from a 84 downstream domain, which is next to it along the path. 86 This document specifies extensions to PCEP for distributing a label 87 and an interface from a domain to its upstream domain along the path 88 for the TE LSP tunnel crossing multiple domains. 90 2. Terminology 92 ABR: Area Border Router. Routers used to connect two IGP areas 93 (areas in OSPF or levels in IS-IS). 95 ASBR: Autonomous System Border Router. Routers used to connect 96 together ASes via inter-AS links. 98 Boundary Node (BN): a boundary node is either an ABR in the context 99 of inter-area Traffic Engineering or an ASBR in the context of inter- 100 AS Traffic Engineering. 102 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 103 a determined sequence of domains. 105 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 106 a determined sequence of domains. 108 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 110 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 112 LSP: Label Switched Path. 114 LSR: Label Switching Router. 116 PCC: Path Computation Client. Any client application requesting a 117 path computation to be performed by a Path Computation Element. 119 PCE: Path Computation Element. An entity (component, application, or 120 network node) that is capable of computing a network path or route 121 based on a network graph and applying computational constraints. 123 PCE(i) is a PCE with the scope of domain(i). 125 TED: Traffic Engineering Database. 127 This document uses terminologies defined in RFC5440. 129 3. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC2119. 135 4. Label Distribution 137 The Label Distribution may be provided by the PCE-based path 138 computation. A PCE responsible for a domain computes a path segment 139 for the domain, which is from an entry boundary to an exit boundary 140 (or an egress) node of the domain. The PCE gets an label from the 141 entry boundary node and adds an label object containing the label and 142 an interface as the incoming interface of the label in the reply 143 message to be sent to the requesting PCC (or another PCE). 145 When a PCE or PCC receives a reply message containing an label 146 object, it removes the object from the message. The PCE may store 147 the information in the label object or send the information to 148 another component such as a Tunnel Central Controller (TCC). 150 4.1. An Exmaple 152 Figure 1 below illustrates a simple two-AS topology. There is a PCE 153 responsible for the path computation in each AS. A path computation 154 is requested from the Tunnel Central Controller (TCC), acting as the 155 PCC, which sends the path computation request to PCE-1. 157 PCE-1 is unable to compute an end-to-end path and invokes PCE-2 158 (possibly using the techniques described in [RFC5441]). PCE-2 159 computes a path segment from entry boundary node ASBR-2 of the right 160 domain to the egress as {ASBR-2, C, D, Egress}. 162 In addition to placing this path segment in the reply message to PCE- 163 1, PCE-2 gets an label from the entry boundary node ASBR-2 and adds 164 an label object containing the label with the interface between 165 ASBR-1 and ASBR-2 into the reply message. 167 ------------------------------- ------------------------------ 168 | ------- | | ------- | 169 | +-->| PCE-1 |<---------+--+-->| PCE-2 | | 170 | | ------- | | ------- | 171 | v | | ^ | 172 | ----- | | | | 173 | | TCC | | | | | 174 | | PCC | | | | | 175 | ----- | | v | 176 | ------- - - ------ | | ------ - - ------ | 177 | |Ingress|--|A|--|B|--|ASBR-1|-+--+-|ASBR-2|--|C|--|D|--|Egress| | 178 | ------- - - ------ | | ------ - - ------ | 179 | | | | 180 ------------------------------- ------------------------------ 182 Figure 1: Example of Label Distribution 184 When PCE-1 receives the reply message containing the label object 185 from PCE-2, it removes the object from the message. PCE-1 may store 186 the information in the label object or send the information to 187 another component such as a Tunnel Central Controller (TCC). TCC may 188 set up the segment of the LSP tunnel from Ingress to ASBR-2 using the 189 label with the interface in the label object from ASBR-2. 191 5. Extensions to PCEP 193 This section describes the extensions to PCEP for distributing labels 194 crossing domains for an inter-domain Point-to-Point (P2P) or Point- 195 to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path 196 (LSP). The extensions include the definition of a new flag in the RP 197 object, tunnel information and label in a PCReq/PCRep message. 199 5.1. RP Object Extension 201 The following flags are added into the RP Object: 203 o L (Label distribution bit - 1 bit): 204 0: This indicates that this is not a PCReq/PCRep message 205 for distributing labels crossing domains. 206 1: This indicates that this is a PCReq or PCRep message 207 for distributing labels crossing domains. 209 o C (LSP tunnel Creation bit - 1 bit): 210 0: This indicates that this is not a PCReq/PCRep message for 211 creating the segment of the LSP tunnel. 212 1: This indicates that this is a PCReq/PCRep message for 213 creating the segment of the LSP tunnel in the domain 214 and distributing labels to its previous domain. 216 An L bit is added in the flag bits field of the RP object to tell a 217 receiver of a PCReq/PCRep message that the message is for 218 distributing labels crossing domains for an inter-domain LSP. The 219 IANA request is referenced in Section below (Request Parameter Bit 220 Flags) of this document. 222 The C bit is added in the flag bits field of the RP object to tell 223 the receiver of a PCReq/PCRep message that the message is for 224 creating the segment of the LSP tunnel in a domain and distributing 225 labels from this domain to its previous domain. The IANA request is 226 referenced in Section below (Request Parameter Bit Flags) of this 227 document. 229 This L bit with the N bit defined in RFC6006 can indicate whether the 230 PCReq/PCRep message is for distributing labels for an MPLS TE P2P LSP 231 or an MPLS TE P2MP LSP. 233 o L = 1 and N = 0: This indicates that this is a PCReq/PCRep message 234 for distributing labels for a P2P LSP. 235 o L = 1 and N = 1: This indicates that this is a PCReq/PCRep message 236 for distributing labels for a P2MP LSP. 238 5.2. Label Object 240 The format of a label object body (Object-Type=2) is illustrated 241 below, which comprises a label and an optional node sub object. The 242 node sub object contains a boundary node IP address, from which the 243 label is allocated and distributed. 245 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Label | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Node IPv4/IPv6 sub object (optional) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 The format of the node IPv4 address sub object (Type=1) is as 254 follows: 256 0 1 2 3 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |L| Type(1) | Length (8) | Node IPv4 address | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Node IPv4 address (cont) | Reserved | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 The format of the node IPv6 address sub object (Type=2) is 265 illustrated below: 267 0 1 2 3 268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |L| Type(2) | Length (20) | Node IPv6 address | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 | Node IPv6 address (cont) | 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Node IPv6 address (cont) | Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 5.3. LSP Tunnel Object 281 The LSP tunnel object contains the information that may be used to 282 identify an LSP tunnel. An LSP tunnel may be a P2P or P2MP LSP 283 tunnel. It may be an IPv4 or IPv6 LPS tunnel. Thus there are four 284 types of LSP tunnels: 1) P2P LSP IPv4 tunnel, 2) P2P LSP IPv6 tunnel, 285 3) P2MP LSP IPv4 tunnel, and 4) P2MP LSP IPv6 tunnel. 287 The format of the P2P LSP IPv4/6 tunnel object body is as follows: 289 0 1 2 3 290 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | P2P LSP Tunnel Egress IPv4/6 Address (4/16 bytes) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Reserved | Tunnel ID | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Extended Tunnel ID (4/16 bytes) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Reserved | LSP ID | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Controller ID (4/16 bytes) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 o P2P LSP Tunnel Egress IPv4/6 Address: 304 IPv4/6 address of the egress of the tunnel. 305 o Tunnel ID: 306 A 16-bit identifier that is constant over the life of the tunnel. 307 o Extended Tunnel ID: 308 A 4/16-byte identifier that is constant over the life of the tunnel. 309 o LSP ID: 310 A 16-bit identifier to allow resources sharing. 311 o Controller ID: 312 A 4/16-byte identifier for the controller responsible for the head 313 segment of the tunnel. 315 The format of the P2MP LSP IPv4/6 tunnel object body is as follows: 317 0 1 2 3 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | P2MP ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Reserved | Tunnel ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Extended Tunnel ID (4/16 bytes) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Reserved | LSP ID | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Controller ID (4/16 bytes) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 o P2MP ID: 332 A 32-bit number unique within the ingress of LSP tunnel. 333 o Tunnel ID: 334 A 16-bit identifier that is constant over the life of the tunnel. 335 o Extended Tunnel ID: 336 A 4/16-byte identifier that is constant over the life of the tunnel. 337 o LSP ID: 338 A 16-bit identifier to allow resources sharing. 339 o Controller ID: 340 A 16-byte identifier for the controller responsible for the head 341 segment of the tunnel. 343 5.4. Request Message Extension 345 Figure below illustrates the format of a request message with a 346 optional LSP tunnel object: 348 ::= 349 [] 350 351 ::=[] 352 ::= [] [] [] 353 [] [[]] [] 354 [] 355 [] 357 5.5. Reply Message Extension 359 Below is the format of a reply message with an optional Label object: 361 ::= 362 363 ::=[] 364 ::= 365 [] 366 [] 367 [] 368 ::=[] 369 ::= [][