idnits 2.17.1 draft-chen-pce-label-x-domains-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 (October 21, 2013) is 3840 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 164, but not defined == Unused Reference: 'RFC2119' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 497, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Liu 5 Expires: April 24, 2014 Ericsson 6 F. Xu 7 Verizon 8 M. Toy 9 Comcast 10 V. Liu 11 China Mobile 12 October 21, 2013 14 Extensions to PCEP for Distributing Label Cross Domains 15 draft-chen-pce-label-x-domains-00.txt 17 Abstract 19 This document specifies extensions to PCEP for distributing labels 20 crossing domains for an inter-domain Point-to-Point (P2P) or Point- 21 to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path 22 (LSP). 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 April 24, 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 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 4. Label Distribution . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. An Exmaple . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 5 65 5.2. Label Object . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.3. LSP Tunnel Object . . . . . . . . . . . . . . . . . . . . 7 67 5.4. Request Message Extension . . . . . . . . . . . . . . . . 9 68 5.5. Reply Message Extension . . . . . . . . . . . . . . . . . 9 69 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. Distributing Label in Ordered Setup . . . . . . . . . . . 10 71 6.2. Distributing Label in Path Computation . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 11 75 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 After a path crossing multiple domains is computed, an inter-domain 84 Traffic Engineering (TE) Label Switched Path (LSP) tunnel may be set 85 up along the path by a number of tunnel central controllers (TCCs). 86 Each of the domains through which the path goes may be controlled by 87 a tunnel central controller (TCC), which sets up the segment of the 88 TE LSP tunnel in the domain. When the TCC sets up the segment of the 89 TE LSP tunnel in its domain that is not a domain containing the tail 90 end of the tunnel, it needs a label from a domain, which is next to 91 it along the path. 93 This document specifies extensions to PCEP and various procedures for 94 distributing a label from a domain to its previous domain along the 95 path for the TE LSP tunnel crossing multiple domains. 97 2. Terminology 99 ABR: Area Border Router. Routers used to connect two IGP areas 100 (areas in OSPF or levels in IS-IS). 102 ASBR: Autonomous System Border Router. Routers used to connect 103 together ASes of the same or different service providers via one or 104 more inter-AS links. 106 Boundary Node (BN): a boundary node is either an ABR in the context 107 of inter-area Traffic Engineering or an ASBR in the context of 108 inter-AS Traffic Engineering. 110 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 111 a determined sequence of domains. 113 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 114 a determined sequence of domains. 116 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 118 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 120 LSP: Label Switched Path. 122 LSR: Label Switching Router. 124 PCC: Path Computation Client. Any client application requesting a 125 path computation to be performed by a Path Computation Element. 127 PCE: Path Computation Element. An entity (component, application, or 128 network node) that is capable of computing a network path or route 129 based on a network graph and applying computational constraints. 131 PCE(i) is a PCE with the scope of domain(i). 133 TED: Traffic Engineering Database. 135 This document uses terminologies defined in RFC5440. 137 3. Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC2119. 143 4. Label Distribution 145 The Label Distribution may be provided by the PCE-based path 146 computation. A PCE responsible for a domain computes a path segment 147 for the domain, which is from an entry boundary to an exit boundary 148 (or an egress) node of the domain. The PCE gets an label from the 149 entry boundary node and adds an label object containing the label in 150 the reply message to be sent to the requesting PCC (or another PCE). 152 When a PCE or PCC receives a reply message containing an label 153 object, it removes the object from the message. The PCE may store 154 the information in the label object or send the information to 155 another component such as a Tunnel Central Controller (TCC). 157 4.1. An Exmaple 159 Figure 1 below illustrates a simple two-AS topology. There is a PCE 160 responsible for the path computation in each AS. A path computation 161 is requested from the Tunnel Central Controller (TCC), acting as the 162 PCC, which sends the path computation request to PCE-1. PCE-1 is 163 unable to compute an end-to-end path and invokes PCE-2 (possibly 164 using the techniques described in [RFC5441]). PCE-2 computes a path 165 segment from entry boundary node ASBR-2 of the right domain to the 166 egress as {ASBR-2, C, D, Egress}. In addition to placing this path 167 segment in the reply message to PCE-1, PCE-2 gets an label from the 168 entry boundary node ASBR-2 and adds an label object containing the 169 label and optionally the ASBR-2 into the reply message. 171 ------------------------------- ------------------------------ 172 | ------- | | ------- | 173 | +-->| PCE-1 |<---------+--+-->| PCE-2 | | 174 | | ------- | | ------- | 175 | v | | ^ | 176 | ----- | | | | 177 | | TCC | | | | | 178 | | PCC | | | | | 179 | ----- | | v | 180 | ------- - - ------ | | ------ - - ------ | 181 | |Ingress|--|A|--|B|--|ASBR-1|-+--+-|ASBR-2|--|C|--|D|--|Egress| | 182 | ------- - - ------ | | ------ - - ------ | 183 | | | | 184 ------------------------------- ------------------------------ 186 Figure 1: Example of Label Distribution 188 When PCE-1 receives the reply message containing the label object 189 from PCE-2, it removes the object from the message. PCE-1 may store 190 the information in the label object or send the information to 191 another component such as a Tunnel Central Controller (TCC). TCC may 192 set up the segment of the LSP tunnel from Ingress to ASBR-2 using the 193 label in the label object from ASBR-2. 195 5. Extensions to PCEP 197 This section describes the extensions to PCEP for distributing labels 198 crossing domains for an inter-domain Point-to-Point (P2P) or Point- 199 to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path 200 (LSP). The extensions include the definition of a new flag in the RP 201 object, tunnel information and label in a PCReq/PCRep message. 203 5.1. RP Object Extension 205 The following flags are added into the RP Object: 207 An L bit is added in the flag bits field of the RP object to tell a 208 receiver of a PCReq/PCRep message that the message is for 209 distributing labels crossing domains for an inter-domain LSP. 211 o L (Label distribution bit - 1 bit): 213 0: This indicates that this is not a PCReq/PCRep message 214 for distributing labels crossing domains. 216 1: This indicates that this is a PCReq or PCRep message 217 for distributing labels crossing domains. 219 The IANA request is referenced in Section below (Request Parameter 220 Bit Flags) of this document. 222 This L bit with the N bit defined in RFC6006 can indicate whether the 223 PCReq/PCRep message is for distributing labels for an MPLS TE P2P LSP 224 or an MPLS TE P2MP LSP. 226 o L = 1 and N = 0: This indicates that this is a PCReq/PCRep message 227 for distributing labels for a P2P LSP. 229 o L = 1 and N = 1: This indicates that this is a PCReq/PCRep message 230 for distributing labels for a P2MP LSP. 232 The C bit is added in the flag bits field of the RP object to tell 233 the receiver of a PCReq/PCRep message that the message is for 234 creating the segment of the LSP tunnel in a domain before 235 distributing labels from this domain to its previous domain. 237 o C (LSP tunnel Creation bit - 1 bit): 239 0: This indicates that this is not a PCReq/PCRep message for 240 creating the segment of the LSP tunnel. 242 1: This indicates that this is a PCReq/PCRep message for 243 creating the segment of the LSP tunnel in the domain 244 before distributing labels to its previous domain. 246 The IANA request is referenced in Section below (Request Parameter 247 Bit Flags) of this document. 249 5.2. Label Object 251 The format of a label object body (Object-Type=2) is illustrated 252 below, which comprises a label and an optional node sub object. The 253 node sub object contains a boundary node IP address, from which the 254 label is allocated and distributed. 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 | Label | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Node IPv4/IPv6 sub object (optional) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 The format of the node IPv4 address sub object (Type=1) is as 265 follows: 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(1) | Length (8) | Node IPv4 address | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Node IPv4 address (cont) | Reserved | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 The format of the node IPv6 address sub object (Type=2) is 276 illustrated below: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |L| Type(1) | Length (20) | Node IPv6 address | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 | Node IPv6 address (cont) | 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Node IPv6 address (cont) | Reserved | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 5.3. LSP Tunnel Object 292 The LSP tunnel object contains the information that may be used to 293 identify an LSP tunnel. An LSP tunnel may be a P2P or P2MP LSP 294 tunnel. It may be an IPv4 or IPv6 LPS tunnel. Thus there are four 295 types of LSP tunnels: 1) P2P LSP IPv4 tunnel, 2) P2P LSP IPv6 tunnel, 296 3) P2MP LSP IPv4 tunnel, and 4) P2MP LSP IPv6 tunnel. 298 The format of the P2P LSP IPv4/6 tunnel object body is as follows: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | P2P LSP Tunnel Egress IPv4/6 Address (4/16 bytes) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Reserved | Tunnel ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Extended Tunnel ID (4/16 bytes) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Reserved | LSP ID | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Controller ID (4/16 bytes) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 o P2P LSP Tunnel Egress IPv4/6 Address: 315 IPv4/6 address of the egress of the tunnel. 316 o Tunnel ID: 317 A 16-bit identifier that is constant over the life of the tunnel. 318 o Extended Tunnel ID: 319 A 4/16-byte identifier that is constant over the life of the tunnel. 320 o LSP ID: 321 A 16-bit identifier to allow resources sharing. 322 o Controller ID: 323 A 4/16-byte identifier for the controller responsible for the head 324 segment of the tunnel. 326 The format of the P2MP LSP IPv4/6 tunnel object body is as follows: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | P2MP ID | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Reserved | Tunnel ID | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Extended Tunnel ID (4/16 bytes) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Reserved | LSP ID | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Controller ID (4/16 bytes) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 o P2MP ID: 343 A 32-bit number unique within the ingress of LSP tunnel. 344 o Tunnel ID: 345 A 16-bit identifier that is constant over the life of the tunnel. 346 o Extended Tunnel ID: 347 A 4/16-byte identifier that is constant over the life of the tunnel. 348 o LSP ID: 349 A 16-bit identifier to allow resources sharing. 350 o Controller ID: 351 A 16-byte identifier for the controller responsible for the head 352 segment of the tunnel. 354 5.4. Request Message Extension 356 Figure below illustrates the format of a request message with a 357 optional LSP tunnel object: 359 ::= 360 [] 361 362 ::=[] 363 ::= [] [] [] 364 [] [[]] [] 365 [] 366 [] 368 Figure 2: Format for Request Message 370 5.5. Reply Message Extension 372 Below is the format of a reply message with an optional Label object: 374 ::= 375 376 ::=[] 377 ::= 378 [] 379 [] 380 [] 381 ::=[] 382 ::= [][