idnits 2.17.1 draft-chen-pce-h-connect-access-10.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 lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 January 2022) is 809 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: 'RFC6805' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC5392' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC5316' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 502, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6805 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). 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 M. Toy 5 Expires: 14 July 2022 Verizon 6 X. Liu 7 Volta Networks 8 L. Liu 9 Fujitsu 10 Z. Li 11 China Mobile 12 10 January 2022 14 PCEP Link State Abstraction 15 draft-chen-pce-h-connect-access-10 17 Abstract 19 This document presents extensions to the Path Computation Element 20 Communication Protocol (PCEP) for a child PCE to abstract its domain 21 information to its parent for supporting a hierarchical PCE system. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 14 July 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 59 4. Connections and Accesses . . . . . . . . . . . . . . . . . . 3 60 4.1. Information on Inter-domain Link . . . . . . . . . . . . 4 61 4.2. Information on ABR . . . . . . . . . . . . . . . . . . . 5 62 4.3. Information on Access Point . . . . . . . . . . . . . . . 5 63 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Messages for Abstract Information . . . . . . . . . . . . 6 65 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.2.1. Child Procedures . . . . . . . . . . . . . . . . . . 6 67 5.2.2. Parent Procedures . . . . . . . . . . . . . . . . . . 9 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Message Encoding . . . . . . . . . . . . . . . . . . 12 75 A.1. Extension to Existing Message . . . . . . . . . . . . . . 12 76 A.1.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 12 77 A.1.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 13 78 A.2. New Message . . . . . . . . . . . . . . . . . . . . . . . 14 79 A.2.1. CONNECTION and ACCESS Object . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 A hierarchical PCE architecture is described in RFC 6805, in which a 85 parent PCE maintains an abstract domain topology, which contains its 86 child domains (seen as vertices in the topology) and the connections 87 among them. 89 For a domain for which a child PCE is responsible, connections 90 attached to the domain may comprise inter-domain links and Area 91 Border Routers (ABRs). For a parent PCE to have the abstract domain 92 topology, each of its child PCEs needs to advertise its connections 93 to the parent PCE. 95 In addition to the connections attached to the domain, there may be 96 some access points in the domain, which are the addresses in the 97 domain to be accessible outside of the domain. For example, an 98 address of a server in the domain that provides a number of services 99 to users outside of the domain is an access point. 101 This document presents extensions to the Path Computation Element 102 Communication Protocol (PCEP) for a child PCE to advertise the 103 information about its connections and access points to its parent PCE 104 and for the parent PCE to build and maintain the abstract domain 105 topology based on the information. The extensions may reduce 106 configurations, thus simplify operations on a PCE system. 108 A child PCE is simply called a child and a parent PCE is called a 109 parent in the following sections. 111 2. Terminology 113 ABR: Area Border Router. Router used to connect two IGP areas 114 (Areas in OSPF or levels in IS-IS). 116 ASBR: Autonomous System (AS) Border Router. Router used to connect 117 together ASes via inter-AS links. 119 TED: Traffic Engineering Database. 121 This document uses terminology defined in [RFC5440]. 123 3. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 4. Connections and Accesses 131 A connection is an inter-domain link between two domains in general. 132 An ABR is also a connection, which connects two special domains 133 called areas in a same Autonomous System (AS). 135 An access point in a domain is an address in the domain to be 136 accessible to the outside of the domain. An access point is simply 137 called an access. 139 4.1. Information on Inter-domain Link 141 An inter-domain link connects two domains in two different ASes. 142 Since there is no IGP running over an inter-domain link, we may not 143 obtain the information about the link generated by an IGP. We may 144 suppose that IP addresses are configured on inter-domain links. 146 For a point-to-point (P2P) link connecting two ABSRs A and B in two 147 different domains, from A's point of view, the following information 148 about the link may be obtained: 150 1) Link Type: P2P 151 2) Local IP address 152 3) Remote IP address 153 4) Traffic engineering metric 154 5) Maximum bandwidth 155 6) Maximum reservable bandwidth 156 7) Unreserved bandwidth 157 8) Administrative group 158 9) SRLG 160 We will have a link ID if it is configured; otherwise no link ID 161 (i.e., the Router ID of the neighbor) may be obtained since no IGP 162 adjacency over the link is formed. 164 For a broadcast link connecting multiple ASBRs in a number of 165 domains, on each of the ASBRs X, the same information about the link 166 as above may be obtained except for the followings: 168 a) Link Type: Multi-access, 169 b) Local IP address with mask length, and 170 c) No Remote IP address. 172 In other words, the information about the broadcast link obtained by 173 ASBR X comprises a), b), 4) to 9), but does not include any remote IP 174 address or link ID. We will have a link ID if it is configured; 175 otherwise no link ID (i.e., the interface address of the designated 176 router for the link) may be obtained since no IGP selects it. 178 A parent constructs an abstract AS domain topology after receiving 179 the information about each of the inter-domain links described above 180 from its children. 182 RFC 5392 and RFC 5316 describe the distributions of inter-domain 183 links in OSPF and IS-IS respectively. For each inter-domain link, 184 its neighboring AS number and neighboring ASBR Identity (TE Router 185 ID) need to be configured in IGP (OSPF or IS-IS). 187 In addition, an IGP adjacency between a network node running IGP and 188 a PCE running IGP as a component needs to be configured and fully 189 established if we want the PCE to obtain the inter-domain link 190 information from IGP. 192 These configurations and IGP adjacency establishment are not needed 193 if the extensions in this draft are used. 195 RFC 7752 (BGP-LS) describes the distributions of TE link state 196 information including inter-domain link state. A BGP peer between a 197 network node running BGP and a PCE running BGP as a component needs 198 to be configured and the peer relation must be established before the 199 PCE can obtain the inter-domain link information from BGP. However, 200 some networks may not run BGP. 202 4.2. Information on ABR 204 For an AS running IGP and containing multiple areas, an ABR connects 205 two or more areas. For each area connected to the ABR, the PCE as a 206 child responsible for the area sends its parent the information about 207 the ABR, which indicates the identifier (ID) of the ABR. 209 A parent has the information about each of its children, which 210 includes the domain such as the area for which the child is 211 responsible. The parent knows all the areas to which each ABR 212 connects after receiving the information on the ABR from each of its 213 children. 215 4.3. Information on Access Point 217 For an IP address in a domain to be accessible outside of the domain, 218 the PCE as a child responsible for the domain sends its parent the 219 information about the address. 221 The parent has all the access points (i.e., IP addresses) to be 222 accessible outside of all its children' domains after receiving the 223 information on the access points from each of its children. 225 5. Extensions to PCEP 227 This section focuses on procedures for abstracting domain information 228 after briefing messages containing the abstract information. 230 5.1. Messages for Abstract Information 232 A child abstracts its domain to its parent through sending its parent 233 a message containing the abstract information on the domain. After 234 the relation between the child and the parent is determined, the 235 parent has some information on the child, which includes the child's 236 ID and domain. The message does not need to contain this 237 information. It comprises the followings: 239 o For new or updated Connections and Accesses, 241 * Indication of Update Connections and Accesses 243 * Detail Information about Connections and Accesses 245 o For Connections and Accesses down, 247 * Indication of Withdraw Connections and Accesses 249 * ID Information about Connections and Accesses 251 For a P2P link from ASBR A to B and a broadcast link connecting to A, 252 the detail information on the links includes A's ID, the information 253 on the P2P link and the information on the broadcast link described 254 in Section 4. The ID information on the links includes A's ID, 1) to 255 3) for the P2P link and a) to b) for the broadcast link described in 256 Section 4. A link ID for a link is included if it is configured. 258 For an ABR X, the information on X includes X's ID and a flag 259 indicating that X is ABR. 261 For an Access X (address), the detail information on X includes X and 262 a cost associated with it. The ID information on X is X itself. 264 There are a few ways to encode the information above into a message. 265 For example, one way is to extend an existing Notification message 266 for including the information. Another way is to use a new message. 267 These are put in Appendix A for your reference. 269 5.2. Procedures 271 5.2.1. Child Procedures 272 5.2.1.1. New or Changed Connections and Accesses 274 After a child determines its parent, it sends the parent a message 275 containing the information about the connections (i.e., inter-domain 276 links and ABRs) from its domain to its adjacent domains and the 277 access points in its domain. 279 For any new or changed inter-domain links, ABRs and access points in 280 the domain for which a child is responsible, the child sends its 281 parent a message containing the information about these links, ABRs 282 and access points with indication of Update Connections and Accesses. 284 For example, for a new inter-domain P2P link from ASBR A in a child's 285 domain to ASBR B in another domain, the child sends its parent a 286 message containing an indication of Update Connections and Accesses, 287 A's ID, and the detail information on the link described in section 288 4.1. 290 For multiple new or changed inter-domain links from ASBR A, the child 291 sends its parent a message having an indication of Update Connections 292 and Accesses, and A's ID followed by the detail information about 293 each of the links. 295 In another example, for a new or changed inter-domain broadcast link 296 connected to ASBR X, an ABR Y and an access point 10.10.10.1/32 with 297 cost 10 in a child's domain, the child sends its parent a message 298 containing an indication of Update Connections and Accesses, and X's 299 ID followed by the detail information about the link attached to X 300 and the detail information about ABR Y, and the information on access 301 10.10.10.1/32 with cost 10. 303 For changes on the attributes (such as bandwidth) of an inter-domain 304 link, a threshold may be used to control the frequency of updates 305 that are sent from a child to its parent. At one extreme, the 306 threshold is set to let a child send its parent a update message for 307 any change on the attributes of an inter-domain link. At another 308 extreme, the threshold is set to make a child not to send its parent 309 any update message for any change on the attributes of an inter- 310 domain link. Typically, the threshold is set to allow a child to 311 send its parent a update message for a significant change on the 312 attributes of an inter-domain link. 314 5.2.1.2. Connections and Accesses Down 316 For any inter-domain links, ABRs and access points down in the domain 317 for which a child is responsible, the child sends its parent a 318 message containing the information about these links, ABRs and access 319 points with indication of Withdraw Connections and Accesses. 321 For example, for the inter-domain P2P link from ASBR A down, the 322 child sends its parent a message containing an indication of Withdraw 323 Connections and Accesses, and A's ID, which is followed by the ID 324 information about the link. 326 For multiple inter-domain links from ASBR A down, the child sends its 327 parent a message having an indication of Withdraw Connections and 328 Accesses, and A's ID, which is followed by the ID information about 329 each of the links. 331 5.2.1.3. Child and Parent in Same Organization 333 If a child and its parent are in a same organization, the child may 334 send its parent the information inside its domain. For a parent, 335 after all its children in its organization send their parent the 336 information in their domains, connections and access points, it has 337 in its TED the detail information inside each of its children's 338 domains and the connections among these domains. The parent can 339 compute a path crossing these domains directly and efficiently 340 without sending any path computation request to its children. 342 5.2.1.4. Child as a Parent 344 There are a few ways in which a child as a parent abstracts its 345 domain information to its parent. 347 One way is that the child sends its parent all its domain information 348 if the child and the parent are in a same organization. The 349 information includes the detail network topology inside each of the 350 child's domains, the inter-domain links connecting the domains that 351 the child's children are responsible and the inter-domain links 352 connecting these domains to other adjacent domains. 354 In another way, the child abstracts each of the domains that its 355 children are responsible as a cloud (or say abstract node) and these 356 clouds are connected by the inter-domain links attached to the 357 domains. The child sends its parent all the inter-domain links 358 attached to any of the domains. 360 In a third way, the child abstracts all its domains including the 361 domains for which its children are responsible as a cloud. This 362 abstraction is described below in details. 364 If a parent P1 is also a child of another parent P2, P1 as a child 365 sends its parent P2 a message containing the information about the 366 connections and access points. P1 as a parent has the connections 367 among its children's domains. But these connections are hidden from 368 its parent P2. P1 may have connections from its children's domains 369 to other domains. P1 as a child sends its parent P2 these 370 connections. 372 P1 as a parent has the access points in its children's domains to be 373 accessible outside of the domains. P1 as child may not send all of 374 these to its parent P2. It sends its parent some of these access 375 points according to some local policies. 377 From P2's point of view, its child P1 is responsible for one domain, 378 which has some connections to its adjacent domains and some access 379 points to be accessible. 381 5.2.2. Parent Procedures 383 5.2.2.1. Process Connections and Accesses 385 A parent stores into its TED the connections and accesses for each of 386 its children according to the messages containing connections and 387 accesses received. For a message containing Update Connections and 388 Accesses, it updates the connections and accesses in the TED 389 accordingly. For a message containing Withdraw Connections and 390 Accesses, it removes the connections and accesses from the TED. 392 After receiving the messages for connections and accesses from its 393 children, the parent builds and maintains the TED for the topology of 394 its children's domains, in which each of the domains is seen as a 395 cloud or an abstract node. The information inside each of the 396 domains is hidden from the parent. There are connections among the 397 domains and the access points in the domains to be accessible in the 398 topology. 400 For a new P2P link from node A to B with no link ID configured, when 401 receiving a message containing the link from a child, the parent 402 stores the link from A into its TED, where A is attached to the 403 child's domain as a cloud. It finds the link's remote end B using 404 the remote IP address of the link. After finding B, it associates 405 the link attached to A with B and the link attached to B with A. 406 This creates a bidirectional connection between A and B. 408 For a new P2P link from node A to B with link ID configured, when 409 receiving a message containing the link, the parent stores the link 410 from A into its TED. It finds the link's remote end B using the link 411 ID (i.e., B's ID). 413 For a new broadcast link connecting multiple nodes with no link ID 414 configured, when the parent receives a message containing the link 415 attached to node X, it stores the link from X into its TED. It finds 416 the link's remote end P using the link's local IP address with 417 network mask. P is a Pseudo node identified by the local IP address 418 of the designated node selected from the nodes connected to the link. 419 After finding P, it associates the link attached to X with P and the 420 link connected to P with X. If P is not found, a new Pseudo node P 421 is created. The parent associates the link attached to X with P and 422 the link attached to P with X. This creates a bidirectional 423 connection between X and P. 425 The first node and second node from which the parent receives a 426 message containing the link is selected as the designed node and 427 backup designed node respectively. After the designed node is down, 428 the backup designed node becomes the designed node and the node other 429 than the designed node with the largest local IP address connecting 430 to the link is selected as the backup designed node. 432 When the old designed node is down and the backup designed node 433 becomes the new designed node, the parent updates its TED through 434 removing the link between each of nodes X and old P (the Pseudo node 435 corresponding to the old designed node) and adding a link between 436 each of nodes X (still connecting to the broadcast link) and new P 437 (the Pseudo node corresponding to the new designed node). 439 5.2.2.2. Detail Topology in a Domain 441 If a parent is in a same organization as its child, it stores into 442 its TED the detail information inside the child's domain when 443 receiving a message containing the information from the child; 444 otherwise, it discards the information and issues a warning 445 indicating that the information is sent to a wrong place. 447 6. Security Considerations 449 The mechanism described in this document does not raise any new 450 security issues for the PCEP protocols. 452 7. IANA Considerations 454 This section specifies requests for IANA allocation. 456 8. Acknowledgement 458 The authors would like to thank Jescia Chen, Adrian Farrel, and Eric 459 Wu for their valuable comments on this draft. 461 9. References 463 9.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, 467 DOI 10.17487/RFC2119, March 1997, 468 . 470 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 471 Path Computation Element Architecture to the Determination 472 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 473 DOI 10.17487/RFC6805, November 2012, 474 . 476 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 477 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 478 DOI 10.17487/RFC5440, March 2009, 479 . 481 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 482 (TE) Extensions to OSPF Version 2", RFC 3630, 483 DOI 10.17487/RFC3630, September 2003, 484 . 486 9.2. Informative References 488 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 489 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 490 2008, . 492 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 493 Support of Inter-Autonomous System (AS) MPLS and GMPLS 494 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 495 January 2009, . 497 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 498 Support of Inter-Autonomous System (AS) MPLS and GMPLS 499 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 500 December 2008, . 502 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 503 S. Ray, "North-Bound Distribution of Link-State and 504 Traffic Engineering (TE) Information Using BGP", RFC 7752, 505 DOI 10.17487/RFC7752, March 2016, 506 . 508 Appendix A. Message Encoding 510 A.1. Extension to Existing Message 512 An existing Notification message may be extended to advertise the 513 information about connections and access points. The following new 514 Notification-type (NT) and Notification-value (NV) of a NOTIFICATION 515 object in the message are defined: 517 o NT=8 (TBD): Connections and Accesses 519 * NV=1: Update Connections and Accesses. A NT=8 and NV=1 520 indicates that the child sends its parent updates on the 521 information about Connections and Accesses, and TLVs containing 522 the information are in the object. 524 * NV=2: Withdraw Connections and Accesses. A NT=8 and NV=2 525 indicates that the child asks its parent to remove Connections 526 and Accesses indicated by TLVs in the object. 528 A.1.1. TLVs 530 Four TLVs are defined for connections and accesses. They are Inter- 531 Domain link TLV, Router-ID TLV, Access IPv4/IPv6 Prefix TLV. 533 The format of the Inter-Domain link TLV is illustrated below. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type (tTBD1) | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Inter-Domain Link Sub-TLVs | 541 ~ ~ 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 An Inter-Domain link TLV describes a single inter-domain link. It 545 comprises a number of inter-domain link sub-TLVs for the information 546 described in section 4, which are the sub-TLVs defined in RFC 3630 or 547 their equivalents except for the local IP address with mask length 548 defined below. 550 The format of the Router-ID TLV is shown below. Undefined flags MUST 551 be set to zero. The ID indicates the ID of a router. For a router 552 running OSPF, the ID may be the 32-bit OSPF router ID of the router. 553 For a router running IS-IS, the ID may be the 48-bit IS-IS router ID 554 of the router. For a router not running OSPF or IS-IS, the ID may be 555 the 32-bit ID of the router configured. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type (tTBD2) | Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |B|E|I| Flags | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 564 | 32-bit/48-bit ID ~ 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Flag B: Set to 1 indicating ABR (B is for Border) 567 Flag E: Set to 1 indicating ASBR (E is for External) 568 Flag I: Set to 1 indicating ID of local router (I is for ID) 570 The format of the Access IPv4/IPv6 Prefix TLV is shown as follows. 571 The cost is the metric to the prefix. The Prefix Length indicates 572 the length of the prefix. The IPv4/IPv6 Prefix indicates an access 573 IPv4/IPv6 address prefix. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type (tTBD3/tTDB4) | Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | cost | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Prefix Length | IPv4/IPv6 Prefix (variable) ~ 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 A.1.2. Sub-TLVs 587 The format of the Sub-TLV for a local IPv4/IPv6 address with mask 588 length is shown as follows. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type (stTBD1/stTBD2) | Length | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | IPv4/IPv6 Address ~ 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Mask Length | 598 +-+-+-+-+-+-+-+-+ 600 The IPv4/IPv6 Address indicates the local IPv4/IPv6 address of a 601 link. The Mask Length indicates the length of the IPv4/IPv6 address 602 mask. 604 A.2. New Message 606 A new message may be defined to advertise the connections and 607 accesses from a child to its parent. The format of the message 608 containing Connections and Access (AC for short) is as follows: 610 ::= 611 [] 612 where: 613 ::= [] 614 ::= [ | ] 615 ::= [] 617 Where the value of the Message-Type in the Common Header indicates 618 the new message type. The exact value is to be assigned by IANA. A 619 new RP (NRP) object will be defined, which follows the Common Header. 621 A new flag W (Withdraw) in the NRP object is defined to indicate 622 whether the connections and access are withdrawn. When flag W is set 623 to one, the parent removes the connections and accesses contained in 624 the message after receiving it. When flag W is set to zero, the 625 parent adds/updates the connections and accesses in the message after 626 receiving it. 628 An alternative to flag W in the NRP object is a similar flag in each 629 CONNECTION and ACCESS object such as using one bit in Res flags for 630 flag W. For example, when the flag is set to one in the object, the 631 parent removes the connections and accesses in the object after 632 receiving it. When the flag is set to zero in the object, the parent 633 adds/updates the connections and accesses in the object after 634 receiving it. 636 In another option, one byte in a CONNECTION and ACCESS Object is 637 defined as flags field and one bit is used as flag W. The other 638 undefined bits in the flags field MUST be set to zero. 640 The objects in the new message are defined below. 642 A.2.1. CONNECTION and ACCESS Object 644 A new object, called CONNECTION and ACCESS Object (CA for short), is 645 defined. It has Object-Class ocTBD1. Four Object-Types are defined 646 under CA object: 648 o CA Inter-Domain Link: CA Object-Type is 1. 650 o CA ABR: CA Object-Type is 2. 652 o CA Access IPv4 Prefix: CA Object-Type is 3. 654 o CA Access IPv6 Prefix: CA Object-Type is 4. 656 Each of these objects are described below. 658 The format of Inter-Domain Link object body is as follows: 660 Object-Class = ocTBD1 (Connection and Access) 661 Object-Type = 1 (CA Inter-Domain Link) 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |W| Flags | Router-ID TLV | 666 +-+-+-+-+-+-+-+-+ + 667 ~ ~ 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Inter-Domain Link TLVs | 670 ~ ~ 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 The Router-ID TLV indicates an ASBR in the domain, which is a local 674 end of inter-domain links. Each of the Inter-Domain Link TLVs 675 describes an inter-domain link and comprises a number of inter-domain 676 link Sub-TLVs. Flag W=1 indicates withdraw the links. W=0 indicates 677 new or changed links. 679 The format of ABR object body is illustrated below: 681 Object-Class = ocTBD1 (Connection and Access) 682 Object-Type = 2 (CA ABR) 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 |W| Flags | Router-ID TLVs | 687 +-+-+-+-+-+-+-+-+ + 688 ~ ~ 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 Each of the Router-ID TLVs indicates an ABR in the domain. Flag W=1 692 indicates withdraw the ABRs. W=0 indicates new ABRs. 694 The format of Access IPv4/IPv6 Prefix object body is as follows: 696 Object-Class = ocTBD1 (Connection and Access) 697 Object-Type = 3/4 (CA Access IPv4/IPv6 Prefix) 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 |W| Flags | Access IPv4/IPv6 Prefix TLVs | 702 +-+-+-+-+-+-+-+-+ + 703 ~ ~ 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Each of the Access IPv4/IPv6 Prefix TLVs describes an access IPv4/ 707 IPv6 address prefix in the domain, which is accessible to outside of 708 the domain. Flag W=1 indicates withdraw the address prefixes. W=0 709 indicates new address prefixes. 711 The TLVs in the objects are the same as those described above. 713 Authors' Addresses 715 Huaimo Chen 716 Futurewei 717 Boston, MA, 718 United States of America 720 Email: Huaimo.chen@futurewei.com 721 Mehmet Toy 722 Verizon 723 United States of America 725 Email: mehmet.toy@verizon.com 727 Xufeng Liu 728 Volta Networks 729 McLean, VA 730 United States of America 732 Email: xufeng.liu.ietf@gmail.com 734 Lei Liu 735 Fujitsu 736 United States of America 738 Email: liulei.kddi@gmail.com 740 Zhenqiang Li 741 China Mobile 742 No.32 Xuanwumenxi Ave., Xicheng District 743 Beijing 744 100032 745 P.R. China 747 Email: li_zhenqiang@hotmail.com