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