idnits 2.17.1 draft-chen-pce-pcc-ted-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2017) is 2418 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) == Unused Reference: 'RFC4655' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 381, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 M. Toy 5 Expires: March 15, 2018 Verizon 6 X. Liu 7 Jabil 8 L. Liu 9 Fujitsu 10 Z. Li 11 China Mobile 12 September 11, 2017 14 Static PCEP Link State 15 draft-chen-pce-pcc-ted-03 17 Abstract 19 This document presents extensions to the Path Computation Element 20 Communication Protocol (PCEP) for a PCC to advertise the information 21 about the links without running IGP and for a PCE to build a TED 22 based on the information received. 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 March 15, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . 3 61 4. Link Information . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Extension to Existing Message . . . . . . . . . . . . . . . 4 64 5.1.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 5 66 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.2.1. PCC Procedures . . . . . . . . . . . . . . . . . . . . 6 68 5.2.2. PCE Procedures . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Appendix A. New Message . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 A PCE architecture is described in RFC 4655, in which a Traffic 80 Engineering Database (TED) for a PCE is constructed based on the link 81 information from IGP (OSPF or IS-IS) running in the domain for which 82 the PCE is responsible. 84 For a domain without running IGP, the PCE responsible for the domain 85 may obtain the link information from a PCC running on each node in 86 the domain. 88 This document presents extensions to the Path Computation Element 89 Communication Protocol (PCEP) for a PCC to advertise the information 90 about the links attached to the node running the PCC and for a PCE to 91 build the TED based on the information received from the PCC. 93 2. Terminology 95 ABR: Area Border Router. Router used to connect two IGP areas 96 (Areas in OSPF or levels in IS-IS). 98 ASBR: Autonomous System (AS) Border Router. Router used to connect 99 together ASes via inter-AS links. 101 This document uses terminology defined in [RFC5440]. 103 3. Conventions Used in This Document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 4. Link Information 111 Since no IGP runs over any link, we may not obtain any link 112 information via IGP. But links are configured. 114 For a point-to-point (P2P) link between nodes A and B, from A's point 115 of view, we have the following link information: 117 1) Link Type: P2P 118 2) Local IP address 119 3) Remote IP address 120 4) Traffic engineering metric 121 5) Maximum bandwidth 122 6) Maximum reservable bandwidth 123 7) Unreserved bandwidth 124 8) Administrative group 125 9) SRLG 127 A link ID for the link is obtained if a user configures it; 128 otherwise, no link ID (i.e., the Router ID of A's neighbor) may be 129 obtained since no IGP adjacency over the link is formed. 131 For a broadcast link connecting multiple nodes, on each of the nodes 132 X, we have the same link information as above except for: 134 a) Link Type: Multi-access, 135 b) Local IP address with mask length, and 136 c) No Remote IP address. 138 In other words, the information about the broadcast link obtained by 139 node X comprises a), b), 4) to 9), but does not include any remote IP 140 address or link ID. A link ID for the link is obtained if a user 141 configures it; otherwise, no link ID (i.e., the interface address of 142 the designated router for the link) may be obtained since no IGP 143 selects it. 145 A PCE constructs a TED for its responsible domain after receiving the 146 link information from the PCC running on every node in the domain. 148 5. Extensions to PCEP 150 5.1. Extension to Existing Message 152 An existing Notification message may be extended to advertise the 153 information about links. Alternatively, a new message can be used 154 (refer to Appendix A). 156 The following new Notification-type (NT) and Notification-value (NV) 157 of a NOTIFICATION object in a Notification message are defined: 159 o NT=8 (TBD): Links 161 * NV=1: Update Links. NT=8 and NV=1 indicates that the PCC 162 requests the PCE to update the link information based on the 163 TLVs in the object, which are described below. 165 * NV=2: Withdraw Links. NT=8 and NV=2 indicates that the PCC 166 asks the PCE to remove the Links indicated by the TLVs in the 167 object. 169 5.1.1. TLVs 171 A link TLV and a Router-ID TLV are defined. The format of the link 172 TLV is illustrated below. The Type=tTBD1 indicates a link TLV Type. 173 The Length indicates the size of the Link Sub-TLVs. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type (tTBD1) | Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Link Sub-TLVs | 181 ~ ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 A link TLV describes a single link. It comprises a number of link 185 sub-TLVs for the information described in section 4, which are the 186 sub-TLVs defined in RFC 3630 or their equivalents except for the 187 local IP address with mask length defined below. 189 The format of the Router-ID TLV is shown below. The Type=tTBD2 190 indicates a Router-ID TLV Type. The Length indicates the size of the 191 ID and flags field. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type (tTBD2) | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |B|E|I| Flags | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 200 | 32-bit/48-bit ID ~ 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Flag B: Set to 1 indicating ABR (B is for Border) 203 Flag E: Set to 1 indicating ASBR (E is for External) 204 Flag I: Set to 1 indicating ID of local router (I is for ID) 206 Undefined flags MUST be set to zero. The ID indicates the ID of a 207 router. For a router not running IGP, the ID may be the 32-bit or 208 48-bit ID of the router configured. 210 5.1.2. Sub-TLVs 212 The format of the Sub-TLV for a local IPv4 address with mask length 213 is shown below. The Type=stTBD1 indicates a local IPv4 Address with 214 mask length. The Length indicates the size of the IPv4 address and 215 Mask Length. The IPv4 Address indicates the local IPv4 address of a 216 link. The Mask Length indicates the length of the IPv4 address mask. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type (stTBD1) | Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | IPv4 Address | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Mask Length | 226 +-+-+-+-+-+-+-+-+ 228 The format of the Sub-TLV for a local IPv6 address with mask length 229 is illustrated below. The Type=stTBD2 indicates a local IPv6 Address 230 with mask length. The Length indicates the size of the IPv6 address 231 and Mask Length. The IPv6 Address indicates the local IPv6 address 232 of a link. The Mask Length indicates the length of the IPv6 address 233 mask. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type (stTBD2) | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | IPv6 Address (16 bytes) | 241 ~ ~ 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Mask Length | 244 +-+-+-+-+-+-+-+-+ 246 5.2. Procedures 248 5.2.1. PCC Procedures 250 1. New or Changed Links 252 After the session between a PCC and a PCE is established, the PCC 253 sends the PCE a message containing the information about the links 254 attached to the node running the PCC. 256 For any new or changed links, the PCC sends the PCE a message 257 containing the information about these links with indication of 258 Update Links. 260 For example, for a new P2P link from node A, the PCC running on A 261 sends the PCE a Notification message having a NOTIFICATION object 262 with NT=8 and NV=1 (indicating Update Links), which contains a 263 Router-ID TLV, followed by a link TLV. The former comprises A's ID 264 and flag I set to 1. The latter comprises the Sub-TLVs for the 265 information described in section 4. 267 For multiple new or changed links from node A, the PCC running on A 268 sends the PCE a Notification message having a NOTIFICATION object 269 with NT=8 and NV=1, which contains a Router-ID TLV for A's ID, 270 followed by multiple link TLVs for the links. 272 2. Links Down 274 For links down, the PCC sends the PCE a message containing the 275 information about these links with indication of Withdraw Links. 277 For example, for multiple links from node A down, the PCC running on 278 A sends the PCE a Notification message having a NOTIFICATION object 279 with NT=8 and NV=2 (indicating Withdraw Links), which contains a 280 Router-ID TLV for A's ID, followed by multiple link TLVs for the 281 links. The TLV for a P2P link comprises the Sub-TLVs for the 282 information on 1), 2) and 3) described in section 4. The TLV for a 283 broadcast link comprises the Sub-TLVs for the information on a) and 284 b) described in section 4. 286 3. Simplified Message 288 Alternatively, the messages may be simplified. For each node, the 289 source IP address of the PCC running on the node may be used as the 290 ID of the node. The PCE knows the address after the session between 291 the PCE and the PCC is up. Thus, a message containing the 292 information about links does not need include any router-ID TLV. 294 For example, for a new P2P link attached to node A, the PCC running 295 on A sends the PCE a Notification message having a NOTIFICATION 296 object with NT=8 and NV=1 (indicating Update Links), which contains a 297 link TLV comprising the Sub-TLVs for the information on 1) to 9) 298 described in section 4. The object does not contain any Router-ID 299 TLV for node A. 301 5.2.2. PCE Procedures 303 A PCE stores into its TED the links for each node according to the 304 messages for the links received from the PCC running on the node. 305 For a message containing Update Links, it updates the links 306 accordingly. For a message containing Withdraw Links, it removes the 307 links. When a node is down, the PCE removes the links attached to 308 the node. 310 For a new P2P link between node A and B with no link ID configured, 311 when receiving a message containing the link from the PCC running on 312 A, the PCE stores the link for A (i.e., the link from A) into its 313 TED. It will find the link's remote end B using the remote IP 314 address of the link. After finding B, it associates the link for A 315 with B and the link for B with A. This creates a bidirectional 316 connection between A and B. 318 For a new broadcast link connecting multiple nodes with no link ID 319 configured, when receiving a message containing the link from the PCC 320 running on each of the nodes X, the PCE stores the link for X (i.e., 321 the link from X) into its TED. It will find the link's remote end P 322 using the link's local IP address with network mask. P is a Pseudo 323 node identified by the local IP address of the designated node 324 selected from the nodes connected to the link. After finding P, it 325 associates the link for X with P and the link for P with X. This 326 creates a bidirectional connection between X and P. 328 The first node and second node from which the PCE receives a message 329 containing the link is selected as the designed node and backup 330 designed node respectively. After the designed node is down, the 331 backup designed node becomes the designed node and the node other 332 than the designed node with the largest local IP address connecting 333 to the link is selected as the backup designed node. 335 When the old designed node is down and the backup designed node 336 becomes the new designed node, the PCE updates its TED through 337 removing the link between each of nodes X and old P (the Pseudo node 338 corresponding to the old designed node) and adding a link between 339 each of nodes X (still connecting to the broadcast link) and new P 340 (the Pseudo node corresponding to the new designed node). 342 6. Security Considerations 344 The mechanism described in this document does not raise any new 345 security issues for the PCEP protocols. 347 7. IANA Considerations 349 This section specifies requests for IANA allocation. 351 8. Acknowledgement 353 The authors would like to thank Jescia Chen, and Eric Wu for their 354 valuable comments on this draft. 356 9. References 357 9.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 361 RFC2119, March 1997, 362 . 364 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 365 Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ 366 RFC4655, August 2006, 367 . 369 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 370 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 371 DOI 10.17487/RFC5440, March 2009, 372 . 374 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 375 (TE) Extensions to OSPF Version 2", RFC 3630, 376 DOI 10.17487/RFC3630, September 2003, 377 . 379 9.2. Informative References 381 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 382 S. Ray, "North-Bound Distribution of Link-State and 383 Traffic Engineering (TE) Information Using BGP", RFC 7752, 384 DOI 10.17487/RFC7752, March 2016, 385 . 387 Appendix A. New Message 389 A new message may be defined to advertise the information on links. 390 The format of the message for the information on Links (IL for short) 391 is as follows: 393 ::= 394 where: 395 ::= [] 397 Where the value of the Message-Type in the Common Header indicates 398 the new message type. The exact value is to be assigned by IANA. A 399 new RP (NRP) object will be defined, which follows the Common Header. 401 A new flag W (Withdraw) in the NRP object is defined to indicate 402 whether the links are withdrawn. When flag W is set to one, the PCE 403 removes the links in the message after receiving it from the PCC. 405 When flag W is set to zero, the PCE adds/updates the links in the 406 message. 408 An alternative to flag W in the NRP object is a similar flag W in 409 each LINK object. For example, when the flag is set to one in the 410 LINK object, the PCE removes the links in the object. When the flag 411 is set to zero, the PCE adds/updates the links in the object. 413 The format of a LINK object body is as follows: 415 Object-Class = ocTBD1 (LINK) Object-Type = 1 (Link) 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |W| Flags | (Router-ID TLV) | 420 +-+-+-+-+-+-+-+-+ + 421 ~ ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Link TLVs | 424 ~ ~ 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Flag W=1 indicates Withdraw links. W=0 indicates Updated links. 428 Router-ID TLV is optional. Link TLVs are mandatory. They are the 429 same as described in section 5. 431 Authors' Addresses 433 Huaimo Chen 434 Huawei Technologies 435 Boston, MA, 436 USA 438 EMail: Huaimo.chen@huawei.com 440 Mehmet Toy 441 Verizon 442 USA 444 EMail: mehmet.toy@verizon.com 445 Xufeng Liu 446 Jabil 447 McLean, VA 448 USA 450 EMail: Xufeng_Liu@jabil.com 452 Lei Liu 453 Fujitsu 454 USA 456 EMail: lliu@us.fujitsu.com 458 Zhenqiang Li 459 China Mobile 460 No.32 Xuanwumenxi Ave., Xicheng District 461 Beijing 100032 462 P.R. China 464 EMail: li_zhenqiang@hotmail.com