idnits 2.17.1 draft-chen-idr-com-cntlrs-01.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 5 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 (January 5, 2017) is 2666 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: 'IEEE.754.1985' is mentioned on line 3049, but not defined == Missing Reference: 'RFC3471' is mentioned on line 3050, but not defined == Unused Reference: 'RFC1771' is defined on line 3306, but no explicit reference was found in the text == Unused Reference: 'RFC2842' is defined on line 3310, but no explicit reference was found in the text == Unused Reference: 'RFC3107' is defined on line 3319, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 3328, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 3334, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 3344, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 3354, but no explicit reference was found in the text == Unused Reference: 'RFC5392' is defined on line 3358, but no explicit reference was found in the text == Unused Reference: 'RFC5316' is defined on line 3363, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 3368, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 3372, but no explicit reference was found in the text == Unused Reference: 'RFC1136' is defined on line 3379, but no explicit reference was found in the text == Unused Reference: 'RFC6805' is defined on line 3384, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2842 (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group H. Chen 3 Internet-Draft S. Hares 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 9, 2017 Y. Yang 6 Sockrate 7 Y. Fan 8 Casa Systems, Inc. 9 M. Toy 10 Verizon 11 Z. Li 12 China Mobile 13 L. Liu 14 Fujitsu 15 January 5, 2017 17 BGP for Communications among Controllers 18 draft-chen-idr-com-cntlrs-01 20 Abstract 22 This document describes extensions to the BGP routing protocol for 23 supporting communications among SDN controllers in a centralized 24 control system, which comprises multiple SDN controllers controlling 25 a network with a number of domains. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 9, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conventions Used in This Document . . . . . . . . . . . . . . 6 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Overview of SDN Control System . . . . . . . . . . . . . . . . 6 66 5.1. Hierarchical SDN Control System . . . . . . . . . . . . . 6 67 5.2. Distributed SDN Control System . . . . . . . . . . . . . . 8 68 6. Extensions to BGP . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Capability and Controller Discovery . . . . . . . . . . . 10 70 6.1.1. Capability Discovery . . . . . . . . . . . . . . . . . 10 71 6.1.2. Controller Relation Discovery . . . . . . . . . . . . 11 72 6.2. Messages for SDN Control System . . . . . . . . . . . . . 14 73 6.2.1. Overview of Messages . . . . . . . . . . . . . . . . . 14 74 6.2.2. Messages for Hierarchical SDN Control System . . . . . 17 75 6.2.3. Messages for Distributed SDN Control System . . . . . 24 76 6.3. Connections and Accesses Advertisement . . . . . . . . . . 29 77 6.3.1. Advertisement in Hierarchical SDN Control System . . . 29 78 6.3.2. Advertisement in Distributed SDN Control System . . . 30 79 6.4. Tunnel Creation . . . . . . . . . . . . . . . . . . . . . 31 80 6.4.1. Tunnel Creation in Hierarchical SDN Control System . . 31 81 6.4.2. Tunnel Creation in Distributed SDN Control System . . 35 82 6.5. Transporting SDN Information in BGP . . . . . . . . . . . 39 83 6.5.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . 39 84 6.5.2. SDN NLRIs . . . . . . . . . . . . . . . . . . . . . . 39 85 6.5.3. Controller Request Parameters TLV . . . . . . . . . . 47 86 6.5.4. CONNECTION and ACCESS TLVs . . . . . . . . . . . . . . 51 87 6.5.5. NODE TLVs . . . . . . . . . . . . . . . . . . . . . . 59 88 6.5.6. TUNNEL-ID-Info TLV . . . . . . . . . . . . . . . . . . 66 89 6.5.7. STATUS TLV . . . . . . . . . . . . . . . . . . . . . . 66 90 6.5.8. LABEL TLV . . . . . . . . . . . . . . . . . . . . . . 67 91 6.5.9. INTERFACE TLVs . . . . . . . . . . . . . . . . . . . . 67 92 6.5.10. CONSTRAINS TLVs . . . . . . . . . . . . . . . . . . . 68 93 6.5.11. SPT TLV . . . . . . . . . . . . . . . . . . . . . . . 70 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 74 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 96 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 74 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 74 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 76 101 1. Introduction 103 A domain is a collection of network elements within a common sphere 104 of address management or routing procedure which are operated by a 105 single organization or administrative authority. Examples of such 106 domains include IGP (OSPF or IS-IS) areas and Autonomous Systems. 108 A network running BGP is organized as multiple Autonomous Systems, 109 each of which has a number of IGP areas. 111 The concepts of Software Defined Networks (SDN) have been shown to 112 reduce the overall network CapEx and OpEx, whilst facilitating the 113 deployment of services and enabling new features. The core 114 principles of SDN include: centralized control to allow optimized 115 usage of network resources and provisioning of network elements 116 across domains. 118 For a network with a number of domains, it is natural to have 119 multiple SDN controllers. each of the domains in the network is 120 controlled by a controller. There are a few of architectures of 121 controllers for achieving a centralized control on the network. One 122 is a hierarchical architecture, another is a distributed architecture 123 of controllers. A third one is a hybrid of a hierarchical and a 124 distributed architecture of controllers. 126 At top level of a hierarchical architecture, it is a parent 127 controller that is not a child controller. The parent controller 128 controls a number of child controllers. Some of these child 129 controllers are not parent controllers. Each of them controls a 130 domain. Some other child controllers are also parent controllers, 131 each of which controls multiple child controllers, and so on. 133 In a distributed architecture of controllers, there are a number of 134 controllers, each of which controls a domain in a network with 135 multiple domains and is adjacent to some of the other controllers. 136 They control the network through their coordination. 138 This document describes extensions to the BGP routing protocol for 139 supporting communications among SDN controllers in a centralized 140 control system, which comprises multiple SDN controllers controlling 141 a network with a number of domains. 143 2. Terminology 145 The following terminology is used in this document. 147 ABR: Area Border Router. Router used to connect two IGP areas 148 (Areas in OSPF or levels in IS-IS). 150 ASBR: Autonomous System Border Router. Router used to connect 151 together ASes of the same or different service providers via one 152 or more inter-AS links. 154 BN: Boundary Node. A boundary node is either an ABR in the context 155 of inter-area Traffic Engineering or an ASBR in the context of 156 inter-AS Traffic Engineering. A Boundary Node is also called an 157 Edge Node. 159 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) 160 along the path found from the source node to the BN, where 161 domain(n-1) is the previous hop (or upstream) domain of domain(n). 162 An Entry BN is also called an in-BN or in-edge node. 164 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 165 the path found from the source node to the BN, where domain(n+1) 166 is the next hop (or downstream) domain of domain(n). An Exit BN 167 is also called a out-BN or out-edge node. 169 Source Domain: For a tunnel from a source to a destination, the 170 domain containing the source is the source domain for the tunnel. 172 Destination Domain: For a tunnel from a source to a destination, the 173 domain containing the destination is the destination domain for 174 the tunnel. 176 Source Controller: A controller controlling the source domain. 178 Destination Controller: A controller controlling the destination 179 domain. 181 Parent Controller: A parent controller is a controller that 182 communicates with a number of child controllers and controls a 183 network with multiple domains through the child controllers. A 184 BGP can be enhanced to be a parent controller. 186 Child Controller: A child controller is a controller that 187 communicates with one parent controller and controls a domain in a 188 network. A BGP can be enhanced to be a child controller. 190 Exception list: An exception list for a domain contains the nodes in 191 the domain and its adjacent domains that are on the shortest path 192 tree (SPT) that the parent controller is building. 194 GTID: Global Tunnel Identifier. It is used to identify a tunnel in 195 a network. 197 GPID: Global Path Identifier. It is used to identify a path for a 198 tunnel in a network. 200 Inter-area TE LSP: a TE LSP that crosses an IGP area boundary. 202 Inter-AS TE LSP: a TE LSP that crosses an AS boundary. 204 LSP: Label Switched Path 206 LSR: Label Switching Router 208 TED: Traffic Engineering Database. 210 This document uses terminology defined in [RFC2858]. 212 3. Conventions Used in This Document 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 4. Requirements 220 This section summarizes the requirements for Hierarchical SDN Control 221 System (need more text here). 223 5. Overview of SDN Control System 225 5.1. Hierarchical SDN Control System 227 The Figure below illustrates a hierarchical SDN control system. 228 There is one Parent Controller and four Child Controllers: Child 229 Controller 1, Child Controller 2, Child Controller 3 and Child 230 Controller 4. 232 +-------------------+ 233 | Parent Controller | 234 +--+---------+----+-+ 235 _/| \ \____ 236 _/ | \ \____ 237 _/ | \ \__ 238 __/ | +---------+---------+ \ 239 __/ | |Child Controller 3 | | 240 / | +-------------------+ | 241 +---------+---------+ | / \ | 242 |Child Controller 1 | | .---. .---,\ | 243 +-------------------+ | ( ' ') | 244 / \ | ( Domain 3 ) | 245 .---. .---,\ | ( ) +---------+---------+ 246 ( ' ') | '-o-.--o) |Child Controller 4 | 247 ( Domain 1 ) | | +-------------------+ 248 ( ) | | / \____ 249 '-o-.---) +--------+----------+ \ / \ \____ 250 | |Child Controller 2 | \ /\ .---. .---+ \ 251 | +-------------------+ \ | \( ' |'.---. | 252 | / \____ \_ |---\ Domain 4 | '+, 253 \ / \ \____ (o \ | | ) 254 \ /\ .---. .---+ \ ( | | o) 255 \ | \( ' |'.---. | ( | | ) 256 \ |---\ Domain 2 | '+. ( o o .-' 257 \____(o \ | | ) ' ) 258 ( | | o)-------o---._.-.-----) 259 ( | | ) 260 ( o o .-' 261 ' ) 262 '---._.-.-----) 264 The parent controller communicates with its four child controllers 265 and controls them, each of which controls (or is responsible for) a 266 domain. Child controller 1 controls domain 1, Child controller 2 267 controls domain 2, Child controller 3 controls domain 3, and Child 268 controller 4 controls domain 4. 270 One level of hierarchy of controllers is illustrated in the figure 271 above. There is one parent controller at top level, which is not a 272 child controller. Under the parent controller, there are four child 273 controllers, which are not parent controllers. 275 In a general case, at top level there is one parent controller that 276 is not a child controller, there are some controllers that are both 277 parent controllers and child controllers, and there are a number of 278 child controllers that are not parent controllers. This is a system 279 of multiple levels of hierarchies, in which one parent controller 280 controls or communicates with a first number of child controllers, 281 some of which are also parent controllers, each of which controls or 282 communicates with a second number of child controllers, and so on. 284 The parent controller at top level has a level of 0. For a parent 285 controller, which is a child controller of another parent controller 286 having a level of N, this parent controller has a level of (N + 1). 288 Considering one parent controller and its child controllers, each of 289 the child controllers controls a domain and has the topology 290 information on the domain, the parent controller does not have the 291 topology information on any domain controlled by a child controller 292 normally. This is called a parent without domain topology. 294 In some special cases, the parent controller has the topology 295 information on a region consisting of the domains controlled by its 296 child controllers. In other words, the parent controller has the 297 topology information on the domains controlled by its child 298 controllers and the topology/inter-connections among these domains. 299 This is called a parent with domain topology. 301 The parent controller receives requests for creating end to end 302 tunnels from users or applications. For each request, the parent 303 controller computes a path for the tunnel and creates the tunnel 304 along the path. 306 For a parent without domain topology, the parent controller asks each 307 of its related child controllers to compute path segments from an 308 entry boundary node to exit boundary nodes in the domain it controls 309 or path segments from an exit boundary node in its domain to entry 310 boundary nodes of other adjacent domains just using the inter-domain 311 links attached to the exit boundary node. The parent controller 312 builds a shortest path tree (SPT) using the path segments computed as 313 links to get the end to end path and then creates the tunnel along 314 the path by asking its related child controllers. 316 For a parent with domain topology, the parent controller computes a 317 path for the tunnel using the topology information on the domains 318 controlled by its child controllers. And then it creates the tunnel 319 along the path computed through asking its related child controllers. 321 5.2. Distributed SDN Control System 323 The Figure below illustrates a distributed SDN control system. There 324 are four Distributed Controllers: Distributed Controller 1, 325 Distributed Controller 2, Distributed Controller 3 and Distributed 326 Controller 4, which control Domain 1, Domain 2, Domain 3 and Domain 4 327 respectively. 329 +-------------------+ 330 _______________| Distributed | 331 / | Controller 1 | 332 / +-------------------+ 333 +--------+---------+ / / \ \ 334 | Distributed | / .---. .---,\ \ 335 | Controller 2 | | ( ' ) \ 336 +------------------+ | ( ') \ 337 / \ | | ( Domain 1 ) | 338 .---. .---,\ | | ( ) +--------+--------+ 339 ( ' ') | | '-o-.--o) | Distributed | 340 ( ) | | | | Controller 4 | 341 ( Domain 2 ) | | +---|-----+-----------------+ 342 ( ) | | | | / \____ 343 '-o-.---) +---+----+--------+ \ / \ \____ 344 | | Distributed | \ /\ .---. .---+ \ 345 | | Controller 3 | | / | ( ' | | 346 | +-----------------+ \ | \( |'.---. | 347 | / \____ \_ |---\ Domain 4 | '+, 348 \ / \ \____ (o \ | | ) 349 \ /\ .---. .---+ \ ( | | o) 350 \ | \( ' |'.---. | ( | | ) 351 \ |---\ Domain 3 | '+. ( o o .-' 352 \____(o \ | | ) ' ) 353 ( | | o)-------o---._.-.-----) 354 ( | | ) 355 ( o o .-' 356 ' ) 357 '---._.-.-----) 359 The distributed controller 1 communicates with its adjacent 360 distributed controllers, which are distributed controller 2, 361 distributed controller 3 and distributed controller 4. 363 The distributed controller 2 communicates with its adjacent 364 distributed controllers, which are distributed controller 1 and 365 distributed controller 3. 367 The distributed controller 3 communicates with its adjacent 368 distributed controllers, which are distributed controller 1, 369 distributed controller 2 and distributed controller 4. 371 The distributed controller 4 communicates with its adjacent 372 distributed controllers, which are distributed controller 1 and 373 distributed controller 3. 375 After receiving a request for creating an end to end tunnel from 376 source A to destination Z for a given set of constraints, a 377 distributed controller C1 computes an end to end path for the tunnel 378 first. It sends another distributed controller C2 a message for 379 building/growing a shortest path tree (SPT) (initially, SPT just has 380 source A as root). This controller C2 computes a set of path 381 segments in the domain it controls and continues to build/grow SPT 382 using these path segments as links. 384 And then it creates the tunnel along the path computed through 385 requesting the related distributed controllers. 387 6. Extensions to BGP 389 This section describes extensions to BGP for supporting 390 communications among SDN controllers in a SDN control system. 392 6.1. Capability and Controller Discovery 394 6.1.1. Capability Discovery 396 During/after a BGP session establishment between two BGP speakers, 397 each of them advertises its capabilities for communications among SDN 398 controllers (CSC) through the Open Message containing Capabilities 399 Optional Parameter with a new triple (Capability Code, Capability 400 Length, Capability Value) to indicate its capabilities for CSC. This 401 new triple is called CSC capability triple. It has the following 402 format. 404 +------------------------------+ 405 | Capability Code (TBD1) | 1 octet 406 +------------------------------+ 407 | Capability Length | 1 octet 408 +------------------------------+ 409 | Capability Flags | 4 octets 410 | | 411 +------------------------------+ 412 ~ (Optional Sub-TLVs) ~ 413 +------------------------------+ 415 The value of Capability Code is TBD1. The value of Capability Length 416 is 4 octets plus the size of optional Sub-TLVs. The Capability Value 417 comprises a Capability Flags field of 32 bits, which are numbered 418 from the most significant as bit zero. Some of the capability flags 419 are defined as follows. 421 o PS (Path Segments - 1 bit): Bit 0 is used as PS flag. It is set 422 to 1 indicating support for computing path segments 424 o TS (Tunnel Segment - 1 bit): Bit 1 is used as TS flag. It is set 425 to 1 indicating support for creating tunnel segment 427 o ET (End to end Tunnel - 1 bit): Bit 2 is used as ET flag. It is 428 set to 1 indicating support for creation and maintenance of end to 429 end LSP tunnels 431 o PC (Parent Controller - 1 bit): Bit 3 is used as PC flag. It is 432 set to 1 indicating that the sender of the Open Message is a 433 parent controller 435 o CC (Child Controller - 1 bit): Bit 4 is used as CC flag. It is 436 set to 1 indicating that the sender of the Open Message is a child 437 controller 439 o DC (Distributed Controller - 1 bit): Bit 5 is used as DC flag. It 440 is set to 1 indicating that the sender of the Open Message is a 441 distributed controller 443 o Levels (Levels of Parent Controller - 4 bits): Bits 6 to 9 are 444 used as Levels. It is set to the value of the levels of the local 445 BGP speaker as a parent controller. 447 6.1.2. Controller Relation Discovery 449 6.1.2.1. Parent Child Relation Discovery 451 For a parent controller P and a child controller C connected by a BGP 452 session and having a normal BGP peer adjacency, their parent-child 453 relation is discovered through Open Messages exchanged between the 454 parent controller and the child controller. The following is a 455 sequence of events related to a controller relation discovery. 457 Controller P sends controller C an Open Message containing a CSC 458 capability triple with parent flag PC set to 1 after controller C is 459 configured as a child controller over a BGP session between P and C. 461 P C 462 Configure C as Configure P as 463 Child Controller Parent Controller 465 Open Message (PC=1) 466 ---------------------> Remote P is Parent and 467 is same as configured 468 Form Child-Parent relation 469 Open Message (CC=1) 470 <--------------------- 471 Remote C is Child and 472 is same as configured 473 Form Parent-Child relation 475 When C receives the Open Message from P and determines that PC=1 in 476 the message is consistent with the parent controller configured 477 locally, it forms Child-Parent relation between C and P. It sends 478 controller P an Open Message containing a CSC capability triple with 479 child controller flag CC set to 1 after controller P is configured as 480 a parent controller over a BGP session between C and P. 482 When P receives the Open Message from C and determines that CC=1 in 483 the message is consistent with the Child controller configured 484 locally, it forms Parent-Child relation between P and C. 486 After the Parent-Child relation between P and C is formed, this 487 relation is broken if the configuration "C as Child Controller" on 488 parent controller P is deleted or "P as Parent Controller" on child 489 controller C is removed. 491 When the configuration "C as Child Controller" is deleted from parent 492 controller P, P breaks/removes the Parent-Child relation between P 493 and C and sends C an Open Message with PC = 0. When child controller 494 C receives the Open Message with PC = 0 from P, it determines that 495 the remote end P is no longer its parent controller as configured 496 locally and breaks/removes the Child-Parent relation between C and P. 498 When the configuration "P as Parent Controller" is deleted from child 499 controller C, C breaks/removes the Child-Parent relation between C 500 and P and sends P an Open Message with CC = 0. When parent 501 controller P receives the Open Message with CC = 0 from C, it 502 determines that the remote end C is no longer its child controller as 503 configured locally and breaks/removes the Parent-Child relation 504 between P and C. 506 6.1.2.2. Distributed Relation Discovery 508 For a distributed controller D1 and another distributed controller D2 509 connected by a BGP session and having a normal BGP peer adjacency, 510 their distributed controllers relation is discovered through Open 511 Messages exchanged between D1 and D2. The following is a sequence of 512 events related to a controller relation discovery. 514 Controller D1 sends controller D2 an Open Message containing a CSC 515 capability triple with Distributed Controller flag DC set to 1 after 516 controller D2 is configured as a distributed controller over a BGP 517 session between D1 and D2. 519 D1 D2 520 Configure D2 as Configure D1 as 521 Distributed controller Distributed controller 523 Open Message (DC=1) 524 ---------------------> Remote D1 is Distributed 525 and is same as configured 526 Form Distributed relation 527 Open Message (DC=1) 528 <--------------------- 529 Remote D2 is Distributed 530 and is same as configured 531 Form Distributed relation 533 When D2 receives the Open Message from D1 and determines that DC=1 in 534 the message is consistent with the distributed controller configured 535 locally, it forms distributed relation between D2 and D1. It sends 536 controller D1 an Open Message containing a CSC capability triple with 537 Distributed Controller flag DC set to 1 after controller D1 is 538 configured as a distributed controller over a BGP session between D2 539 and D1. 541 When D1 receives the Open Message from D2 and determines that DC=1 in 542 the message is consistent with the distributed controller configured 543 locally, it forms distributed relation between D1 and D2. 545 When the configuration "D2 as Distributed Controller" is deleted from 546 controller D1, D1 breaks/removes the distributed relation between D1 547 and D2 and sends D2 an Open Message with DC = 0. When controller D2 548 receives the Open Message with DC = 0 from D1, it determines that the 549 remote end D1 is no longer its adjacent distributed controller as 550 configured locally and breaks/removes the distributed relation 551 between D2 and D1. 553 When the configuration "D1 as Distributed Controller" is deleted from 554 controller D2, D2 breaks/removes the distributed relation between D2 555 and D1 and sends D1 an Open Message with DC = 0. When controller D1 556 receives the Open Message with DC = 0 from D2, it determines that the 557 remote end D2 is no longer its adjacent distributed controller as 558 configured locally and breaks/removes the distributed relation 559 between D1 and D2. 561 6.2. Messages for SDN Control System 563 This section gives an overview of messages for a Hierarchical SDN 564 Control System (HSCS) and a Distributed SDN Controller System (DSCS), 565 which is followed by the description on the contents and semantics of 566 the messages. Most of the messages for HSCS are similar to those for 567 DSCS. 569 6.2.1. Overview of Messages 571 6.2.1.1. Overview of Messages for HSCS 573 Various types of messages for supporting HSCS are listed below. 575 Message for Connections and Accesses Advertisement: It is a message 576 that a child controller sends its parent controller to describe 577 the connections from the domain it controls to its adjacent 578 domains and the access points in the domain to be accessible 579 outside of the domain. 581 Request for Computing Path Segments: It is a message that a parent 582 controller sends a child controller to request the child 583 controller for computing path segments in the domain the child 584 controller controls. 586 Reply for Computing Path Segments: It is a message that a child 587 controller sends a parent controller to reply the parent 588 controller for a request message for computing path segments after 589 receiving the request message from the parent controller and 590 computing path segments as requested, which normally contains the 591 path segments computed. 593 Request for Removing Path Segments: It is a message that a parent 594 controller sends a child controller to request the child 595 controller for removing the path segments computed by the child 596 controller and stored in the child controller. 598 Reply for Removing Path Segments: It is a message that a child 599 controller sends a parent controller to reply the parent 600 controller for a request message for removing a set of path 601 segments after receiving the request message from the parent 602 controller and removing the path segments as requested, which 603 normally contains a status of removing path segments. 605 Request for Keeping Path Segments: It is a message that a parent 606 controller sends a child controller to request the child 607 controller for keeping a set of path segments computed by the 608 child controller and stored in the child controller. 610 Reply for Keeping Path Segments: It is a message that a child 611 controller sends a parent controller to reply the parent 612 controller for a request message for keeping path segments after 613 receiving the request message from the parent controller and 614 keeping the path segments as requested, which normally contains a 615 status of keeping path segments. 617 Request for Creating Tunnel Segment: It is a message that a parent 618 controller sends a child controller to request the child 619 controller for creating tunnel segments in the domain the child 620 controller controls. 622 Reply for Creating Tunnel Segment: It is a message that a child 623 controller sends a parent controller to reply the parent 624 controller for a request message for creating tunnel segment after 625 receiving the request message from the parent controller and 626 creating tunnel segment as requested, which normally contains a 627 status of creating tunnel segment and a label and an interface. 629 Request for Removing Tunnel Segment: It is a message that a parent 630 controller sends a child controller to request the child 631 controller for removing the tunnel segment created by the child 632 controller. 634 Reply for Removing Tunnel Segment: It is a message that a child 635 controller sends a parent controller to reply the parent 636 controller for a request message for removing tunnel segment after 637 receiving the request message from the parent controller and 638 removing the tunnel segment as requested, which normally contains 639 a status of removing tunnel segment. 641 Note that four messages Request and Reply for Removing Path Segments 642 and Request and Reply for Keeping Path Segments are not needed if 643 path segments computed are not stored/remembered by a controller. 644 But in this case, the path segment in each domain along the end to 645 end path computed needs to be re-computed when a tunnel along the 646 path is set up. 648 6.2.1.2. Overview of Messages for DSCS 650 Various types of messages for supporting DSCS are listed below. 652 Message for Connections and Accesses Advertisement: It is a message 653 that a distributed controller sends its adjacent distributed 654 controllers to describe the connections from the domain it 655 controls to its adjacent domains and the access points in the 656 domain to be accessible outside of the domain. 658 Request for Growing SPT: It is a message that a distributed 659 controller D1 sends another distributed controller D2 to request 660 D2 for growing a shortest path tree (SPT) (initially, SPT is 661 empty). D2 computes a set of path segments in the domain it 662 controls and builds/grows SPT using these path segments as links. 664 Reply for Growing SPT: It is a message that a distributed controller 665 D1 sends another distributed controller D2 to reply D2 for a 666 request message for Growing SPT after receiving the request 667 message and growing SPT as requested. 669 Request for Removing Path Segments: It is a message that a 670 distributed controller D1 sends another distributed controller D2 671 to request D2 for removing the path segments computed by D2 and 672 stored in D2. 674 Reply for Removing Path Segments: It is a message that a distributed 675 controller D1 sends another distributed controller D2 to reply D2 676 for a request message for removing a set of path segments after 677 receiving the request message from D2 and removing the path 678 segments as requested. 680 Request for Keeping Path Segments: It is a message that a 681 distributed controller D1 sends another distributed controller D2 682 to request D2 for keeping a set of path segments computed by D2 683 and stored in D2. 685 Reply for Keeping Path Segments: It is a message that a distributed 686 controller D1 sends another distributed controller D2 to reply D2 687 for a request message for keeping path segments after receiving 688 the request message from D2 and keeping the path segments as 689 requested. 691 Request for Creating Tunnel Segment: It is a message that a 692 distributed controller D1 sends another distributed controller D2 693 to request D2 for creating tunnel segments in the domain D2 694 controls. 696 Reply for Creating Tunnel Segment: It is a message that a 697 distributed controller D1 sends another distributed controller D2 698 to reply D2 for a request message for creating tunnel segment 699 after receiving the request message and creating tunnel segment as 700 requested, which normally contains a status of creating tunnel 701 segment and a label and an interface. 703 Request for Removing Tunnel Segment: It is a message that a 704 distributed controller D1 sends another distributed controller D2 705 to request D2 for removing the tunnel segment created by D2. 707 Reply for Removing Tunnel Segment: It is a message that a 708 distributed controller D1 sends another distributed controller D2 709 to reply D2 for a request message for removing tunnel segment 710 after receiving the request message from D2 and removing the 711 tunnel segment as requested, which normally contains a status of 712 removing tunnel segment. 714 6.2.2. Messages for Hierarchical SDN Control System 716 6.2.2.1. Message for Connections and Accesses Advertisement in HSCS 718 After a child controller discovers its parent controller, it sends 719 its parent controller a message for connections and accesses 720 advertisement. 722 A message for connections and accesses advertisement (CAAdv message 723 for short) from a child controller comprises: 725 o Inter-domain links from the domain the child controller controls 726 to its adjacent domains. 728 o The addresses in the domain to be accessible to the outside of the 729 domain. 731 o Attributes of each of the boundary nodes of the domain. 733 6.2.2.2. Request for Computing Path Segments in HSCS 735 After receiving a request for creating an end to end tunnel from 736 source A to destination Z for a given set of constraints, a parent 737 controller allocates a global tunnel identifier (GTID) for the end to 738 end tunnel crossing domains and a path identifier (PID) for an end to 739 end path to be computed for the tunnel. The parent controller sends 740 a request message to each of its related child controllers for 741 computing a set of path segments in the domain the child controller 742 controls in a special order. The parent controller builds a shortest 743 path tree (SPT) using these path segments and obtains a shortest path 744 from source A to destination Z that satisfies the constraints. 746 A request message for computing path segments (CPSReq message for 747 short) from a parent controller to a child controller comprises: 749 o The address or identifier of the start-node (saying X) in the 750 domain controlled by the child controller. From this node, a 751 number of path segments are to be computed. 753 o The tunnel ID information (Tunnel-ID-Info for short) containing 754 the global tunnel identifier (GTID) and the path identifier (PID). 755 For the path of the tunnel, which is identified by the Tunnel-ID- 756 Info, a number of path segments are to be computed. 758 o An exception-list containing the nodes that are on the SPT and in 759 the domain controlled by the child controller or its adjacent 760 domains. 762 o The constraints for the path such as bandwidth constraints and 763 color constraints. 765 o A destination node Z. If Z is in the domain controlled by the 766 child controller, the child controller computes a shortest path 767 segment satisfying the constraints from node X to node Z within 768 the domain. 770 o Options for computing path segments: 772 E: E set to 1 indicating computing a shortest path segment 773 satisfying the constraints from node X to each of the edge 774 nodes of the domain controlled by the child controller except 775 for the nodes in the exception-list. E is set to 1 if there is 776 not any previous hop of node X in the domain. 778 After receiving the request message, the child controller computes a 779 shortest path segment satisfying the constraints from node X to each 780 of the edge nodes of the domain controlled by the child controller 781 except for the nodes in the exception-list if E is 1. In addition, 782 it computes a shortest one hop path segment satisfying the 783 constraints from node X to each of the edge nodes of the adjacent 784 domains except for the edge nodes in the exception-list just using 785 the inter-domain links attached to node X if node X is an edge node 786 of the domain and an end point of an inter-domain link. 788 6.2.2.3. Reply for Computing Path Segments in HSCS 790 After receiving a request message from a parent controller for 791 computing path segments, a child controller computes the path 792 segments as requested in the message and sends the parent controller 793 a reply message to reply the request message, which contains the path 794 segments computed. 796 A reply message for computing path segments (CPSRep message for 797 short) comprises: 799 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 800 and the path identifier (PID). For the path of the tunnel, which 801 is identified by the Tunnel-ID-Info, a number of path segments are 802 to be computed. 804 o The address or identifier of the start-node (saying X) in the 805 domain controlled by the child controller. From this node, the 806 path segments are computed. 808 o For each shortest path segment from node X to node Y computed, the 809 address or identifier of node Y and the cost of the shortest path 810 segment from node X to node Y. 812 The child controller stores the details about every shortest path 813 segment computed under GTID and PID when it sends the reply message 814 containing the path segments to the parent controller. 816 The child controller may delete the path segments computed for the 817 GTID and PID if it does not receive any request for keeping them from 818 the parent controller for a given period of time. 820 6.2.2.4. Request for Removing Path Segments in HSCS 822 After a shortest path satisfying a set of constraints from source A 823 to destination Z is computed successfully, a parent controller may 824 delete the path segments computed and stored in the related child 825 controllers, which are not any part of the shortest path. When the 826 path computation fails, the parent controller may delete the path 827 segments computed and stored in the related child controllers. A 828 parent controller may send a child controller a request message for 829 removing the path segments computed by the child controller and 830 stored in the child controller. 832 1). A request message for removing path segments (RPSReq message for 833 short) comprises: 835 o The Tunnel-ID-Info containing the global tunnel identifier (GTID). 837 All the path segments stored under GTID in the child controller are 838 to be removed. 840 2). A request message for removing path segments comprises: 842 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 843 and the path identifier (PID). 845 All the path segments stored under GTID and PID in the child 846 controller are to be removed. 848 3). A request message for removing path segments comprises: 850 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 851 and the path identifier (PID) 853 o A list of start-point (or node) addresses or identifiers. 855 All the path segments stored in the child controller under GTID and 856 PID and with a start-point or node from the list of start-point (or 857 node) addresses or identifiers are to be removed. 859 4). A request message for removing path segments comprises: 861 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 862 and the path identifier (PID) 864 o A list of start-point (or node) addresses or identifiers 866 o A list of pairs (start-point, a list of end-points), which 867 identifies the path segments from start-point of each pair to each 868 of the end-points in the list of the pairs. 870 In addition to the path segments as described in the previous 871 message, the path segments stored in the child controller under GTID 872 and PID and identified by the list of pairs are to be removed. 874 6.2.2.5. Reply for Removing Path Segments in HSCS 876 After removing the path segments as requested by a request message 877 for removing path segments from a parent controller, a child 878 controller sends the parent controller a reply message for removing 879 path segments. 881 A reply message for removing path segments (RPSRep message for short) 882 comprises: 884 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 885 and the path identifier (PID) 887 o Status of the path segments removal: 889 Success: The path segments requested for removal are removed 890 successfully. 892 Fail: The path segments requested for removal can not be 893 removed. 895 o Error code and reasons for failure if the status is Fail. 897 6.2.2.6. Request for Keeping Path Segments in HSCS 899 After a shortest path satisfying a set of constraints from source A 900 to destination Z is computed, a parent controller may send a request 901 message for keeping path segments to each of the related child 902 controllers to keep the path segments on the shortest path. 904 A request message for keeping path segments (KPSReq message for 905 short) comprises: 907 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 908 and the path identifier (PID). 910 o A list of pairs (start-point, end-point), each of which identifies 911 the path segment from the start-point of the pair to the end-point 912 of the pair. 914 The child controller will keep the path segments given by the list of 915 pairs (start-point, end-point) stored under GTID and PID. It will 916 remove all the other path segments stored under GTID and PID. 918 6.2.2.7. Reply for Keeping Path Segments in HSCS 920 After keeping path segments as requested by a request message for 921 keeping path segments from a parent controller, a child controller 922 sends the parent controller a reply message for keeping path 923 segments. 925 A reply message for keeping path segments (KPSRep message for short) 926 comprises: 928 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 929 and the path identifier (PID). 931 o Status of the path segment retention: 933 Success: The path segments requested for retention are retained 934 successfully. 936 Fail: The path segments requested for retention can not be 937 retained. 939 o Error code and reasons for failure if the status is Fail. 941 6.2.2.8. Request for Creating Tunnel Segment in HSCS 943 After obtaining the end to end shortest point to point (P2P) path, a 944 parent controller creates a tunnel along the path crossing multiple 945 domains through sending a request message for creating tunnel segment 946 to each of the child controllers along the path in a reverse 947 direction to create a tunnel segment. 949 A request message for creating tunnel segment (CTSReq message for 950 short) comprises: 952 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 953 and the path identifier (PID). 955 o A path segment from a start-point to an end-point for parent 956 without domain topology or a path segment details/ERO for parent 957 with domain topology. 959 o A label and an interface if the domain controlled by the child 960 control is not a destination domain. 962 For a parent without domain topology, the child controller allocates 963 and reserves link bandwidth along the path segment identified by the 964 start-point and end-point, assigns labels along the path segment, and 965 writes cross connects on each of the nodes along the path segment. 967 For a parent with domain topology, the child controller assigns 968 labels along the path segment ERO and writes cross connects on each 969 of the nodes along the path segment. The link bandwidth along the 970 path segment is allocated and reserved by the parent controller. 972 For the non destination domain, the child controller writes the cross 973 connect on the edge node to the downstream domain using the label and 974 the interface from the downstream domain in the message. 976 For the non source domain, the child controller will include a label 977 and an interface in a message to be sent to the parent controller. 978 The interface connects the edge node of the upstream domain along the 979 path. The label is allocated for the interface on the node that is 980 the next hop of the edge node. 982 6.2.2.9. Reply for Creating Tunnel Segment in HSCS 984 After creating tunnel segment as requested by a request message for 985 creating tunnel segment from a parent controller, a child controller 986 sends the parent controller a reply message for creating tunnel 987 segment. 989 A reply message for creating tunnel segment (CTSRep message for 990 short) comprises: 992 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 993 and the path identifier (PID). 995 o Status of the tunnel segment creation: 997 Success: The tunnel segment requested is created successfully. 999 Fail: The tunnel segments requested can not be created. 1001 o A label and an interface if the domain controlled by the child 1002 controller is not source domain and the status is Success. 1004 o Error code and reasons for failure if the status is Fail. 1006 For the non source domain controlled by the child controller, the 1007 interface in the message connects the edge node of the upstream 1008 domain along the path, the label is allocated for the interface on 1009 the node that is the next hop of the edge node. 1011 6.2.2.10. Request for Removing Tunnel Segment in HSCS 1013 When a parent controller receives a request for deleting a tunnel 1014 from a user or an application, or receives a reply message for 1015 creating tunnel segment with status of Fail from a child controller, 1016 the parent controller will delete the tunnel through sending a 1017 request message for removing tunnel segment to each of the related 1018 child controllers. 1020 A request message for removing tunnel segment (RTSReq message for 1021 short) comprises: 1023 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 1024 and the path identifier (PID). 1026 The child controller releases the labels assigned along the path 1027 segments under GTID and PID, and removes the cross connects on each 1028 of the nodes along the path segments. If the child controller 1029 reserved the link bandwidth along the path segments under GTID and 1030 PID, it releases the link bandwidth reserved. 1032 6.2.2.11. Reply for Removing Tunnel Segment in HSCS 1034 After removing the tunnel segment as requested by a request message 1035 for removing tunnel segment from a parent controller, a child 1036 controller sends the parent controller a reply message for removing 1037 tunnel segment. 1039 A reply message for removing tunnel segment (RTSRep message for 1040 short) comprises: 1042 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 1043 and the path identifier (PID). 1045 o Status of the tunnel segment removal: 1047 Success: The tunnel segment requested is removed successfully. 1049 Fail: The tunnel segment requested can not be removed. 1051 o Error code and reasons for failure if the status is Fail. 1053 6.2.3. Messages for Distributed SDN Control System 1055 Regarding to the operations related to paths and tunnels, most of the 1056 messages used in Distributed SDN Control System (DSCS) are the same 1057 as their corresponding messages used in Hierarchical SDN Control 1058 System (HSCS), which are described in the previous section. Some 1059 messages in DSCS are similar to their corresponding messages in HSCS. 1061 6.2.3.1. Message for Connections and Accesses Advertisement in DSCS 1063 After a distributed controller discovers its adjacent distributed 1064 controllers, it sends each of them a message for connections and 1065 accesses advertisement. The contents of the message is the same as 1066 that of the corresponding message that a child controller sends to 1067 its parent controller, which is described in section 6.2.2.1. 1069 6.2.3.2. Request for Growing SPT 1071 After receiving a request for creating an end to end tunnel from 1072 source A to destination Z for a given set of constraints, a 1073 distributed controller D1 allocates a global tunnel identifier (GTID) 1074 for the end to end tunnel crossing domains and a path identifier 1075 (PID) for an end to end path to be computed for the tunnel. D1 sends 1076 another distributed controller D2 a request message for growing a 1077 shortest path tree (SPT). D2 computes a set of path segments in the 1078 domain it controls and builds/grows SPT using these path segments as 1079 links. 1081 A request message for Growing SPT (GSReq message for short) from a 1082 distributed controller D1 to another distributed controller D2 1083 comprises: 1085 o The address or identifier of the start-node (saying X) in the 1086 domain controlled by D2. From this node, a number of path 1087 segments are to be computed. 1089 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 1090 and the path identifier (PID). For the path of the tunnel 1091 identified by the Tunnel-ID-Info, a number of path segments are to 1092 be computed. 1094 o The SPT built so far. 1096 o The current candidate-list. 1098 o The constraints for the path such as bandwidth constraints and 1099 color constraints. 1101 o A destination node Z. If Z is in the domain controlled by D2, D2 1102 computes a shortest path segment satisfying the constraints from 1103 node X to node Z within the domain. 1105 Controller D2 updates the candidate-list using the path segments 1106 computed as links, selects a node Y with minimum cost from the 1107 candidate-list and adds Y into the SPT. 1109 After adding a node Y into the SPT, D2 constructs a request message 1110 for growing SPT using the updated SPT, the updated candidate-list and 1111 node Y as a start-node, and sends the message to the distributed 1112 controller controlling the domain containing Y. 1114 D2 stores the details about every shortest path segment computed for 1115 the path of the tunnel when it sends D3 the request message 1116 containing the path segments as links. 1118 D2 deletes the path segments computed for the path of the tunnel 1119 after a given period of time if it does not receive any request for 1120 keeping them. 1122 6.2.3.3. Reply for Growing SPT 1124 After a distributed controller D2 receives a request message for 1125 growing SPT from another distributed controller D1, D2 computes the 1126 path segments in the domain it controls and grows SPT using the 1127 segments as links. It sends a distributed controller D3 a request 1128 message for growing SPT to continue to grow SPT and may send D1 a 1129 reply for growing SPT. 1131 A reply message for Growing SPT (GSRep message for short) from D2 to 1132 D1 comprises: 1134 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 1135 and the path identifier (PID), which identifies the path of the 1136 tunnel for which a SPT is being built for. 1138 o Status of growing SPT: 1140 Success: The SPT is built successfully. 1142 Fail: The SPT can not be built to contain a shortest path from 1143 source A to destination Z. 1145 o SPT if the status is Success. 1147 o Error code and reasons for failure if the status is Fail. 1149 6.2.3.4. Request for Removing Path Segments in DSCS 1151 After a shortest path satisfying a set of constraints from source A 1152 to destination Z is computed successfully, the distributed controller 1153 D0 originating the path computation may delete the path segments 1154 computed and stored in the related distributed controllers, which are 1155 not any part of the shortest path. When the path computation fails, 1156 D0 may delete the path segments computed and stored in the related 1157 distributed controllers. D0 may send a distributed controller Di a 1158 request message for removing the path segments computed by Di and 1159 stored in Di. 1161 The contents of the request message for removing path segments sent 1162 to a distributed controller Di is the same as that of the 1163 corresponding message sent to a child controller, which is described 1164 in section 6.2.2.4. Di receiving the message performs the same 1165 removal operations on the path segments according to the contents of 1166 the message as the child controller does. 1168 6.2.3.5. Reply for Removing Path Segments in DSCS 1170 After removing the path segments as requested by a request message 1171 for removing path segments from a distributed controller D0, a 1172 distributed controller Di sends D0 a reply message for removing path 1173 segments. 1175 The contents of the reply message for removing path segments sent by 1176 distributed controller Di is the same as that of the corresponding 1177 message sent by the child controller, which is described in section 1178 6.2.2.5. 1180 6.2.3.6. Request for Keeping Path Segments in DSCS 1182 After a shortest path satisfying a set of constraints from source A 1183 to destination Z is computed, the distributed controller D0 1184 originating the path computation may send a request message for 1185 keeping path segments to each of the related distributed controllers 1186 Di to keep the path segments on the shortest path. 1188 The contents of the request message for keeping path segments sent to 1189 a distributed controller Di is the same as that of the corresponding 1190 message sent to a child controller, which is described in section 1191 6.2.2.6. Di receiving the message performs the same retention 1192 operations on the path segments according to the contents of the 1193 message as the child controller does. 1195 6.2.3.7. Reply for Keeping Path Segments in DSCS 1197 After keeping path segments as requested by a request message for 1198 keeping path segments from a distributed controller D0, a distributed 1199 controller Di sends D0 a reply message for keeping path segments. 1201 The contents of the reply message for keeping path segments sent by 1202 distributed controller Di is the same as that of the corresponding 1203 message sent by the child controller, which is described in section 1204 6.2.2.7. 1206 6.2.3.8. Request for Creating Tunnel Segment in DSCS 1208 After obtaining the end to end shortest point to point (P2P) path, a 1209 distributed controller creates a tunnel along the path crossing 1210 multiple domains through sending a request message for creating 1211 tunnel segment to each of the related distributed controllers along 1212 the path in a reverse direction to create a tunnel segment. 1214 A request message for creating tunnel segment (CTSReq message for 1215 short) sent from controller D0 to Di comprises: 1217 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 1218 and the path identifier (PID). 1220 o A path segment from a start-point to an end-point. 1222 o A label and an interface if the domain controlled by Di is not a 1223 destination domain. 1225 Di allocates and reserves link bandwidth along the path segment 1226 identified by the start-point and end-point, assigns labels along the 1227 path segment, and writes cross connects on each of the nodes along 1228 the path segment. 1230 For the non destination domain, Di writes the cross connect on the 1231 edge node to the downstream domain using the label and the interface 1232 from the downstream domain in the message. 1234 For the non source domain, Di will include a label and an interface 1235 in a message to be sent. The interface connects the edge node of the 1236 upstream domain along the path. The label is allocated for the 1237 interface on the node that is the next hop of the edge node. 1239 6.2.3.9. Reply for Creating Tunnel Segment in DSCS 1241 After creating tunnel segment as requested by a request message for 1242 creating tunnel segment from a distributed controller D0, a 1243 distributed controller Di may send D0 a reply message for creating 1244 tunnel segment. 1246 A reply message for creating tunnel segment (CTSRep message for 1247 short) comprises: 1249 o The Tunnel-ID-Info containing the global tunnel identifier (GTID) 1250 and the path identifier (PID). 1252 o Status of the tunnel segment creation: 1254 Success: The tunnel segment requested is created successfully. 1256 Fail: The tunnel segments requested can not be created. 1258 o A label and an interface if the domain controlled by Di is not 1259 source domain and the status is Success. 1261 o Error code and reasons for failure if the status is Fail. 1263 For the non source domain controlled by Di, the interface in the 1264 message connects the edge node of the upstream domain along the path, 1265 the label is allocated for the interface on the node that is the next 1266 hop of the edge node. 1268 6.2.3.10. Request for Removing Tunnel Segment in DSCS 1270 When a distriuted controller D0 receives a request for deleting a 1271 tunnel from a user or an application, or receives a reply message for 1272 creating tunnel segment with status of Fail from another distributed 1273 controller, D0 deletes the tunnel through sending a request message 1274 for removing tunnel segment to each of the related distributed 1275 controllers Di. 1277 The contents of the request message for removing tunnel segment is 1278 the same as that of the corresponding message described in section 1279 6.2.2.10. The distributed controller Di receiving the message 1280 performs the same removal operations on the tunnel segments according 1281 to the contents of the message as the child controller does. 1283 6.2.3.11. Reply for Removing Tunnel Segment in DSCS 1285 After removing the tunnel segment as requested by a request message 1286 for removing tunnel segment from a distributed controller D0, a 1287 distributed controller Di sends D0 a reply message for removing 1288 tunnel segment. 1290 The contents of the reply message for removing tunnel segment sent by 1291 distributed controller Di is the same as that of the corresponding 1292 message sent by the child controller, which is described in section 1293 6.2.2.11. 1295 6.3. Connections and Accesses Advertisement 1297 6.3.1. Advertisement in Hierarchical SDN Control System 1299 A child controller sends its parent controller a message for 1300 connections and accesses, which contains the connections (i.e., 1301 inter-domain links) connecting the domain that the child controller 1302 controls to its adjacent domains, and the addresses/prefixes (i.e., 1303 the access points) in the domain to be accessible from outside of the 1304 domain. 1306 When there is a change on the connections and the accesses of the 1307 domain, the child controller sends its parent controller a updated 1308 message for the connections and accesses, which contains the latest 1309 connections and accesses of the domain. 1311 A parent controller stores the connections and accesses for each of 1312 its child controllers according to the messages for connections and 1313 accesses received from the child controllers. For a updated message, 1314 it updates the connections and accesses accordingly. 1316 When a child controller is down, its parent controller removes the 1317 connections and accesses of the domain controlled by the child 1318 controller. 1320 After connections and accesses advertisements, a parent controller 1321 has the exterior information about all the domains controlled by its 1322 child controllers. In other words, a parent controller has the 1323 connections among the domains (i.e., the inter-domain links 1324 connecting the domains) controlled by its child controllers and the 1325 addresses/prefixes (i.e., access points) in the domains to be 1326 accessible. 1328 A connection comprises: the attributes for a link connecting domains 1329 and the attributes for the end points of the link. The attributes 1330 for an end point of a link comprises the type of the end point node 1331 such as ABR or ASBR, and the domain of the end point such AS number 1332 and area number. 1334 An access point comprises an address or a prefix of a domain to be 1335 accessible outside of the domain. 1337 6.3.2. Advertisement in Distributed SDN Control System 1339 Each distributed controller sends its adjacent distributed 1340 controllers a message for connections and accesses, which contains 1341 the connections (i.e., inter-domain links) from the domain that the 1342 controller controls to its adjacent domains, and the addresses (i.e., 1343 the access points) in the domain to be accessible from outside of the 1344 domain. 1346 When there is a change on the connections and the accesses of the 1347 domain, the controller sends its adjacent distributed controllers a 1348 updated message for connections and accesses, which contains the 1349 latest connections and accesses of the domain. 1351 After a distributed controller A receives a message for connections 1352 and accesses originated from a distributed controller X from an 1353 adjacent distributed controller B, A stores and/or updates the 1354 connections and accesses of the domain controlled by X according to 1355 the message for X and sends the message to all its adjacent 1356 distributed controllers except for B if the contents of the message 1357 for X is changed. 1359 The connections and accesses of the domain controlled by distributed 1360 controller X will be removed if X is not reachable. 1362 When a new distributed controller joins through an adjacency, it will 1363 get all the connections and accesses messages for the other 1364 distributed controllers via the adjacency. 1366 After advertisements of connections and accesses, each distributed 1367 controller has the exterior information about all the domains 1368 controlled by distributed controllers. In other words, it has the 1369 connections among the domains (i.e., the inter-domain links 1370 connecting the domains) and the addresses in the domains to be 1371 accessible. 1373 6.4. Tunnel Creation 1375 6.4.1. Tunnel Creation in Hierarchical SDN Control System 1377 6.4.1.1. Procedure for Computing Path in HSCS 1379 For a top level parent without domain topology, the parent controller 1380 computes a shortest point to point (P2P) path for a tunnel from a 1381 source to a destination satisfying a set of constraints given to the 1382 tunnel through building a shortest path tree (SPT). The SPT is built 1383 from the SPT containing just the source as root and an empty 1384 candidate-list in the following steps. 1386 Step 1: The parent controller selects the node X just added to the 1387 SPT (Initially, it selects the source). 1389 Step 2: After selecting the node X just added into the SPT, the 1390 parent controller chooses the child controller controlling the 1391 domain containing the node X, and determines whether the node X is 1392 destination. 1394 For destination node, the parent controller stops computing path 1395 since the end to end path from source to destination is in the 1396 SPT, which is from the root of the SPT to the node (destination 1397 node) in the SPT. 1399 For non-destination node X, the parent controller sends the child 1400 controller a request message for computing path segments 1401 related to the domain controlled by the child controller. The 1402 request contains the exception-list for the domain and flag E. 1404 o After receiving the request message, the child controller 1405 computes a shortest path segment from node X to each of the 1406 edge nodes of the domain not in the exception-list if E is 1407 1. 1409 o In addition, it computes a shortest one hop path segment 1410 from node X to each of the edge nodes of the adjacent 1411 domains not in the exception-list just using the inter- 1412 domain links attached to node X if node X is an edge node 1413 and there is an inter-domain link attached to it. 1415 o If node X is in the destination domain, it computes a 1416 shortest path segment from node X to the destination. 1418 o It sends the parent controller a reply message with the path 1419 segments computed as links. 1421 Step 3: After receiving the reply message from the child controller, 1422 the parent controller updates the candidate list with the links, 1423 picks up a node in the candidate list with the minimum cost and 1424 adds it into the SPT. Repeat step 1. 1426 For a parent without domain topology, if the parent controller is 1427 also a child controller of another upper level parent controller, 1428 after receiving a request for computing path segments from the upper 1429 level parent controller, the parent controller computes each of the 1430 path segments as requested in the same way as described above. It 1431 records and maintains the path segments computed under the GTID and 1432 GPID in the request message received from the upper level parent 1433 controller. 1435 In addition, for each path segment to be computed, it allocates a new 1436 GTID and GPID for the path segment and computes the path segment 1437 through sending a request message for computing path segments to each 1438 of its related child controllers using the new GTID and GPID. 1440 When the parent as a child controller receives a request message for 1441 removing path segments from the upper level parent controller, it 1442 removes the path segments computed by each of its related child 1443 controllers through sending a request message for removing path 1444 segments to each of the related child controllers, and then it 1445 removes the path segments crossing multiple domains controlled by its 1446 child controllers. 1448 6.4.1.2. Procedure for Creating Tunnel along Path in HSCS 1450 After obtaining the end to end shortest point to point (P2P) path, 1451 the parent controller creates a tunnel along the path crossing 1452 multiple domains through requesting the child controllers along the 1453 path in a reverse direction. 1455 For a parent without domain topology, the following is the procedure 1456 for creating the tunnel along the path, which is initiated by the 1457 parent controller starting from domain X = destination domain. 1459 Step 1: The parent controller sends the child controller controlling 1460 domain X a request message for creating tunnel segment in domain 1461 X. 1463 o After receiving the request message from the parent controller, 1464 the child controller creates the tunnel segment in domain X it 1465 controls through reserving the resources such as link 1466 bandwidth, allocating labels along the path segment and writing 1467 a cross connect on every node in the domain along the path. 1469 o If the child controller is not destination controller, the 1470 request message contains an label and interface for the next 1471 hop of the edge node of domain X. The label is allocated by the 1472 controller that controls the downstream domain of domain X. The 1473 child controller uses this label and an incoming label 1474 allocated for the incoming interface on the edge node to write 1475 a cross connect on the edge node. 1477 o The child controller sends the parent controller a reply 1478 message with the status of the tunnel segment creation. The 1479 reply message contains an incoming label and interface for the 1480 next hop of the edge node of the upstream domain of domain X if 1481 domain X is not source domain. 1483 Step 2: The parent controller receives the reply message from child 1484 controller C. If the status in the message is Fail, then it 1485 removes the tunnel segments created for the tunnel and return with 1486 failure for creating the tunnel. 1488 Step 3: If child controller C is the source controller, then the end 1489 to end tunnel is created, and the parent controller and the child 1490 controllers along the tunnel maintain the information of the 1491 tunnel with the GTID and PID. The parent controller returns with 1492 success for creating the tunnel. 1494 Step 4: Child controller C is not source controller. The reply 1495 message contains the label and interface, the parent controller 1496 repeats step 1 with domain X = the upstream domain of domain X. 1497 (In other words, it sends a request message to the child 1498 controller that controls the domain which is the upstream domain 1499 of the domain in which a tunnel segment is just created. The 1500 request contains the label and interface.) 1502 For a parent with domain topology, the procedure for creating the 1503 tunnel along the path initiated by the parent controller is similar 1504 to the one described above, but has a few of changes to it, which are 1505 listed as follows: 1507 o The request message for creating tunnel segment sent to a child 1508 controller from the parent controller contains the detailed 1509 information about the path segment (such as ERO comprising every 1510 hop of the path segment) along which the tunnel segment to be 1511 created. 1513 o The child controller does not check or reserve resources such as 1514 link bandwidth along the path segment if the parent controller is 1515 responsible for allocating and reserving the resources along the 1516 path for the tunnel. 1518 o The child controller does not assign any labels along the path 1519 segment if the parent controller is responsible for assigning 1520 labels along the path for the tunnel. In this case, the request 1521 message for creating tunnel segment contains an label for every 1522 hop of the path segment. The reply message from the child 1523 controller to the parent controller does not contain any label or 1524 interface. 1526 When the parent as a child controller receives a request message for 1527 creating tunnel segment along a path segment from the upper level 1528 parent controller, it gets the path segments for its related child 1529 controllers from the path segment in the message. 1531 For the parent with domain topology, it obtains the detailed hop to 1532 hop information crossing multiple domains about the path segment 1533 stored by the parent controller using the GTID, PID and start-point 1534 and end-point of the path segment in the message received. The 1535 parent controller creates the tunnel segments in the multiple domains 1536 through sending a request message for creating tunnel to each of its 1537 related child controllers along the path in a reverse direction. 1539 For the parent without domain topology, it obtains the detailed 1540 information about the path segment stored by the parent controller 1541 using the GTID, PID and start-point and end-point of the path segment 1542 in the message received. The detailed information includes multiple 1543 path segments, each of which crosses a domain controlled by one of 1544 its related child controllers. These multiple path segments 1545 constitute the path segment in the message, which crosses multiple 1546 domains. The parent controller creates the tunnel segments in the 1547 multiple domains through sending a request message for creating 1548 tunnel to each of its related child controllers along the path in a 1549 reverse direction. For each of the path segments crossing a domain, 1550 the parent controller creates a tunnel segment along the path segment 1551 through sending a request message for creating tunnel segment to its 1552 child controller controlling the domain. 1554 6.4.2. Tunnel Creation in Distributed SDN Control System 1556 In a Distributed SDN Control System (DSCS), a distributed controller 1557 may be designated as a master controller, which receives various 1558 requests such as creating an end to end tunnel from users and 1559 applications. After the master controller receives a request for 1560 creating an end to end tunnel from source A to destination Z for a 1561 given set of constraints, it may compute a path for the tunnel first 1562 and then create the tunnel along the path through requesting the 1563 related distributed controllers. It may compute a path and create 1564 the tunnel along the path in one round through requesting the related 1565 distributed controllers. 1567 6.4.2.1. Procedure for Computing Path in DSCS 1569 The master controller initiates the computation of an end to end path 1570 from source A to destination Z through sending a request message for 1571 growing SPT to the source controller. The message contains start- 1572 node = A, SPT with just source A and an empty candidate-list. The 1573 source controller starts the path computation. 1575 The following is the procedure for computing a path started from Dj 1576 controlling domain X (= source domain). 1578 Step 1: Dj controlling domain X receives a request message for 1579 growing SPT from controller Di. The message contains start-node 1580 A, SPT, candidate-list, destination Z, constrains, GTID and PID. 1582 Step 2: Dj does the following 1584 o If the start-node is the destination, Dj stops computing path 1585 since the end to end path from source to destination is in the 1586 SPT. The path is from the root of the SPT to the start-node 1587 (== destination node) in the SPT. 1589 o Dj computes a shortest path segment from the start-node A to 1590 each of the edge nodes of domain X not in the SPT that 1591 satisfies the constrains. It also computes a shortest path 1592 segment from the start-node A to the destination Z if Z is in 1593 domain X. Dj stores the path segments computed under GTID and 1594 PID. 1596 o Dj updates the current candidate-list using the path segments 1597 as links and the inter-domain links attached to the start-node, 1598 selects a node B with the minimum cost from the updated 1599 candidate-list if the list is not empty, and adds the node B 1600 into the SPT. 1602 o If the candidate-list is empty, Dj stops computing path since 1603 no path can be computed. 1605 o Dj removes the node B selected from the candidate-list, repeat 1606 step 1 through sending a request message for growing SPT to the 1607 distributed controller Dk controlling the domain Y containing 1608 B. The request message contains the start-node B, SPT with B 1609 just added, updated candidate-list, destination Z, constrains, 1610 GTID and PID. 1612 6.4.2.2. Procedure for Creating Tunnel along Path in DSCS 1614 There are a couple of ways in which an end to end tunnel is created 1615 along the path computed or the tunnel. One way is that the 1616 distributed controller originating the path computation initiates and 1617 controls the creation of the tunnel. Another way is that the 1618 destination controller for the tunnel starts the tunnel creation. 1620 1. Master Controller Controls Tunnel Creation in DSCS 1622 After obtaining the end to end shortest point to point (P2P) path, 1623 the distributed controller D0 originating the path computation 1624 initiates the creation of a tunnel along the path crossing multiple 1625 domains through requesting the related distributed controllers along 1626 the path in a reverse direction. 1628 The following is the procedure for creating the tunnel along the 1629 path, which is initiated by D0 starting from domain X = destination 1630 domain. 1632 Step 1: D0 sends the distributed controller Di controlling domain X 1633 a request message for creating tunnel segment in domain X. 1635 o After receiving the request message from D0, Di creates the 1636 tunnel segment in domain X it controls through reserving the 1637 resources such as link bandwidth, allocating labels along the 1638 path segment and writing a cross connect on every node in the 1639 domain along the path. 1641 o If Di is not destination controller, the request message 1642 contains an label and interface for the next hop of the edge 1643 node of domain X. The label is allocated by the controller that 1644 controls the downstream domain of domain X. Di uses this label 1645 and an incoming label allocated for the incoming interface on 1646 the edge node to write a cross connect on the edge node. 1648 o Di sends D0 a reply message with the status of the tunnel 1649 segment creation. The reply message contains an incoming label 1650 and interface for the next hop of the edge node of the upstream 1651 domain of domain X if domain X is not source domain. 1653 Step 2: D0 receives the reply message from Di. If the status in the 1654 message is Fail, then it removes the tunnel segments created for 1655 the tunnel and return with failure for creating the tunnel. 1657 Step 3: If Di is the source controller, then the end to end tunnel 1658 is created, and the controller D0 and each of the related 1659 distributed controllers Di along the tunnel maintain the 1660 information of the tunnel with the GTID and PID. D0 returns with 1661 success for creating the tunnel. 1663 Step 4: Di is not source controller. The reply message contains the 1664 label and interface, D0 repeats step 1 with domain X = the 1665 upstream domain of domain X. (In other words, it sends a request 1666 message to another distributed controller that controls the domain 1667 which is the upstream domain of the domain in which a tunnel 1668 segment is just created. The request contains the label and 1669 interface.) 1671 2. Destination Controller Starts Tunnel Creation 1673 After obtaining the end to end shortest point to point (P2P) path, 1674 the distributed controller D0 originating the path computation 1675 initiates the creation of a tunnel along the path crossing multiple 1676 domains through requesting the destination controller Dn to start the 1677 tunnel creation. 1679 The following is the procedure for creating the tunnel along the path 1680 started from Dn controlling domain X = destination domain. 1682 Step 1: If Dn controlling domain X receives a request message for 1683 creating tunnel segment from controller D0, then 1685 o Dn creates the tunnel segment in domain X it controls through 1686 reserving the resources such as link bandwidth, allocating 1687 labels along the path segment and writing a cross connect on 1688 every node in the domain along the path segment. 1690 o If Dn is not destination controller, the request message 1691 contains an label and interface for the next hop of the edge 1692 node of domain X. The label is allocated by the controller that 1693 controls the downstream domain of domain X. Dn uses this label 1694 and an incoming label allocated for the incoming interface on 1695 the edge node to write a cross connect on the edge node. 1697 o If Dn is not source controller, repeat step 1 by sending 1698 distributed controller Dm controlling the upstream domain W of 1699 domain X a request message for creating tunnel segment in 1700 domain W if creating tunnel segment in domain X is successful. 1701 The request message contains an incoming label and interface 1702 for the next hop of the edge node of domain W. 1704 o If creating tunnel segment in domain X fails, Dn removes the 1705 partial tunnel segment created in domain X and repeat step 1 1706 through sending its downstream controller D0 a reply message 1707 with the status of Fail. 1709 o If Dn is the source controller, repeat step 1 through sending 1710 its downstream controller D0 a reply message with the status of 1711 Success. 1713 Step 2: If Dn receives a reply message from its upstream controller 1714 Dm, then 1716 o If the status in the message is Fail, Dn removes the tunnel 1717 segments created for the tunnel and sends its downstream 1718 controller D0 a reply message with the status of Fail. 1720 o If the status in the message is Success, Dn sends D0 a reply 1721 message with the status of Success. 1723 6.4.2.3. Computing Path and Creating Tunnel in One Round 1725 The master controller initiates the computation of an end to end path 1726 from source A to destination Z. The source controller starts 1727 computing the path through growing the SPT from source as root. 1728 Other related controllers continue computing the path through growing 1729 the SPT. The destination controller finishes computing the path and 1730 gets the path when the destination Z is in SPT. 1732 After the destination controller gets the path, it tells the master 1733 controller that the path is computed through a reply message for 1734 growing SPT and starts creating the tunnel. 1736 It creates the tunnel segment in the destination domain and then 1737 sends the controller Du controlling the upstream domain U of the 1738 destination domain a request message for creating tunnel segment 1739 along the path. Du creates the tunnel segment in domain U and then 1740 sends the controller controlling the upstream domain of domain U a 1741 request message for creating tunnel segment along the path, and so 1742 on. At last, the source controller finishes creating the tunnel 1743 after it creates the tunnel segment in the source domain. 1745 The source controller tells the master controller that the tunnel is 1746 created successfully after it finishes creating the tunnel through a 1747 reply message for creating tunnel segment. 1749 6.5. Transporting SDN Information in BGP 1751 6.5.1. TLV Format 1753 The information in the new SDN NLRIs is encoded in Type/Length/Value 1754 triplets. The TLV format is shown below. 1756 0 1 2 3 1757 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 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | Type | Length | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 ~ Value (variable) ~ 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 The Length field defines the length of the value portion in octets 1765 (thus a TLV with no value portion would have a length of zero). The 1766 TLV is not padded to four-octet alignment. Unrecognized types MUST 1767 be preserved and propagated. In order to compare NLRIs with unknown 1768 TLVs all TLVs MUST be ordered in ascending order by TLV Type. If 1769 there are more TLVs of the same type, then the TLVs MUST be ordered 1770 in ascending order of the TLV value within the TLVs with the same 1771 type by treating the entire value field an opaque hexadecimal string 1772 and comparing leftmost octets first regardless of the length of the 1773 string. All TLVs that are not specified as mandatory are considered 1774 optional. 1776 6.5.2. SDN NLRIs 1778 The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 1779 for carrying opaque information. Each SDN NLRI describes a SDN 1780 message. 1782 All SDN messages SHALL be encoded using AFI TBD (16389) / SAFI TBD 1783 (78). 1785 In order for two BGP speakers to exchange SDN NLRI, they MUST use BGP 1786 Capabilities Advertisement to ensure that they both are capable of 1787 properly processing such NLRI. This is done as specified in 1788 [RFC4760], by using capability code 1 (multi-protocol BGP), with AFI 1789 TBD (16389) / SAFI TBD (78) for BGP-SDN 1791 The format of the SDN NLRI is shown as follows. 1793 0 1 2 3 1794 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 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | NLRI-Type | NLRI-Length | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | SDN NLRI Value (variable) | 1799 ~ ~ 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 SDN AFI TBD (16389) / SAFI TBD (78) NLRI Format 1803 Where the values of NLRI-Type are defined below. 1805 +=========+=====================================================+ 1806 |Value of | Meaning | 1807 |NLRI-Type| | 1808 +=========+=====================================================+ 1809 | 1 | Request for Computing Path Segment (CPSReq) | 1810 | 2 | Reply for Computing Path Segment (CPSRep) | 1811 | 3 | Request for Removing Path Segment (RPSReq) | 1812 | 4 | Reply for Removing Path Segment (RPSRep) | 1813 | 5 | Request for Keeping Path Segment (KPSReq) | 1814 | 6 | Reply for Keeping Path Segment (KPSRep) | 1815 | 7 | Request for Creating Tunnel Segment (CTSReq) | 1816 | 8 | Reply for Creating Tunnel Segment (CTSRep) | 1817 | 9 | Request for Removing Tunnel Segment (RTSReq) | 1818 | 10 | Reply for Removing Tunnel Segment (RTSRep) | 1819 | 11 | Message for Connection and Access Advertisement(CAA)| 1820 | 12 | Request for Growing SPT (GSReq) | 1821 | 13 | Reply for Growing SPT (GSRep) | 1822 +=========+=====================================================+ 1824 The format of Request for Computing Path Segment NLRI (NLRI-Type = 1) 1825 is illustrated below. 1827 0 1 2 3 1828 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 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | NLRI-Type (1) | NLRI-Length | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 ~ Controller Request Parameters (variable) ~ 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 ~ Start-Node (variable) ~ 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 ~ Tunnel-ID-Info (variable) ~ 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 ~ Exception-List (variable) ~ 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 ~ Constraints (variable) ~ 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 ~ Destination Node (variable) ~ 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 Format of Request for Computing Path Segment NLRI 1847 The format of Reply for Computing Path Segment NLRI (NLRI-Type = 2) 1848 is illustrated below. 1850 0 1 2 3 1851 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 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | NLRI-Type (2) | NLRI-Length | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 ~ Controller Request Parameters (variable) ~ 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 ~ Start-Node (variable) ~ 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 ~ Tunnel-ID-Info (variable) ~ 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 ~ Segment End List (variable) ~ 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 ~ Metric List (variable) ~ 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 ~ No Path (variable) ~ 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 Format of Reply for Computing Path Segment NLRI 1870 The format of Request for Removing Path Segment NLRI (NLRI-Type = 3) 1871 is illustrated below. 1873 0 1 2 3 1874 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 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | NLRI-Type (3) | NLRI-Length | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 ~ Controller Request Parameters (variable) ~ 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 ~ Tunnel-ID-Info (variable) ~ 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 ~ Start-Node List (variable) ~ 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 Format of Request for Removing Path Segment NLRI 1887 The format of Reply for Removing Path Segment NLRI (NLRI-Type = 4) is 1888 illustrated below. 1890 0 1 2 3 1891 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 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | NLRI-Type (4) | NLRI-Length | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 ~ Controller Request Parameters (variable) ~ 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 ~ Tunnel-ID-Info (variable) ~ 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 ~ Status (variable) ~ 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 ~ Error Code and Reasons (variable) ~ 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 Format of Reply for Removing Path Segment NLRI 1906 The format of Request for Keeping Path Segment NLRI (NLRI-Type = 5) 1907 is illustrated below. 1909 0 1 2 3 1910 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 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | NLRI-Type (5) | NLRI-Length | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 ~ Controller Request Parameters (variable) ~ 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 ~ Tunnel-ID-Info (variable) ~ 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 ~ Segment List (variable) ~ 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 Format of Request for Keeping Path Segment NLRI 1923 The format of Reply for Keeping Path Segment NLRI (NLRI-Type = 6) is 1924 illustrated below. 1926 0 1 2 3 1927 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 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | NLRI-Type (6) | NLRI-Length | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 ~ Controller Request Parameters (variable) ~ 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 ~ Tunnel-ID-Info (variable) ~ 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 ~ Status (variable) ~ 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 ~ Error Code and Reasons (variable) ~ 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 Format of Reply for Keeping Path Segment NLRI 1942 The format of Request for Creating Path Segment NLRI (NLRI-Type = 7) 1943 is illustrated below. 1945 0 1 2 3 1946 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 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | NLRI-Type (7) | NLRI-Length | 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 ~ Controller Request Parameters (variable) ~ 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 ~ Tunnel-ID-Info (variable) ~ 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 ~ Start-Node (variable) ~ 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 ~ End-Node (variable) ~ 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 ~ Label (variable) ~ 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 ~ Interface (variable) ~ 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 Format of Request for Creating Path Segment NLRI 1965 The format of Reply for Creating Path Segment NLRI (NLRI-Type = 8) is 1966 illustrated below. 1968 0 1 2 3 1969 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 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | NLRI-Type (8) | NLRI-Length | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 ~ Controller Request Parameters (variable) ~ 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 ~ Tunnel-ID-Info (variable) ~ 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 ~ Status (variable) ~ 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 ~ Label (variable) ~ 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 ~ Interface (variable) ~ 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 ~ Error Code and Reasons (variable) ~ 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 Format of Reply for Creating Path Segment NLRI 1988 The format of Request for Removing Tunnel Segment NLRI (NLRI-Type = 1989 9) is illustrated below. 1991 0 1 2 3 1992 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 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | NLRI-Type (9) | NLRI-Length | 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 ~ Controller Request Parameters (variable) ~ 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 ~ Tunnel-ID-Info (variable) ~ 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 Format of Request for Removing Tunnel Segment NLRI 2003 The format of Reply for Removing Tunnel Segment NLRI (NLRI-Type = 10) 2004 is illustrated below. 2006 0 1 2 3 2007 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 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | NLRI-Type (10) | NLRI-Length | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 ~ Controller Request Parameters (variable) ~ 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 ~ Tunnel-ID-Info (variable) ~ 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 ~ Status (variable) ~ 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 ~ Error Code and Reasons (variable) ~ 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 Format of Reply for Removing Tunnel Segment NLRI 2022 The format of Connection and Access Advertisement Message NLRI (NLRI- 2023 Type = 11) is illustrated below. 2025 0 1 2 3 2026 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 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | NLRI-Type (11) | NLRI-Length | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 ~ Controller Request Parameters (variable) ~ 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 ~ Inter-Domain Link List (variable) ~ 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 ~ Access-Address-List (variable) ~ 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 Format of Connection and Access Advertisement Message NLRI 2038 The format of Request for Growing SPT NLRI (NLRI-Type = 12) is 2039 illustrated below. 2041 0 1 2 3 2042 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 2043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 | NLRI-Type (12) | NLRI-Length | 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 ~ Controller Request Parameters (variable) ~ 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 ~ Start-Node (variable) ~ 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 ~ Tunnel-ID-Info (variable) ~ 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 ~ SPT (variable) ~ 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 ~ Candidate-List (variable) ~ 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 ~ Constraints (variable) ~ 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 ~ Destination Node (variable) ~ 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 Format of Request for Growing SPT NLRI 2063 The format of Reply for Growing SPT NLRI (NLRI-Type = 13) is 2064 illustrated below. 2066 0 1 2 3 2067 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 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | NLRI-Type (13) | NLRI-Length | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 ~ Controller Request Parameters (variable) ~ 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 ~ Tunnel-ID-Info (variable) ~ 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 ~ SPT (variable) ~ 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 ~ Error Code and Reasons (variable) ~ 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 Format of Reply for Growing SPT NLRI 2082 6.5.3. Controller Request Parameters TLV 2084 A Controller Request Parameters (CRP) TLV carried within each of the 2085 new messages for supporting HSCS is used to specify various 2086 parameters of a tunnel related operation request. The format of CRP 2087 TLV is as follows 2089 0 1 C 2 3 2090 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 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Type (tTBD1) | Length | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | OP |E| PTP | Flags | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | Request-ID | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 ~ Optional Sub-TLVs ~ 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 Format of Controller Request Parameters (CRP) TLV 2102 The OP (Optimization Parameter) of 4 bits in Flags field are defined 2103 as follows: 2105 +=========+================================+ 2106 | OP | Meaning (Optimize on) | 2107 +=========+================================+ 2108 | 1 | IGP metric | 2109 | 2 | TE metric | 2110 | 3 | Hop count | 2111 | 4 - 15,0| Undefined/Reserved | 2112 +=========+================================+ 2114 The Optimization Parameter (OP) is common for HSCS, DSCS and other 2115 control systems. 2117 The following flags are currently defined for HSCS: 2119 o E (Edges of Domain): E set to 1 indicating computing a shortest 2120 path segment satisfying a given set of constraints from a start 2121 node to each of the edge nodes of the domain controlled by a child 2122 controller except for the nodes in a given exception-list. 2124 The PTP (Path computation and Tunnel creation Procedure) of 4 bits in 2125 Flags field for DSCS are defined as follows: 2127 +=========+=====================================================+ 2128 | PTP | Meaning(Procedure indicated) | 2129 +=========+=====================================================+ 2130 | 1 | Master controller Controls Path computation (MCP) | 2131 | 2 | Master controller Controls Tunnel creation (MCT) | 2132 | 3 | Master controller Initiates Path computation (MIP) | 2133 | 4 | Master controller Initiates Tunnel creation (MIT) | 2134 | 5 | Master controller Initiates Path computation and | 2135 | | Tunnel creation in one round (MIPT) | 2136 | 6 - 15,0| Undefined/Reserved | 2137 +=========+=====================================================+ 2139 The following optional Sub-TLVs are currently defined for DSCS: 2141 o Request Originator: A distributed controller that originates the 2142 request. For example, the master controller is the request 2143 originator for the request initiating an end to end path 2144 computation when it sends the request to the source controller(, 2145 which is the request target controller). 2147 o Request From Controller: A distributed controller that constructs 2148 the request and from which the request is sent. For example, in 2149 step 2 of the procedure for computing path in DSCS, when 2150 distributed controller Dj sends a request message for growing SPT 2151 to the distributed controller Dk controlling the domain Y 2152 containing B, Dj is the Request From Controller and Dk is the 2153 Request Target Controller. 2155 o Request Target Controller: A distributed controller to which the 2156 request targets. 2158 The Request Originator Sub-TLV for IPv4 (RO-IPv4 for short) has the 2159 following format: 2161 0 1 2 3 2162 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 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | Type (1) | Length | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Request Originator IPv4 Address | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 ~ (Optional Sub-TLVs) ~ 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 Format of IPv4 Request Originator Sub-TLV 2172 The RO-IPv4 has a 32-bit Controller IPv4 Address for the request 2173 originator. It may contain additional Sub-TLVs. No Sub-TLVs are 2174 currently defined. 2176 A request originator is a master controller normally in a DSCS. If 2177 the master controller is not adjacent to the target controller, to 2178 which the master controller sends a request message, it sends the 2179 message to its adjacent distributed controller which is on the route 2180 to the target controller. The adjacent distributed controller is the 2181 next hop node to the target controller according to the routing 2182 table. 2184 Each of the distributed controllers along the route to the target 2185 controller of the message relays the message to its adjacent 2186 distributed controller as the next hop node to the target controller 2187 after receiving the message. When the target controller receives the 2188 message, it performs the operations as requested by the message. 2190 When a distributed controller such as a target controller sends a 2191 reply message to the request originator such as the master 2192 controller, it sends the message to its adjacent distributed 2193 controller which is on the route to the request originator if the 2194 originator is not its adjacent controller. 2196 Each of the distributed controllers along the route to the originator 2197 such as the master controller relays the reply message to its 2198 adjacent distributed controller as the next hop node to the 2199 originator after receiving the reply message. When the originator 2200 receives the reply message, it performs the operations according to 2201 the message. 2203 The Request Originator Sub-TLV for IPv6 (RO-IPv6 for short) has the 2204 following format: 2206 0 1 2 3 2207 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 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | Type (2) | Length | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | Request Originator IPv6 Address | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 ~ (Optional Sub-TLVs) ~ 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 Format of IPv6 Request Originator Sub-TLV 2217 The RO-IPv6 has a 128-bit Controller IPv6 Address for the request 2218 originator. It may contain additional Sub-TLVs. No Sub-TLVs are 2219 currently defined. 2221 The Request From Controller Sub-TLV for IPv4 (RFC-IPv4 for short) has 2222 the following format: 2224 0 1 2 3 2225 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 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 | Type (3) | Length | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | Request From Controller IPv4 Address | 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 ~ (Optional Sub-TLVs) ~ 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 Format of IPv4 Request From Controller Sub-TLV 2235 The RFC-IPv4 has a 32-bit IPv4 Address of the Request From 2236 Controller. It may contain additional Sub-TLVs. No Sub-TLVs are 2237 currently defined. 2239 If the Request From controller is not adjacent to the target 2240 controller, to which the Request From controller sends a request 2241 message, it sends the request message to its adjacent distributed 2242 controller which is on the route to the target controller. The 2243 adjacent distributed controller is the next hop node to the target 2244 controller according to the routing table. 2246 The Request From Controller Sub-TLV for IPv6 (RFC-IPv6 for short) has 2247 the following format: 2249 0 1 2 3 2250 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 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | Type (4) | Length | 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | Request From Controller IPv6 Address | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 ~ (Optional Sub-TLVs) ~ 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 Format of IPv6 Request From Controller Sub-TLV 2260 The RFC-IPv6 has a 128-bit IPv6 Address of the Request From 2261 Controller. It may contain additional Sub-TLVs. No Sub-TLVs are 2262 currently defined. 2264 The Request Target Controller Sub-TLV for IPv4 (RTC-IPv4 for short) 2265 has the following format: 2267 0 1 2 3 2268 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 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | Type (5) | Length | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | Request Target Controller IPv4 Address | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 ~ (Optional Sub-TLVs) ~ 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 Format of IPv4 Request Target Controller Sub-TLV 2278 The RTC-IPv4 has a 32-bit IPv4 Address of the Request Target 2279 Controller. It may contain additional Sub-TLVs. No Sub-TLVs are 2280 currently defined. 2282 The Request Target Controller Sub-TLV for IPv6 (RTC-IPv6 for short) 2283 has the following format: 2285 0 1 2 3 2286 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 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | Type (6) | Length | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | Request Target Controller IPv6 Address | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 ~ (Optional Sub-TLVs) ~ 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 Format of IPv6 Request Target Controller Sub-TLV 2296 The RTC-IPv6 has a 128-bit IPv6 Address of the Request Target 2297 Controller. It may contain additional Sub-TLVs. No Sub-TLVs are 2298 currently defined. 2300 6.5.4. CONNECTION and ACCESS TLVs 2302 Three TLVs for CONNECTION and ACCESS are defined: 2304 o Inter-Domain Link TLV 2306 o Access IPv4 Prefix TLV 2308 o Access IPv6 Prefix TLV 2310 The format of each of these TLVs is as follows: 2312 0 1 2 3 2313 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 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | Type (tTBD2) | Length | 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 | AS Number | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 | Area-ID Sub-TLV | 2320 ~ ~ 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 | IGP Router-ID Sub-TLV | 2323 ~ ~ 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 | Inter-Domain Link Sub-TLVs | 2326 ~ ~ 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 Format of Inter-Domain Link TLV 2330 The Inter-Domain Link TLV describes an inter-domain link and 2331 comprises a number of inter-domain link Sub-TLVs. 2333 0 1 2 3 2334 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 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Type (tTBD3) | Length | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | AS Number | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | Area-ID Sub-TLV | 2341 ~ ~ 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | Access IPv4 Prefix Sub-TLVs | 2344 ~ ~ 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 Format of Access IPv4 Prefix TLV 2348 0 1 2 3 2349 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 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | Type (tTBD4) | Length | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 | AS Number | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 | Area-ID Sub-TLV | 2356 ~ ~ 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | Access IPv6 Prefix Sub-TLVs | 2359 ~ ~ 2360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2361 Format of Access IPv6 Prefix TLV 2363 The format of the Area-ID Sub-TLV is shown below: 2365 0 1 2 3 2366 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 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | Type (1) | Length (4) | 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | Area Number | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 Format of Area-ID Sub-TLV 2374 The format of the OSPF Router-ID Sub-TLV is shown below: 2376 0 1 2 3 2377 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 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | Type (2) | Length (4) | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | OSPF Router ID | 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 Format of OSPF Router-ID Sub-TLV 2385 The format of the ISIS Router-ID Sub-TLV is shown below: 2387 0 1 2 3 2388 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 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Type (3) | Length (6) | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | ISO Node-ID ~ 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 Format of ISIS Router-ID Sub-TLV 2396 The format of the Access IPv4 Prefix Sub-TLV is shown as follows: 2398 0 1 2 3 2399 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 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Type (4) | Length | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | Prefix Length | IPv4 Prefix (variable) ~ 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 Format of Access IPv4 Prefix Sub-TLV 2407 The format of the Access IPv6 Prefix Sub-TLV is illustrated below: 2409 0 1 2 3 2410 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 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 | Type (5) | Length | 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 | Prefix Length | IPv6 Prefix (variable) ~ 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 Format of Access IPv6 Prefix Sub-TLV 2418 A number of Inter-Domain link Sub-TLVs are defined: 2420 o Inter-Domain Link Type Sub-TLV 2422 o Remote AS Number ID Sub-TLV 2424 o Remote Area-ID Sub-TLV 2426 o Remote OSPF Router-ID Sub-TLV 2428 o Remote ISIS Router-ID Sub-TLV 2429 o IPv4 Remote ASBR ID Sub-TLV 2431 o IPv6 Remote ASBR ID Sub-TLV 2433 o Local Interface IPv4 Address Sub-TLV 2435 o Local Interface IPv6 Address Sub-TLV 2437 o Remote Interface IPv4 Address Sub-TLV 2439 o Remote Interface IPv6 Address Sub-TLV 2441 The format of the Inter-Domain Link Type Sub-TLV is illustrated 2442 below: 2444 0 1 2 3 2445 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 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Type (6) | Length (1) | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | Inter-Domain Link Type | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 Format of Inter-Domain Link Type Sub-TLV 2453 The Inter-Domain Link Type sub-TLV defines the type of the inter- 2454 domain link: 2456 1 - Point-to-point 2458 2 - Multi-access 2460 The Inter-Domain Link Type sub-TLV is TLV type 1, and is one octet in 2461 length. 2463 The format of the Remote AS Number ID Sub-TLV is illustrated below: 2465 0 1 2 3 2466 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 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | Type (7) | Length (4) | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 | Remote AS Number | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 Format of Remote AS Number ID Sub-TLV 2474 The Remote AS Number field has 4 octets. When only two octets are 2475 used for the AS number, as in current deployments, the left (high- 2476 order) two octets MUST be set to zero. 2478 The format of the Remote Area-ID Sub-TLV is shown below: 2480 0 1 2 3 2481 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 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | Type (8) | Length (4) | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | Area Number | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 Format of Remote Area-ID Sub-TLV 2489 The format of the Remote OSPF Router-ID Sub-TLV is shown below: 2491 0 1 2 3 2492 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 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Type (9) | Length (4) | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | OSPF Router ID | 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 Format of Remote OSPF Router-ID Sub-TLV 2500 The format of the Remote ISIS Router-ID Sub-TLV is shown below: 2502 0 1 2 3 2503 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 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | Type (10) | Length (6) | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | ISO Node-ID ~ 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 Format of Remote ISIS Router-ID Sub-TLV 2511 The format of the IPv4 Remote ASBR ID Sub-TLV is illustrated below: 2513 0 1 2 3 2514 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 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | Type (11) | Length (4) | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | IPv4 Remote ASBR ID | 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 Format of IPv4 Remote ASBR ID Sub-TLV 2522 The IPv4 Remote ASBR ID sub-TLV MUST be included if the neighboring 2523 ASBR has an IPv4 address. 2525 The format of the IPv6 Remote ASBR ID Sub-TLV is illustrated below: 2527 0 1 2 3 2528 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 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | Type (12) | Length (16) | 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | IPv6 Remote ASBR ID | 2533 ~ (16 Bytes) ~ 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Format of IPv6 Remote ASBR ID Sub-TLV 2537 The IPv6 Remote ASBR ID sub-TLV MUST be included if the neighboring 2538 ASBR has an IPv6 address. 2540 The format of the Local Interface IPv4 Address Sub-TLV is shown 2541 below: 2543 0 1 2 3 2544 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 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | Type (13) | Length | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 | Local Interface IPv4 Address(es) | 2549 ~ ~ 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 Format of Local Interface IPv4 Address Sub-TLV 2553 The Local Interface IPv4 Address sub-TLV specifies the IPv4 2554 address(es) of the interface corresponding to the inter-domain link. 2555 If there are multiple local addresses on the link, they are all 2556 listed in this sub-TLV. 2558 The Local Interface IPv4 Address sub-TLV is TLV type 8, and is 4N 2559 octets in length, where N is the number of local IPv4 addresses. 2561 The format of the Local Interface IPv6 Address Sub-TLV is illustrated 2562 below: 2564 0 1 2 3 2565 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 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | Type (14) | Length | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | Local Interface IPv6 Address(es) | 2570 ~ ~ 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 Format of Local Interface IPv6 Address Sub-TLV 2574 The Local Interface IPv6 Address sub-TLV specifies the IPv6 2575 address(es) of the interface corresponding to the inter-domain link. 2576 If there are multiple local addresses on the link, they are all 2577 listed in this sub-TLV. 2579 The Local Interface IPv6 Address sub-TLV is TLV type 9, and is 16N 2580 octets in length, where N is the number of local IPv6 addresses. 2582 The format of the Remote Interface IPv4 Address Sub-TLV is 2583 illustrated below: 2585 0 1 2 3 2586 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 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 | Type (15) | Length | 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 | Neighbor Interface IPv4 Address(es) | 2591 ~ ~ 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 Format of Remote Interface IPv4 Address Sub-TLV 2595 The Remote Interface IPv4 Address sub-TLV specifies the IPv4 2596 address(es) of the neighbor's interface corresponding to the inter- 2597 domain link. This and the local address are used to discern multiple 2598 parallel links between systems. If there are multiple remote 2599 addresses on the link, they are all listed in this sub-TLV. 2601 The Remote Interface IPv4 Address sub-TLV is TLV type 10, and is 4N 2602 octets in length, where N is the number of neighbor IPv4 addresses. 2604 The format of the Remote Interface IPv6 Address Sub-TLV is 2605 illustrated below: 2607 0 1 2 3 2608 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 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | Type (16) | Length | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | Neighbor Interface IPv6 Address(es) | 2613 ~ ~ 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 Format of Remote Interface IPv6 Address Sub-TLV 2617 The Remote Interface IPv6 Address sub-TLV specifies the IPv6 2618 address(es) of the neighbor's interface corresponding to the inter- 2619 domain link. If there are multiple neighbor addresses on the link, 2620 they are all listed in this sub-TLV. 2622 The Remote Interface IPv6 Address sub-TLV is TLV type 11, and is 16N 2623 octets in length, where N is the number of neighbor IPv6 addresses. 2625 6.5.5. NODE TLVs 2627 A number of Node TLVs are defined below: 2629 1. IPv4 START-NODE TLV 2631 2. IPv6 START-NODE TLV 2633 3. IPv4 DESTINATION-NODE-LIST TLV 2635 4. IPv6 DESTINATION-NODE-LIST TLV 2637 5. IPv4 SEGMENT-END-NODE-LIST TLV 2639 6. IPv6 SEGMENT-END-NODE-LIST TLV 2641 7. IPv4 EXCEPTION-LIST TLV 2643 8. IPv6 EXCEPTION-LIST TLV 2645 9. IPv4 CANDIDATE-LIST TLV 2647 10. IPv6 CANDIDATE-LIST TLV 2649 11. NODE-COST-LIST TLV 2651 The format of IPv4 START-NODE TLV is as follows: 2653 0 1 2 3 2654 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 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | Type (tTBD5) | Length | 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 | Start Node IPv4 Address | 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 Format of IPv4 START-NODE TLV 2662 The Start Node IPv4 Address is the IPv4 address of a start node. 2664 The format of IPv6 START-NODE TLV is as follows: 2666 0 1 2 3 2667 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 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 | Type (tTBD6) | Length | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | Start Node IPv6 Address | 2672 ~ (16 bytes) ~ 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 Format of IPv6 START-NODE TLV 2676 The Start Node IPv6 Address is the IPv6 address of a start node. 2678 The format of IPv4 DESTINATION-NODE-LIST TLV is as follows: 2680 0 1 2 3 2681 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 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | Type (tTBD7) | Length | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | Destination Node 1 IPv4 Address | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 | . . . . . . | 2688 ~ ~ 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | Destination Node n IPv4 Address | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 Format of IPv4 DESTINATION-NODE-LIST TLV 2694 The IPv4 DESTINATION-NODE-LIST contains n destination node IPv4 2695 addresses. An IPv4 DESTINATION-NODE-LIST is also called an IPv4 2696 DESTINATION-NODES. 2698 The format of IPv6 DESTINATION-NODE-LIST TLV is as follows: 2700 0 1 2 3 2701 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 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | Type (tTBD8) | Length | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | Destination Node 1 IPv6 Address | 2706 ~ (16 bytes) ~ 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 | . . . . . . | 2709 ~ ~ 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | Destination Node n IPv6 Address | 2712 ~ (16 bytes) ~ 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 Format of IPv6 DESTINATION-NODE-LIST TLV 2716 The IPv6 DESTINATION-NODE-LIST contains n destination node IPv6 2717 addresses. An IPv6 DESTINATION-NODE-LIST is also called an IPv6 2718 DESTINATION-NODES. 2720 The format of IPv4 SEGMENT-END-NODE-LIST TLV is as follows: 2722 0 1 2 3 2723 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 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Type (tTBD9) | Length | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Segment End Node 1 IPv4 Address | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | . . . . . . | 2730 ~ ~ 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 | Segment End Node n IPv4 Address | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 Format of IPv4 SEGMENT-END-NODE-LIST TLV 2736 The IPv4 SEGMENT-END-NODE-LIST contains n segment node IPv4 2737 addresses. An IPv4 SEGMENT-END-NODE-LIST is also called an IPv4 2738 SEGMENT-END-NODES. 2740 The format of IPv6 SEGMENT-END-NODE-LIST TLV is as follows: 2742 0 1 2 3 2743 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 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | Type (tTBD10) | Length | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 | Segment End Node 1 IPv6 Address | 2748 ~ (16 bytes) ~ 2749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2750 | . . . . . . | 2751 ~ ~ 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | Segment End Node n IPv6 Address | 2754 ~ (16 bytes) ~ 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 Format of IPv6 SEGMENT-END-NODE-LIST TLV 2758 The IPv6 SEGMENT-END-NODE-LIST contains n segment end node IPv6 2759 addresses. An IPv6 SEGMENT-END-NODE-LIST is also called an IPv6 2760 SEGMENT-END-NODES. 2762 The format of IPv4 EXCEPTION-LIST TLV is as follows: 2764 0 1 2 3 2765 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 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 | Type (tTBD11) | Length | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | Exception Node 1 IPv4 Address | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | . . . . . . | 2772 ~ ~ 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | Exception Node n IPv4 Address | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 Format of IPv4 EXCEPTION-LIST TLV 2778 The IPv4 EXCEPTION-LIST contains n node IPv4 addresses in an 2779 exception-list. An IPv4 EXCEPTION-LIST is also called an IPv4 2780 EXCEPTION-NODE-LIST. 2782 The format of IPv6 EXCEPTION-LIST TLV is as follows: 2784 0 1 2 3 2785 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 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 | Type (tTBD12) | Length | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | Exception Node 1 IPv6 Address | 2790 ~ (16 bytes) ~ 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 | . . . . . . | 2793 ~ ~ 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 | Exception Node n IPv6 Address | 2796 ~ (16 bytes) ~ 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 Format of IPv6 EXCEPTION-LIST TLV 2800 The IPv6 EXCEPTION-LIST contains n node IPv6 addresses in an 2801 exception-list. An IPv6 EXCEPTION-LIST is also called an IPv6 2802 EXCEPTION-NODE-LIST. 2804 The format of IPv4 CANDIDATE-LIST TLV is as follows: 2806 0 1 2 3 2807 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 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 | Type (tTBD13) | Length | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 ~ IPv4 Candidate-Node Sub-TLV ~ 2812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2813 | . . . . . . | 2814 ~ ~ 2815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2816 ~ IPv4 Candidate-Node Sub-TLV ~ 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2818 Format of IPv4 CANDIDATE-LIST TLV 2820 The IPv4 CANDIDATE-LIST contains the information about each of IPv4 2821 nodes in an candidate-list, which is represented in an IPv4 2822 Candidate-Node Sub-TLV. 2824 The format of IPv6 CANDIDATE-LIST TLV is as follows: 2826 0 1 2 3 2827 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 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | Type (tTBD14) | Length | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 ~ IPv6 Candidate-Node Sub-TLV ~ 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 | . . . . . . | 2834 ~ ~ 2835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 | IPv4 Candidate-Node Sub-TLV | 2837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2838 Format of IPv6 CANDIDATE-LIST TLV 2840 The IPv4 CANDIDATE-LIST contains the information about each of IPv4 2841 nodes in an candidate-list, which is represented in an IPv4 2842 Candidate-Node Sub-TLV. 2844 The format of NODE-COST-LIST TLV is as follows: 2846 0 1 2 3 2847 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 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 | Type (tTBD15) | Length | 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 | Node 1 Cost | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 | . . . . . . | 2854 ~ ~ 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 | Node n Cost | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 Format of NODE-COST-LIST TLV 2860 The NODE-COST-LIST contains n costs for n segment end nodes. The 2861 type of cost is determined by the value of Optimization Parameter in 2862 Controller Request Parameters TLV. 2864 The format of IPv4 Candidate-Node Sub-TLV is as follows: 2866 0 1 2 3 2867 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 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | Type (1) | Length | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 | Candidate-Node IPv4 Address | 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 | Previous-Hop Node IPv4 Address | 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 | Candidate-Node Cost | 2876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2877 Format of IPv4 Candidate-Node Sub-TLV 2879 The Candidate-Node IPv4 Address indicates the IPv4 address of the 2880 candidate node. The Previous-Hop Node IPv4 Address is the IPv4 2881 address of the previous hop node of the candidate node. The 2882 Candidate-Node Cost indicates the cost to the candidate node. The 2883 type of the cost is determined by the value of Optimization Parameter 2884 in Controller Request Parameters TLV. 2886 The format of IPv6 Candidate-Node Sub-TLV is as follows: 2888 0 1 2 3 2889 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 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Type (2) | Length | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 | Candidate-Node IPv6 Address | 2894 ~ (16 bytes) ~ 2895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2896 | Previous-Hop Node IPv6 Address | 2897 ~ (16 bytes) ~ 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2899 | Candidate-Node Cost | 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 Format of IPv6 Candidate-Node Sub-TLV 2903 The Candidate-Node IPv6 Address indicates the IPv6 address of the 2904 candidate node. The Previous-Hop Node IPv6 Address is the IPv6 2905 address of the previous hop node of the candidate node. The 2906 Candidate-Node Cost indicates the cost to the candidate node. The 2907 type of the cost is determined by the value of Optimization Parameter 2908 in Controller Request Parameters TLV. 2910 6.5.6. TUNNEL-ID-Info TLV 2912 The format of TUNNEL-ID-Info TLV is as follows: 2914 0 1 2 3 2915 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 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 | Type (tTBD16) | Length | 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 | Tunnel ID | 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | Path ID | Reserved(MUST be zero) | 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 ~ Optional Sub_TLVs ~ 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 Format of TUNNEL-ID-Info TLV 2927 The Tunnel ID is a 32-bit unique number for identifying a tunnel 2928 globally. The Path ID is a 16-bit number for uniquely identifying a 2929 path under a tunnel. 2931 When the Path ID is zero, the TUNNEL-ID-Info indicates all the paths 2932 or path segments under the Tunnel ID if it is used to indicate paths 2933 or path segments. 2935 6.5.7. STATUS TLV 2937 The format of STATUS TLV has following format: 2939 0 1 2 3 2940 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 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | Type (tTBD17) | Length | 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2944 | Status Code | Reason | Reserved | 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 ~ Optional TLVs ~ 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 Format of STATUS TLV 2950 The status code (or status for short) in a STATUS may be one of the 2951 followings: 2953 1 (SUCCESS): Indicating a request is successfully finished. 2955 2 (FAIL): Indicating a request can not be finished. 2957 When the status is FAIL, the Reason gives a reason for the failure 2958 and the Optional TLVs give some more details about failure. 2960 6.5.8. LABEL TLV 2962 The format of LABEL TLV has following format: 2964 0 1 2 3 2965 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 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 | Type (tTBD18) | Length | 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | (top label) | 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 Format of Label TLV 2973 The contents of a LABEL is a single label, encoded in 4 octets. 2975 6.5.9. INTERFACE TLVs 2977 Three TLVs for Interface are defined: 2979 1. Interface Index TLV 2981 2. Interface IPv4 Address TLV 2983 3. Interface IPv6 Address TLV 2985 The format of interface index TLV has following format: 2987 0 1 2 3 2988 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 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 | Type (tTBD19) | Length | 2991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2992 | Interface Index | 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2994 Format of Interface Index TLV 2996 The Interface Index is a single interface index, encoded in 4 octets. 2998 The format of interface IPv4 address TLV has following format: 3000 0 1 2 3 3001 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 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3003 | Type (tTBD20) | Length | 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3005 | Interface IPv4 Address | 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 Format of Interface IPv4 Address TLV 3009 The Interface IPv4 Address is a single interface IPv4 address, 3010 encoded in 4 octets. 3012 The format of interface IPv6 address TLV has following format: 3014 0 1 2 3 3015 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 3016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 | Type (tTBD21) | Length | 3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 | Interface IPv6 Address | 3020 ~ (16 bytes) ~ 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 Format of Interface IPv6 Address TLV 3024 The Interface IPv6 Address is a single interface IPv6 address, 3025 encoded in 16 octets. 3027 6.5.10. CONSTRAINS TLVs 3029 Three TLVs for Constrains are defined: 3031 1. BANDWIDTH TLV 3033 2. LSPA (LSP Attributes) TLV 3035 3. ER (Explicit Route) TLV 3037 The format of BANDWIDTH TLV has following format: 3039 0 1 2 3 3040 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 3041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3042 | Type (tTBD22) | Length | 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3044 | Bandwidth | 3045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3046 Format of BANDWIDTH TLV 3048 The Bandwidth is encoded in 32 bits in IEEE floating point format 3049 (see [IEEE.754.1985]), expressed in bytes per second. Refer to 3050 Section 3.1.2 of [RFC3471] for a table of commonly used values. 3052 The format of LSPA TLV has following format: 3054 0 1 2 3 3055 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 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 | Type (tTBD23) | Length | 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 | Exclude-any | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3061 | Include-any | 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3063 | Exclude-all | 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 | Setup Prio | Holding Prio | Flags |L| Reserved | 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3067 ~ Optional Sub-TLVs ~ 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 Format of LSPA TLV 3071 Setup Prio (Setup Priority - 8 bits): The priority of the TE LSP 3072 with respect to taking resources, in the range of 0 to 7. The 3073 value 0 is the highest priority. The Setup Priority is used in 3074 deciding whether this session can preempt another session. 3076 Holding Prio (Holding Priority - 8 bits): The priority of the TE LSP 3077 with respect to holding resources, in the range of 0 to 7. The 3078 value 0 is the highest priority. Holding Priority is used in 3079 deciding whether this session can be preempted by another session. 3081 Flags (8 bits) 3083 L flag: Corresponds to the "Local Protection Desired" bit 3084 ([RFC3209]) of the SESSION-ATTRIBUTE Object. When set, this 3085 means that the computed path must include links protected with 3086 Fast Reroute as defined in [RFC4090]. 3088 Unassigned flags: MUST be set to zero on transmission and MUST be 3089 ignored on receipt. 3091 Reserved (8 bits): This field MUST be set to zero on transmission 3092 and MUST be ignored on receipt. 3094 The format of ER TLV is shown below: 3096 0 1 2 3 3097 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 3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3099 | Type (tTBD24) | Length | 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 ~ Node Sub-TLV ~ 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3103 ~ . . . . . . ~ 3104 ~ ~ 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 ~ Node Sub-TLV ~ 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 Format of ER TLV 3110 Where the Node Sub-TLVs are defined in the following section. 3112 6.5.11. SPT TLV 3114 The information about a SPT is encoded using explicit route (ER) and 3115 secondary explicit route (SER) Sub-TLVs in a compression format. The 3116 Figure below illustrates a SPT with A as its root and five leaves F, 3117 N, O, P and Q. 3119 A 3120 | 3121 | 3122 B 3123 | 3124 | 3125 C----D----E 3126 | | | 3127 | | | 3128 F G H-------I 3129 | |\ | 3130 | | \ | 3131 J K L M 3132 | | | | 3133 | | | | 3134 N O P Q 3136 One way to encode the SPT in compression is as follows: 3138 Branch A-F: ER Sub-TLV = {A, B, E, D, C, F, c2F} 3139 Branch A-N: SER Sub-TLV = {D, G, J, N, c2N} 3140 Branch A-O: SER Sub-TLV = {E, H, K, O, c2O} 3141 Branch A-P: SER Sub-TLV = {H, L, P, c2P} 3142 Branch A-Q: SER Sub-TLV = {H, I, M, Q, c2Q} 3144 Where for each of the five leaf nodes, it is followed by the cost to 3145 it from the root. For example, leaf node F is followed by cost c2F, 3146 which is the cost to F from root A. 3148 In this compressed encoding, the potential repetition of path 3149 information for multiple branches that share path segments in the SPT 3150 is eliminated. 3152 The format of SPT TLV has following format: 3154 0 1 2 3 3155 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 3156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3157 | Type (tTBD25) | Length | 3158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 ~ ER Sub-TLV ~ 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 ~ SER Sub-TLV ~ 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 ~ . . . . . . ~ 3164 ~ ~ 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 ~ SER Sub-TLV ~ 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 Format of SPT TLV 3170 A SPT TLV contains one ER Sub-TLV, which may be followed by a number 3171 of SER Sub-TLVs. 3173 The format of ER Sub-TLV has following format: 3175 0 1 2 3 3176 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 3177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3178 | Type (1) | Length | 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 ~ Node Sub-TLV ~ 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 ~ . . . . . . ~ 3183 ~ ~ 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 ~ Node Sub-TLV ~ 3186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 ~ Cost2Node Sub-TLV ~ 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 Format of ER Sub-TLV 3191 An ER Sub-TLV contains a number of Node Sub-TLVs, each of which 3192 represents a node for a branch in a SPT. The branch is from the root 3193 of the SPT to a leaf of the SPT. The order of the Node Sub-TLVs in 3194 the ER TLV MUST be the same as the order of the nodes in the branch. 3195 Following the last Node Sub-TLV is a Cost2Node Sub-TLV, which 3196 indicates the cost to the node represented in the last Node Sub-TLV 3197 from the root of the SPT. 3199 The format of SER Sub-TLV is the same as that of ER Sub-TLV. It is 3200 illustrated below: 3202 0 1 2 3 3203 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 3204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3205 | Type (2) | Length | 3206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3207 ~ Node Sub-TLV ~ 3208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 ~ . . . . . . ~ 3210 ~ ~ 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 ~ Node Sub-TLV ~ 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 ~ Cost2Node Sub-TLV ~ 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 Format of SER Sub-TLV 3218 There are three types of Node Sub-TLVs, which are listed as follows: 3220 1 IPv4 prefix 3221 2 IPv6 prefix 3222 3 Autonomous System Number (ASN) 3224 There is one type of Cost2Node Sub-TLV. The type of the cost 3225 represented in the Sub-TLV is determined by the Optimization 3226 Parameter in Controller Request Parameters TLV. 3228 The format of IPv4 prefix Node Sub-TLV is shown below: 3230 0 1 2 3 3231 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 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 | Type (1) | Length | 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 | IPv4 address (4 bytes) | 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3237 | Prefix Length |L| Reserved (MUST be zero) | 3238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3239 Format of IPv4 prefix Node Sub-TLV 3241 The L bit is set to 1 if the Sub-TLV represents a loose hop. If the 3242 bit is not set (i.e., it is 0), the Sub-TLV represents a strict hop. 3244 The format of IPv6 prefix Node Sub-TLV is shown below: 3246 0 1 2 3 3247 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 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 | Type (2) | Length | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | IPv6 address (16 bytes) | 3252 ~ ~ 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 | Prefix Length |L| Reserved (MUST be zero) | 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 Format of IPv6 prefix Node Sub-TLV 3258 The L bit is set to 1 if the Sub-TLV represents a loose hop. If the 3259 bit is not set (i.e., it is 0), the Sub-TLV represents a strict hop. 3261 The format of ASN Node Sub-TLV is shown below: 3263 0 1 2 3 3264 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 3265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3266 | Type (3) | Length | 3267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 | Autonomous System Number | 3269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3270 Format of ASN Node Sub-TLV 3272 The format of Cost2Node Sub-TLV is shown below: 3274 0 1 2 3 3275 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 3276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3277 | Type (4) | Length | 3278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3279 | Cost | 3280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3281 Format of Cost2Node Sub-TLV 3283 7. Security Considerations 3285 The mechanism described in this document does not raise any new 3286 security issues for the BGP protocols. 3288 8. IANA Considerations 3290 This section specifies requests for IANA allocation. 3292 9. Acknowledgement 3294 The authors would like to thank people for their valuable comments on 3295 this draft. 3297 10. References 3299 10.1. Normative References 3301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3302 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 3303 RFC2119, March 1997, 3304 . 3306 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 3307 (BGP-4)", RFC 1771, DOI 10.17487/RFC1771, March 1995, 3308 . 3310 [RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement 3311 with BGP-4", RFC 2842, DOI 10.17487/RFC2842, May 2000, 3312 . 3314 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 3315 "Multiprotocol Extensions for BGP-4", RFC 2858, 3316 DOI 10.17487/RFC2858, June 2000, 3317 . 3319 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 3320 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 3321 . 3323 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 3324 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 3325 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 3326 . 3328 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 3329 Switching (GMPLS) Signaling Resource ReserVation Protocol- 3330 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 3331 DOI 10.17487/RFC3473, January 2003, 3332 . 3334 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 3335 in Resource ReSerVation Protocol - Traffic Engineering 3336 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 3337 . 3339 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 3340 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 3341 DOI 10.17487/RFC4090, May 2005, 3342 . 3344 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 3345 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 3346 DOI 10.17487/RFC4271, January 2006, 3347 . 3349 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 3350 "Multiprotocol Extensions for BGP-4", RFC 4760, 3351 DOI 10.17487/RFC4760, January 2007, 3352 . 3354 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 3355 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, 3356 February 2009, . 3358 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 3359 Support of Inter-Autonomous System (AS) MPLS and GMPLS 3360 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 3361 January 2009, . 3363 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 3364 Support of Inter-Autonomous System (AS) MPLS and GMPLS 3365 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 3366 December 2008, . 3368 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 3369 Engineering", RFC 5305, DOI 10.17487/RFC5305, 3370 October 2008, . 3372 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 3373 (TE) Extensions to OSPF Version 2", RFC 3630, 3374 DOI 10.17487/RFC3630, September 2003, 3375 . 3377 10.2. Informative References 3379 [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing 3380 Domains: A model for routing in the Internet", RFC 1136, 3381 DOI 10.17487/RFC1136, December 1989, 3382 . 3384 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 3385 Path Computation Element Architecture to the Determination 3386 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 3387 DOI 10.17487/RFC6805, November 2012, 3388 . 3390 Authors' Addresses 3392 Huaimo Chen 3393 Huawei Technologies 3394 Boston, MA, 3395 USA 3397 EMail: Huaimo.chen@huawei.com 3398 Susan Hares 3399 Huawei Technologies 3400 Karnataka 3402 EMail: shares@ndzh.com 3404 Yi Yang 3405 Sockrate 3406 USA 3408 EMail: yyang1998@gmail.com 3410 Yanhe Fan 3411 Casa Systems, Inc. 3412 USA 3414 EMail: yfan@casa-systems.com 3416 Mehmet Toy 3417 Verizon 3418 USA 3420 EMail: mehmet.toy@verizon.com 3422 Zhenqiang Li 3423 China Mobile 3424 No.32 Xuanwumenxi Ave., Xicheng District 3425 Beijing 100032 3426 P.R. China 3428 EMail: li_zhenqiang@hotmail.com 3430 Lei Liu 3431 Fujitsu 3432 USA 3434 EMail: lliu@us.fujitsu.com