idnits 2.17.1 draft-chen-pce-label-x-domains-13.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 (July 11, 2021) is 1012 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 159, but not defined == Unused Reference: 'RFC2119' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 429, 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: January 12, 2022 Ciena 6 M. Toy 7 Verizon 8 V. Liu 9 July 11, 2021 11 Extensions to PCEP for Distributing Label Cross Domains 12 draft-chen-pce-label-x-domains-13 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 January 12, 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 4. Label Distribution . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. An Exmaple . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 5 62 5.2. Label Object . . . . . . . . . . . . . . . . . . . . . . 6 63 5.3. LSP Tunnel Object . . . . . . . . . . . . . . . . . . . . 7 64 5.4. Request Message Extension . . . . . . . . . . . . . . . . 8 65 5.5. Reply Message Extension . . . . . . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 9 69 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 After a path crossing multiple domains is computed, an inter-domain 78 Traffic Engineering (TE) Label Switched Path (LSP) tunnel may be set 79 up along the path by a number of tunnel central controllers (TCCs). 80 Each of the domains through which the path goes may be controlled by 81 a tunnel central controller (TCC), which sets up the segment of the 82 TE LSP tunnel in the domain. When the TCC sets up the segment of the 83 TE LSP tunnel in its domain that is not a domain containing the tail 84 end of the tunnel, it needs a label and an interface from a 85 downstream domain, which is next to it along the path. 87 This document specifies extensions to PCEP for distributing a label 88 and an interface from a domain to its upstream domain along the path 89 for the TE LSP tunnel crossing multiple domains. 91 2. Terminology 93 ABR: Area Border Router. Routers used to connect two IGP areas 94 (areas in OSPF or levels in IS-IS). 96 ASBR: Autonomous System Border Router. Routers used to connect 97 together ASes via inter-AS links. 99 Boundary Node (BN): a boundary node is either an ABR in the context 100 of inter-area Traffic Engineering or an ASBR in the context of inter- 101 AS Traffic Engineering. 103 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 104 a determined sequence of domains. 106 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 107 a determined sequence of domains. 109 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 111 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 113 LSP: Label Switched Path. 115 LSR: Label Switching Router. 117 PCC: Path Computation Client. Any client application requesting a 118 path computation to be performed by a Path Computation Element. 120 PCE: Path Computation Element. An entity (component, application, or 121 network node) that is capable of computing a network path or route 122 based on a network graph and applying computational constraints. 124 PCE(i) is a PCE with the scope of domain(i). 126 TED: Traffic Engineering Database. 128 This document uses terminologies defined in RFC5440. 130 3. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC2119. 136 4. Label Distribution 138 The Label Distribution may be provided by the PCE-based path 139 computation. A PCE responsible for a domain computes a path segment 140 for the domain, which is from an entry boundary to an exit boundary 141 (or an egress) node of the domain. The PCE gets an label from the 142 entry boundary node and adds an label object containing the label and 143 an interface as the incoming interface of the label in the reply 144 message to be sent to the requesting PCC (or another PCE). 146 When a PCE or PCC receives a reply message containing an label 147 object, it removes the object from the message. The PCE may store 148 the information in the label object or send the information to 149 another component such as a Tunnel Central Controller (TCC). 151 4.1. An Exmaple 153 Figure 1 below illustrates a simple two-AS topology. There is a PCE 154 responsible for the path computation in each AS. A path computation 155 is requested from the Tunnel Central Controller (TCC), acting as the 156 PCC, which sends the path computation request to PCE-1. 158 PCE-1 is unable to compute an end-to-end path and invokes PCE-2 159 (possibly using the techniques described in [RFC5441]). PCE-2 160 computes a path segment from entry boundary node ASBR-2 of the right 161 domain to the egress as {ASBR-2, C, D, Egress}. 163 In addition to placing this path segment in the reply message to PCE- 164 1, PCE-2 gets an label from the entry boundary node ASBR-2 and adds 165 an label object containing the label with the interface between 166 ASBR-1 and ASBR-2 into the reply message. 168 ------------------------------- ------------------------------ 169 | ------- | | ------- | 170 | +-->| PCE-1 |<---------+--+-->| PCE-2 | | 171 | | ------- | | ------- | 172 | v | | ^ | 173 | ----- | | | | 174 | | TCC | | | | | 175 | | PCC | | | | | 176 | ----- | | v | 177 | ------- - - ------ | | ------ - - ------ | 178 | |Ingress|--|A|--|B|--|ASBR-1|-+--+-|ASBR-2|--|C|--|D|--|Egress| | 179 | ------- - - ------ | | ------ - - ------ | 180 | | | | 181 ------------------------------- ------------------------------ 183 Figure 1: Example of Label Distribution 185 When PCE-1 receives the reply message containing the label object 186 from PCE-2, it removes the object from the message. PCE-1 may store 187 the information in the label object or send the information to 188 another component such as a Tunnel Central Controller (TCC). TCC may 189 set up the segment of the LSP tunnel from Ingress to ASBR-2 using the 190 label with the interface in the label object from ASBR-2. 192 5. Extensions to PCEP 194 This section describes the extensions to PCEP for distributing labels 195 crossing domains for an inter-domain Point-to-Point (P2P) or Point- 196 to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path 197 (LSP). The extensions include the definition of a new flag in the RP 198 object, tunnel information and label in a PCReq/PCRep message. 200 5.1. RP Object Extension 202 The following flags are added into the RP Object: 204 o L (Label distribution bit - 1 bit): 205 0: This indicates that this is not a PCReq/PCRep message 206 for distributing labels crossing domains. 207 1: This indicates that this is a PCReq or PCRep message 208 for distributing labels crossing domains. 210 o C (LSP tunnel Creation bit - 1 bit): 211 0: This indicates that this is not a PCReq/PCRep message for 212 creating the segment of the LSP tunnel. 213 1: This indicates that this is a PCReq/PCRep message for 214 creating the segment of the LSP tunnel in the domain 215 and distributing labels to its previous domain. 217 An L bit is added in the flag bits field of the RP object to tell a 218 receiver of a PCReq/PCRep message that the message is for 219 distributing labels crossing domains for an inter-domain LSP. The 220 IANA request is referenced in Section below (Request Parameter Bit 221 Flags) of this document. 223 The C bit is added in the flag bits field of the RP object to tell 224 the receiver of a PCReq/PCRep message that the message is for 225 creating the segment of the LSP tunnel in a domain and distributing 226 labels from this domain to its previous domain. The IANA request is 227 referenced in Section below (Request Parameter Bit Flags) of this 228 document. 230 This L bit with the N bit defined in RFC6006 can indicate whether the 231 PCReq/PCRep message is for distributing labels for an MPLS TE P2P LSP 232 or an MPLS TE P2MP LSP. 234 o L = 1 and N = 0: This indicates that this is a PCReq/PCRep message 235 for distributing labels for a P2P LSP. 236 o L = 1 and N = 1: This indicates that this is a PCReq/PCRep message 237 for distributing labels for a P2MP LSP. 239 5.2. Label Object 241 The format of a label object body (Object-Type=2) is illustrated 242 below, which comprises a label and an optional node sub object. The 243 node sub object contains a boundary node IP address, from which the 244 label is allocated and distributed. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Label | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Node IPv4/IPv6 sub object (optional) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 The format of the node IPv4 address sub object (Type=1) is as 255 follows: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |L| Type(1) | Length (8) | Node IPv4 address | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Node IPv4 address (cont) | Reserved | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 The format of the node IPv6 address sub object (Type=2) is 266 illustrated below: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 |L| Type(2) | Length (20) | Node IPv6 address | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | Node IPv6 address (cont) | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Node IPv6 address (cont) | Reserved | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 5.3. LSP Tunnel Object 282 The LSP tunnel object contains the information that may be used to 283 identify an LSP tunnel. An LSP tunnel may be a P2P or P2MP LSP 284 tunnel. It may be an IPv4 or IPv6 LPS tunnel. Thus there are four 285 types of LSP tunnels: 1) P2P LSP IPv4 tunnel, 2) P2P LSP IPv6 tunnel, 286 3) P2MP LSP IPv4 tunnel, and 4) P2MP LSP IPv6 tunnel. 288 The format of the P2P LSP IPv4/6 tunnel object body is as follows: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | P2P LSP Tunnel Egress IPv4/6 Address (4/16 bytes) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Reserved | Tunnel ID | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Extended Tunnel ID (4/16 bytes) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Reserved | LSP ID | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Controller ID (4/16 bytes) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 o P2P LSP Tunnel Egress IPv4/6 Address: 305 IPv4/6 address of the egress of the tunnel. 306 o Tunnel ID: 307 A 16-bit identifier that is constant over the life of the tunnel. 308 o Extended Tunnel ID: 309 A 4/16-byte identifier that is constant over the life of the tunnel. 310 o LSP ID: 311 A 16-bit identifier to allow resources sharing. 312 o Controller ID: 313 A 4/16-byte identifier for the controller responsible for the head 314 segment of the tunnel. 316 The format of the P2MP LSP IPv4/6 tunnel object body is as follows: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | P2MP ID | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Reserved | Tunnel ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Extended Tunnel ID (4/16 bytes) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Reserved | LSP ID | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Controller ID (4/16 bytes) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 o P2MP ID: 333 A 32-bit number unique within the ingress of LSP tunnel. 334 o Tunnel ID: 335 A 16-bit identifier that is constant over the life of the tunnel. 336 o Extended Tunnel ID: 337 A 4/16-byte identifier that is constant over the life of the tunnel. 338 o LSP ID: 339 A 16-bit identifier to allow resources sharing. 340 o Controller ID: 341 A 16-byte identifier for the controller responsible for the head 342 segment of the tunnel. 344 5.4. Request Message Extension 346 Figure below illustrates the format of a request message with a 347 optional LSP tunnel object: 349 ::= 350 [] 351 352 ::=[] 353 ::= [] [] [] 354 [] [[]] [] 355 [] 356 [] 358 5.5. Reply Message Extension 360 Below is the format of a reply message with an optional Label object: 362 ::= 363 364 ::=[] 365 ::= 366 [] 367 [] 368 [] 369 ::=[] 370 ::= [][