idnits 2.17.1 draft-chen-pce-pcc-ted-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 (July 7, 2016) is 2821 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 371, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 388, 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 (~~), 5 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 July 7, 2016 5 Expires: January 8, 2017 7 Native PCE TED 8 draft-chen-pce-pcc-ted-00 10 Abstract 12 This document presents extensions to the Path Computation Element 13 Communication Protocol (PCEP) for a PCC to advertise the information 14 about the links and for a PCE to build a TED based on the information 15 received. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 8, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 54 4. Information on Link . . . . . . . . . . . . . . . . . . . . . 3 55 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. Extension to Existing Message . . . . . . . . . . . . . . 4 57 5.1.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.1.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.2.1. PCC Procedures . . . . . . . . . . . . . . . . . . . . 7 61 5.2.2. PCE Procedures . . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. New Message . . . . . . . . . . . . . . . . . . . . . 10 69 A.1. LINK Object . . . . . . . . . . . . . . . . . . . . . . . 10 70 A.2. TLVs in LINK Object . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 A PCE architecture is described in RFC 4655, in which the TED for a 75 PCE is constructed through using routing protocol such as OSPF or 76 IS-IS running in the domain for which the PCE is resposible. 78 For a domain without running OSPF or IS-IS, the PCE responsible for 79 the domain may obtain the inforamtion about the links from each of 80 the PCCs running on a node in the domain. 82 This document presents extensions to the Path Computation Element 83 Communication Protocol (PCEP) for a PCC to advertise the information 84 about the links attached to the node running the PCC and for a PCE to 85 build a TED based on the information received from the PCC. 87 2. Terminology 89 The following terminology is used in this document. 91 ABR: Area Border Router. Router used to connect two IGP areas 92 (Areas in OSPF or levels in IS-IS). 94 ASBR: Autonomous System Border Router. Router used to connect 95 together ASes of the same or different service providers via one 96 or more inter-AS links. 98 TED: Traffic Engineering Database. 100 This document uses terminology defined in [RFC5440]. 102 3. Conventions Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 4. Information on Link 110 Since there is no IGP running over any link, we may not obtain the 111 information about the link generated by an OSPF or IS-IS. We may 112 suppose that IP addresses are configured on links. 114 For a point-to-point link connecting two nodes A and B, from A's 115 point of view, the following information about the link may be 116 obtained: 118 1) Link Type: Point-to-point 119 2) Local IP address of the link 120 3) Remote IP address of the link 121 4) Traffic engineering metric of the link 122 5) Maximum bandwidth of the link 123 6) Maximum reservable bandwidth of the link 124 7) Unreserved bandwidth of the link 125 8) Administrative group of the link 127 Note that no link ID (i.e., the Router ID of the neighbor) may be 128 obtained since no IGP adjacency over the link is formed. 130 For a broadcast link connecting multiple nodes, on each of the nodes 131 X, the same information about the link as above may be obtained 132 except for the followings: 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), 5), 6), 7) and 8), but does not include 140 any remote IP address or link ID. Note that no link ID (i.e., the 141 interface address of the designated router for the link) may be 142 obtained since no IGP selects it. 144 A PCE constructs a TED for the domain for which the PCE is 145 responsible after receiving the information about each of the links 146 described above from the PCC running on every node in the domain plus 147 the node ID such as A's ID. 149 5. Extensions to PCEP 151 This section describes the extensions to PCEP to distribute the 152 information about links. 154 5.1. Extension to Existing Message 156 An existing Notification message may be extended to advertise the 157 information about links. Alternatively, a new message can be used 158 (refer to Appendix A). 160 The following new Notification-type (NT) and Notification-value (NV) 161 of a NOTIFICATION object in a Notification message are defined: 163 o NT=8 (TBD): Links 165 * NV=1: Updates on Links. A NT=8 and NV=1 indicates that the PCC 166 sends the PCE updates on the information about Links, and TLVs 167 containing the information are in the NOTIFICATION object. The 168 format and contents of the TLVs are described below. 170 * NV=2: Withdraw Links. A NT=8 and NV=2 indicates that the PCC 171 asks the PCE to remove Links indicated by the TLVs in the 172 object. 174 5.1.1. TLVs 176 Two TLVs are defined for the information on links. They are link TLV 177 and Router-ID TLV. 179 The format of the link TLV is illustrated below. The Type=tTBD1 180 indicates a link TLV Type. The Length indicates the size of the Link 181 Sub-TLVs. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type (tTBD1) | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Link Sub-TLVs | 189 ~ ~ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 A link TLV describes a single link. It comprises a number of link 193 sub-TLVs for the information described in section 4, which are the 194 sub-TLVs defined in RFC 3630 or their equivalents except for the 195 local IP address with mask length defined below. 197 The format of the Router-ID TLV is shown below. The Type=tTBD2 198 indicates a Router-ID TLV Type. The Length indicates the size of the 199 ID and flags field. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type (tTBD2) | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |B|E|I| Flags | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 208 | 32-bit/48-bit ID ~ 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Flag B: Set to 1 indicating ABR (B is for Border) 211 Flag E: Set to 1 indicating ASBR (E is for External) 212 Flag I: Set to 1 indicating ID of local router (I is for ID) 214 Undefined flags MUST be set to zero. The ID indicates the ID of a 215 router. For a router not running OSPF or IS-IS, the ID may be the 216 32-bit or 48-bit ID of the router configured. 218 5.1.2. Sub-TLVs 220 The format of the Sub-TLV for a local IPv4 address with mask length 221 is shown as follows. The Type=stTBD1 indicates a local IPv4 Address 222 with mask length. The Length indicates the size of the IPv4 address 223 and Mask Length. The IPv4 Address indicates the local IPv4 address 224 of a link. The Mask Length indicates the length of the IPv4 address 225 mask. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type (stTBD1) | Length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | IPv4 Address | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Mask Length | 235 +-+-+-+-+-+-+-+-+ 237 The format of the Sub-TLV for a local IPv6 address with mask length 238 is illustrated below. The Type=stTBD2 indicates a local IPv6 Address 239 with mask length. The Length indicates the size of the IPv6 address 240 and Mask Length. The IPv6 Address indicates the local IPv6 address 241 of a link. The Mask Length indicates the length of the IPv6 address 242 mask. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type (stTBD2) | Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | IPv6 Address (16 bytes) | 250 ~ ~ 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Mask Length | 253 +-+-+-+-+-+-+-+-+ 255 5.2. Procedures 257 5.2.1. PCC Procedures 259 1. New or Changed Links 261 After the session between a PCC and a PCE is established, the PCC 262 sends the PCE a message containing the information about the links 263 attached to the node running the PCC. 265 When there are changes on the links, the PCC sends the PCE a message 266 for the changed links. 268 For any new or changed links, the PCC sends the PCE a message 269 containing the information about these links with indication of 270 Updates on Links. 272 For example, for a new point-to-point link from node A to node B, the 273 PCC running on node A may send the PCE a Notification message having 274 a NOTIFICATION object with NT=8 and NV=1 (indicating Updates on 275 Links), which contains a Router-ID TLV, followed by a link TLV. The 276 Router-ID TLV comprises the ID of node A and flag I set to 1. The 277 link TLV comprises the Sub-TLVs for the information on 1) to 8) 278 described in section 4. 280 For multiple new or changed links from node A, the PCC running on A 281 may send the PCE a Notification message having a NOTIFICATION object 282 with NT=8 and NV=1, which contains a Router-ID TLV for the ID of node 283 A, followed by multiple link TLVs for the links from node A. Thus 284 this one message contains the information about multiple links. 286 2. Links Down 288 For any links down, the PCC sends the PCE a message containing the 289 information about these links with indication of Withdraw Links. 291 For example, for the point-to-point link from node A to node B down, 292 the PCC running on node A may send the PCE a Notification message 293 having a NOTIFICATION object with NT=8 and NV=2 (indicating Withdraw 294 Links), which contains a Router-ID TLV, followed by a link TLV. The 295 Router-ID TLV comprises the ID of node A and flag I set to 1. The 296 link TLV comprises the Sub-TLVs for the information on 1), 2) and 3) 297 described in section 4. 299 For multiple links from node A down, the PCC running on node A may 300 send the PCE a Notification message having a NOTIFICATION object with 301 NT=8 and NV=2, which contains a Router-ID TLV for the ID of node A, 302 followed by multiple link TLVs for the links from node A. The TLV for 303 a point-to-point link comprises the Sub-TLVs for the information on 304 1), 2) and 3) described in section 4. The TLV for a broadcast link 305 comprises the Sub-TLVs for the information on a) and b) described in 306 section 4. 308 3. Simplified Message 310 Alternatively, the messages may be simplified and the PCC procedures 311 may change accordingly. 313 For each node, the source IP address of the PCC running on the node 314 may be used as the ID of the node. The PCE knows the address after 315 the session between the PCE and the PCC is up. When the session 316 between the PCE and the PCC is established, the PCC may send the PCE 317 an ID of the node configured. Thus, a message containing the 318 information about links does not need include any router-ID TLV. 320 For example, for a new point-to-point link attached to node A, the 321 PCC running on node A sends the PCE a Notification message having a 322 NOTIFICATION object with NT=8 and NV=1 (indicating Updates on Links), 323 which contains a link TLV comprising the Sub-TLVs for the information 324 on 1) to 8) described in section 4. The object does not contain any 325 Router-ID TLV for node A. 327 In another example, for multiple links attached to node A down, the 328 PCC running on node A sends the PCE a Notification message having a 329 NOTIFICATION object with NT=8 and NV=2 (indicating Withdraw Links), 330 which contains multiple link TLVs for the links, but does not contain 331 any Router-ID TLV for node A. The TLV for a point-to-point link 332 comprises the Sub-TLVs for the information on 1), 2) and 3) described 333 in section 4. The TLV for a broadcast link comprises the Sub-TLVs 334 for the information on a) and b) described in section 4. 336 5.2.2. PCE Procedures 338 A PCE stores the links for each node according to the messages for 339 the links received from the PCC running on the node. For a message 340 containing updates on links, it updates the links accordingly. For a 341 message containing withdraw links, it removes the links. 343 When a node is down, the PCE removes the links attached to the node. 345 After receiving the messages for links from the PCCs, the PCE builds 346 and maintains a TED for the PCE's domain. 348 6. Security Considerations 350 The mechanism described in this document does not raise any new 351 security issues for the PCEP protocols. 353 7. IANA Considerations 355 This section specifies requests for IANA allocation. 357 8. Acknowledgement 359 The authors would like to thank Eric Wu and others for their valuable 360 comments on this draft. 362 9. References 364 9.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 368 RFC2119, March 1997, 369 . 371 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 372 Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ 373 RFC4655, August 2006, 374 . 376 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 377 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 378 DOI 10.17487/RFC5440, March 2009, 379 . 381 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 382 (TE) Extensions to OSPF Version 2", RFC 3630, 383 DOI 10.17487/RFC3630, September 2003, 384 . 386 9.2. Informative References 388 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 389 S. Ray, "North-Bound Distribution of Link-State and 390 Traffic Engineering (TE) Information Using BGP", RFC 7752, 391 DOI 10.17487/RFC7752, March 2016, 392 . 394 Appendix A. New Message 396 A new message may be defined to advertise the information on links. 397 The format of the message containing the inforamtion on Links (IL for 398 short) is as follows: 400 ::= 401 402 403 where: 404 ::= [] 406 Where the value of the Message-Type in the Common Header indicates 407 the new message type. The exact value is to be assigned by IANA. A 408 new RP (NRP) object will be defined, which follows the Common Header. 410 A new flag W (Withdraw) in the NRP object is defined to indicate 411 whether the links are withdrawn. When flag W is set to one, the PCE 412 removes the links contained in the message after receiving it from 413 the PCC. When flag W is set to zero, the PCE adds/updates the links 414 in the message. 416 An alternative to flag W in the NRP object is a similar flag in each 417 LINK object such as using one bit in Res flags for flag W. For 418 example, when the flag is set to one in the object, the PCE removes 419 the links in the object after receiving it. When the flag is set to 420 zero in the object, the PCE adds/updates the links in the object. 422 In another option, one byte in a LINK Object is defined as flags 423 field and one bit is used as flag W. The other undefined bits in the 424 flags field MUST be set to zero. 426 A.1. LINK Object 428 A new object, called LINK Object is defined. The format of LINK 429 object body is as follows: 431 Object-Class = ocTBD1 (LINK) 432 Object-Type = 1 (Link) 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |W| Flags | Router-ID TLV | 437 +-+-+-+-+-+-+-+-+ + 438 ~ ~ 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Link TLVs | 441 ~ ~ 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 The Router-ID TLV indicates a node in the domain, which is a local 445 end of links. Each of the Link TLVs describes a link and comprises a 446 number of link Sub-TLVs. Flag W=1 indicates withdraw the links. W=0 447 indicates new or changed links. 449 A.2. TLVs in LINK Object 451 The format of the Router-ID TLV is illustrated below: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type (tTBD1) | Length | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | 32-bit/48-bit ID ~ 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 The format of the link TLV is shown below: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type (tTBD2) | Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Link Sub-TLVs | 469 ~ ~ 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 The link sub-TLVs are for the information on a link described in 473 section 4, which are the sub-TLVs defined in RFC 3630 or their 474 equivalents except for local IP address with mask length. 476 Author's Address 478 Huaimo Chen 479 Huawei Technologies 480 Boston, MA, 481 USA 483 EMail: Huaimo.chen@huawei.com