idnits 2.17.1 draft-chen-pce-h-sdns-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4655' is defined on line 2439, but no explicit reference was found in the text == Unused Reference: 'RFC5441' is defined on line 2449, but no explicit reference was found in the text == Unused Reference: 'RFC5392' is defined on line 2456, but no explicit reference was found in the text == Unused Reference: 'RFC5316' is defined on line 2461, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 2466, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 2470, but no explicit reference was found in the text == Unused Reference: 'RFC1136' is defined on line 2477, but no explicit reference was found in the text == Unused Reference: 'RFC4105' is defined on line 2482, but no explicit reference was found in the text == Unused Reference: 'RFC4216' is defined on line 2487, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 2492, but no explicit reference was found in the text == Unused Reference: 'RFC6805' is defined on line 2499, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track M. Toy 5 Expires: May 4, 2017 6 L. Liu 7 Fujitsu 8 V. Liu 9 China Mobile 10 October 31, 2016 12 PCE Hierarchical SDNs 13 draft-chen-pce-h-sdns-01 15 Abstract 17 This document presents extensions to the Path Computation Element 18 Communication Protocol (PCEP) for supporting a hierarchical SDN 19 control system, which comprises multiple SDN controllers controlling 20 a network with a number of domains. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 4, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Conventions Used in This Document . . . . . . . . . . . . . . 6 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Overview of Hierarchical SDN Control System . . . . . . . . . 6 61 6. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 9 63 6.2. New Messages for Hierarchical SDN Control System . . . . . 10 64 6.2.1. Contents of Messages . . . . . . . . . . . . . . . . . 12 65 6.2.2. Individual Encoding of Messages . . . . . . . . . . . 24 66 6.2.3. Group Encoding of Messages . . . . . . . . . . . . . . 25 67 6.2.4. Embedded Encoding of Messages . . . . . . . . . . . . 26 68 6.2.5. Mixed Encoding of Messages . . . . . . . . . . . . . . 27 69 6.3. Controller Relation Discovery . . . . . . . . . . . . . . 27 70 6.3.1. Using Open Message . . . . . . . . . . . . . . . . . . 27 71 6.3.2. Using Discovery Message . . . . . . . . . . . . . . . 29 72 6.4. Connections and Accesses Advertisement . . . . . . . . . . 30 73 6.5. Tunnel Creation . . . . . . . . . . . . . . . . . . . . . 30 74 6.5.1. Computing Path in Two Rounds . . . . . . . . . . . . . 31 75 6.5.2. Computing Path in One Round . . . . . . . . . . . . . 32 76 6.5.3. Creating Tunnel along Path . . . . . . . . . . . . . . 34 77 6.6. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . 36 78 6.6.1. CRP Objects . . . . . . . . . . . . . . . . . . . . . 36 79 6.6.2. LOCAL-CONTROLLER Object . . . . . . . . . . . . . . . 37 80 6.6.3. REMOTE-CONTROLLER Object . . . . . . . . . . . . . . . 38 81 6.6.4. CONNECTION and ACCESS Object . . . . . . . . . . . . . 40 82 6.6.5. NODE Object . . . . . . . . . . . . . . . . . . . . . 47 83 6.6.6. TUNNEL Object . . . . . . . . . . . . . . . . . . . . 53 84 6.6.7. STATUS Object . . . . . . . . . . . . . . . . . . . . 54 85 6.6.8. LABEL Object . . . . . . . . . . . . . . . . . . . . . 54 86 6.6.9. INTERFACE Object . . . . . . . . . . . . . . . . . . . 55 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 89 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 56 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 57 93 Appendix A. Details on Embedded Encoding of Messages . . . . . . 58 94 A.1. Message for Controller Relation Discovery . . . . . . . . 58 95 A.2. Message for Connections and Accesses Advertisement . . . . 60 96 A.3. Request for Computing Path Segments . . . . . . . . . . . 60 97 A.4. Reply for Computing Path Segments . . . . . . . . . . . . 61 98 A.5. Request for Removing Path Segments . . . . . . . . . . . . 61 99 A.6. Reply for Removing Path Segments . . . . . . . . . . . . . 62 100 A.7. Request for Keeping Path Segments . . . . . . . . . . . . 62 101 A.8. Reply for Keeping Path Segments . . . . . . . . . . . . . 63 102 A.9. Request for Creating Tunnel Segment . . . . . . . . . . . 63 103 A.10. Reply for Creating Tunnel Segment . . . . . . . . . . . . 64 104 A.11. Request for Removing Tunnel Segment . . . . . . . . . . . 64 105 A.12. Reply for Removing Tunnel Segment . . . . . . . . . . . . 65 107 1. Introduction 109 A domain is a collection of network elements within a common sphere 110 of address management or routing procedure which are operated by a 111 single organization or administrative authority. Examples of such 112 domains include IGP (OSPF or IS-IS) areas and Autonomous Systems. 114 For scalability, security, interoperability and manageability, a big 115 network is organized as a number of domains. For example, a big 116 network running OSPF as routing protocol is organized as a number of 117 OSPF areas. A network running BGP is organized as multiple 118 Autonomous Systems, each of which has a number of IGP areas. 120 The concepts of Software Defined Networks (SDN) have been shown to 121 reduce the overall network CapEx and OpEx, whilst facilitating the 122 deployment of services and enabling new features. The core 123 principles of SDN include: centralized control to allow optimized 124 usage of network resources and provisioning of network elements 125 across domains. 127 For a network with a number of domains, it is natural to have 128 multiple SDN controllers, each of which controls a domain in the 129 network. To achieve a centralized control on the network, a 130 hierarchical architecture of controllers is a good fit. At top level 131 of the hierarchy, it is a parent controller that is not a child 132 controller. The parent controller controls a number of child 133 controllers. Some of these child controllers are not parent 134 controllers. Each of them controls a domain. Some other child 135 controllers are also parent controllers, each of which controls 136 multiple child controllers, and so on. 138 This document presents extensions to the Path Computation Element 139 Communication Protocol (PCEP) for supporting a hierarchical SDN 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 PCE 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 PCE 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 PID: Path Identifier. It is used to identify a path for a tunnel in 198 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 PCC: Path Computation Client. Any client application requesting a 209 path computation to be performed by a Path Computation Element. 211 PCE: Path Computation Element. An entity (component, application, 212 or network node) that is capable of computing a network path or 213 route based on a network graph and applying computational 214 constraints. 216 PCE(i): a PCE with the scope of domain(i). 218 TED: Traffic Engineering Database. 220 This document uses terminology defined in [RFC5440]. 222 3. Conventions Used in This Document 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in [RFC2119]. 228 4. Requirements 230 This section summarizes the requirements for Hierarchical SDN Control 231 System (need more text here). 233 5. Overview of Hierarchical SDN Control System 235 The Figure below illustrates a hierarchical SDN control system. 236 There is one Parent Controller and four Child Controllers: Child 237 Controller 1, Child Controller 2, Child Controller 3 and Child 238 Controller 4. 240 +-------------------+ 241 | Parent Controller | 242 +--+---------+----+-+ 243 _/| \ \____ 244 _/ | \ \____ 245 _/ | \ \__ 246 __/ | +---------+---------+ \ 247 __/ | |Child Controller 3 | | 248 / | +-------------------+ | 249 +---------+---------+ | / \ | 250 |Child Controller 1 | | .---. .---,\ | 251 +-------------------+ | ( ' ') | 252 / \ | ( Domain 3 ) | 253 .---. .---,\ | ( ) +---------+---------+ 254 ( ' ') | '-o-.--o) |Child Controller 4 | 255 ( Domain 1 ) | | +-------------------+ 256 ( ) | | / \____ 257 '-o-.---) +--------+----------+ \ / \ \____ 258 | |Child Controller 2 | \ /\ .---. .---+ \ 259 | +-------------------+ \ | \( ' |'.---. | 260 | / \____ \_ |---\ Domain 4 | '+, 261 \ / \ \____ (o \ | | ) 262 \ /\ .---. .---+ \ ( | | o) 263 \ | \( ' |'.---. | ( | | ) 264 \ |---\ Domain 2 | '+. ( o o .-' 265 \____(o \ | | ) ' ) 266 ( | | o)-------o---._.-.-----) 267 ( | | ) 268 ( o o .-' 269 ' ) 270 '---._.-.-----) 272 The parent controller communicates with these four child controllers 273 and controls them, each of which controls (or is responsible for) a 274 domain. Child controller 1 controls domain 1, Child controller 2 275 controls domain 2, Child controller 3 controls domain 3, and Child 276 controller 4 controls domain 4. 278 One level of hierarchy of controllers is illustrated in the figure 279 above. There is one parent controller at top level, which is not a 280 child controller. Under the parent controller, there are four child 281 controllers, which are not parent controllers. 283 In a general case, at top level there is one parent controller that 284 is not a child controller, there are some controllers that are both 285 parent controllers and child controllers, and there are a number of 286 child controllers that are not parent controllers. This is a system 287 of multiple levels of hierarchies, in which one parent controller 288 controls or communicates with a first number of child controllers, 289 some of which are also parent controllers, each of which controls or 290 communicates with a second number of child controllers, and so on. 292 Considering one parent controller and its child controllers, each of 293 the child controllers controls a domain and has the topology 294 information on the domain, the parent controller does not have the 295 topology information on any domain controlled by a child controller 296 normally. This is called parent without domain topology. 298 In some special cases, the parent controller has the topology 299 information on a region consisting of the domains controlled by its 300 child controllers. In other words, the parent controller has the 301 topology information on the domains controlled by its child 302 controllers and the topology/inter-connections among these domains. 303 This is called parent with domain topology. 305 The parent controller receives requests for creating end to end 306 tunnels from users or applications. For each request, the parent 307 controller is responsible for obtaining a path for the tunnel and 308 creating the tunnel along the path. 310 For parent without domain topology, the parent controller asks each 311 of its related child controllers to compute path segments from an 312 entry boundary node to exit boundary nodes in the domain it controls 313 or path segments from an exit boundary node in its domain to entry 314 boundary nodes of other adjacent domains just using the inter-domain 315 links attached to the exit boundary node. The details of the 316 segments are hidden from the parent, which sees each of the segments 317 as a link from a boundary node to another boundary node with a cost. 318 The parent controller builds a shortest path tree (SPT) using the 319 path segments computed as links to get the end to end path and then 320 creates the tunnel along the path by asking its related child 321 controllers. 323 The end to end path does not have any details from the parent's point 324 of view. It can be considered as a sequence of domains containing 325 the shortest path. Along this sequence of domains, the details of 326 the end to end path can be obtained. And then the tunnel along the 327 path with details can be created. 329 For parent with domain topology, the parent controller computes a 330 path for the tunnel using the topology information on the domains 331 controlled by its child controllers. And then it creates the tunnel 332 along the path computed through asking its related child controllers. 334 6. Extensions to PCEP 336 This section describes the extensions to PCEP for a Hierarchical SDN 337 Control System (HSCS). The extensions include the definition of a 338 new flag in the RP object, a global tunnel identifier (GTID), a path 339 identifier (PID), a list of path segments and an exception list in 340 the PCReq and PCRep message. 342 6.1. Capability Discovery 344 During a PCEP session establishment between two PCEP speakers (PCE or 345 PCC), each of them advertises its capabilities for HSCS through the 346 Open Message with the Open Object containing a new TLV to indicate 347 its capabilities for HSCS. This new TLV is called HSCS capability 348 TLV. It has the following format. 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type = TBD1 | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Capability Flags | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | (Optional Sub-TLVs) | 358 ~ ~ 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 The type of the TLV is TBD1. It has a length of 4 octets plus the 362 size of optional Sub-TLVs. The value of the TLV comprises a 363 capability flags field of 32 bits, which are numbered from the most 364 significant as bit zero. Each bit represents a capability. 366 o PC (Parent Controller - 1 bit): Bit 0 is used as PC flag. It is 367 set to 1 indicating a parent controller. 369 o CC (Child Controller - 1 bit): Bit 1 is used as PC flag. It is 370 set to 1 indicating a child controller. 372 o PS (Path Segments - 1 bit): Bit 2 is used as PS flag. It is set 373 to 1 indicating support for computing path segments for HSCS 375 o TS (Tunnel Segment - 1 bit): Bit 3 is used as TS flag. It is set 376 to 1 indicating support for creating tunnel segment for HSCS 378 o ET (End to end Tunnel - 1 bit): Bit 4 is used as ET flag. It is 379 set to 1 indicating support for creation and maintenance of end to 380 end LSP tunnels 382 6.2. New Messages for Hierarchical SDN Control System 384 This section describes the contents and semantics of the new 385 messages, and presents a few of different encodings for the messages. 387 There are a number of new messages for supporting HSCS. These new 388 messages can be encoded in a few of ways as follows: 390 o To use a new type at top level for each of the new messages. This 391 is called individual encoding. 393 o To use a new type at top level for each group of the new messages 394 and a option/operation/sub-type value for every message in the 395 group. This is called group encoding. 397 o To use/re-use existing messages and a value of options/operations 398 for each new message in an existing message. This is called 399 embedded encoding. 401 o To combine the ways above. This is called mixed encoding. 403 Various types of messages for supporting HSCS are listed below. Note 404 that many new messages may not be needed for some procedures/options. 405 For example, four messages Request and Reply for Removing Path 406 Segments and Request and Reply for Keeping Path Segments are not 407 needed if path segments computed are not stored/remembered by a child 408 controller. But in this case, the path segment in each domain along 409 the end to end path computed needs to be re-computed when a tunnel 410 along the path is set up. 412 Message for Controller Relation Discovery: It is a message exchanged 413 between a parent controller and a child controller for discovering 414 their parent-child relation. 416 Message for Connections and Accesses Advertisement: It is a message 417 that a child controller sends its parent controller to describe 418 the connections from the domain it controls to its adjacent 419 domains and the access points in the domain to be accessible 420 outside of the domain. 422 Request for Computing Path Segments: It is a message that a parent 423 controller sends a child controller to request the child 424 controller for computing path segments in the domain the child 425 controller controls. 427 Reply for Computing Path Segments: It is a message that a child 428 controller sends a parent controller to reply the parent 429 controller for a request message for computing path segments after 430 receiving the request message from the parent controller for 431 computing path segments and computing path segments as requested, 432 which normally contains the path segments computed. 434 Request for Removing Path Segments: It is a message that a parent 435 controller sends a child controller to request the child 436 controller for removing the path segments computed by the child 437 controller and stored in the child controller. 439 Reply for Removing Path Segments: It is a message that a child 440 controller sends a parent controller to reply the parent 441 controller for a request message for removing a set of path 442 segments after receiving the request message from the parent 443 controller for removing path segments and removing the path 444 segments as requested, which normally contains a status of 445 removing path segments. 447 Request for Keeping Path Segments: It is a message that a parent 448 controller sends a child controller to request the child 449 controller for keeping a set of path segments computed by the 450 child controller and stored in the child controller. 452 Reply for Keeping Path Segments: It is a message that a child 453 controller sends a parent controller to reply the parent 454 controller for a request message for keeping path segments after 455 receiving the request message from the parent controller for 456 keeping path segments and keeping the path segments as requested, 457 which normally contains a status of keeping path segments. 459 Request for Creating Tunnel Segment: It is a message that a parent 460 controller sends a child controller to request the child 461 controller for creating tunnel segments related to the domain the 462 child controller controls. 464 Reply for Creating Tunnel Segment: It is a message that a child 465 controller sends a parent controller to reply the parent 466 controller for a request message for creating tunnel segment after 467 receiving the request message from the parent controller for 468 creating tunnel segment and creating tunnel segment as requested, 469 which normally contains a status of creating tunnel segment and a 470 label and an interface. 472 Request for Removing Tunnel Segment: It is a message that a parent 473 controller sends a child controller to request the child 474 controller for removing the tunnel segment created by the child 475 controller. 477 Reply for Removing Tunnel Segment: It is a message that a child 478 controller sends a parent controller to reply the parent 479 controller for a request message for removing tunnel segment after 480 receiving the request message from the parent controller for 481 removing tunnel segment and removing the tunnel segment as 482 requested, which normally contains a status of removing tunnel 483 segment. 485 6.2.1. Contents of Messages 487 This section describes the contents in each of the messages and gives 488 the format of each of messages in individual encoding, which is the 489 same as in group encoding. Some of the objects in the messages are 490 defined in the following sections. 492 6.2.1.1. Message for Controller Relation Discovery 494 A message for controller relation discovery is exchanged between a 495 parent controller and a child controller for discovering their 496 parent-child relation. 498 A message for controller relation discovery (CRDis message for short) 499 sent from a local controller to a remote controller comprises: 501 o Local controller attributes 503 o Remote controller attributes after the local controller receives 504 the remote controller attributes from a remote end and determines 505 that the relation between the local controller and the remote 506 controller can be formed. 508 The format of the CRDis message is as follows: 510 ::= 511 512 513 [] 515 where CRP (Controller Request Parameters) object is defined in 516 section Objects and TLVs. 518 6.2.1.2. Message for Connections and Accesses Advertisement 520 After a child controller discovers its parent controller, it sends 521 its parent controller a message for connections and accesses 522 advertisement. 524 A message for connections and accesses advertisement (CAAdv message 525 for short) from a child controller comprises: 527 o Inter-domain links from the domain the child controller controls 528 to its adjacent domains. 530 o The addresses in the domain to be accessible to the outside of the 531 domain. 533 o Attributes of each of the boundary nodes of the domain. 535 The format of the CAAdv message is as follows: 537 ::= 538 539 540 [] 541 where: 542 ::= 543 [] 544 ::= 545 [] 547 6.2.1.3. Request for Computing Path Segments 549 After receiving a request for creating an end to end tunnel from 550 source A to destination Z for a given set of constraints, a parent 551 controller allocates a global tunnel identifier (GTID) for the end to 552 end tunnel crossing domains and a path identifier (PID) for an end to 553 end path to be computed for the tunnel. The parent controller sends 554 a request message to each of its related child controllers for 555 computing a set of path segments in the domain the child controller 556 controls in a special order. The parent controller builds a shortest 557 path tree (SPT) using these path segments and obtains a shortest path 558 from source A to destination Z that satisfies the constraints. 560 Note: The details of the path segments are hidden from the parent, 561 which sees each of the segments as a link from one (boundary) node to 562 another (boundary) node with a cost. The end to end path does not 563 have any details from the parent's point of view, which may be 564 considered as a domain path. 566 A request message for computing path segments (PSReq message for 567 short) from a parent controller to a child controller comprises: 569 o The address or identifier of the start-node (saying X) in the 570 domain controlled by the child controller. From this node, a 571 number of path segments are to be computed. 573 o The global tunnel identifier (GTID) and the path identifier (PID). 574 For the path of the tunnel, a number of path segments are to be 575 computed. 577 o An exception list containing the nodes that are on the SPT and in 578 the domain controlled by the child controller or its adjacent 579 domains. 581 o The constraints for the path such as bandwidth constraints and 582 color constraints. 584 o A destination node Z. If Z is in the domain controlled by the 585 child controller, the child controller computes a shortest path 586 segment satisfying the constraints from node X to node Z within 587 the domain. 589 o Options for computing path segments: 591 E: E set to 1 indicating computing a shortest path segment 592 satisfying the constraints from node X to each of the edge 593 nodes of the domain controlled by the child controller except 594 for the nodes in the exception list. E is set to 1 if there is 595 not any previous hop of node X in the domain. 597 After receiving the request message, the child controller computes a 598 shortest path segment satisfying the constraints from node X to each 599 of the edge nodes of the domain controlled by the child controller 600 except for the nodes in the exception list if E is 1. In addition, 601 it computes a shortest path segment satisfying the constraints from 602 node X to each of the edge nodes of the adjacent domains except for 603 the edge nodes in the exception list just using the inter-domain 604 links attached to node X if node X is an edge node of the domain and 605 an end point of an inter-domain link. 607 The format of the PSReq message is as follows: 609 ::= 610 [] 611 612 where: 613 ::=[] 614 ::= 615 616 [] 618 ::= 619 620 621 [] 622 [] [] [] 623 [] [[]] [] 624 [] 625 627 6.2.1.4. Reply for Computing Path Segments 629 After receiving a request message from a parent controller for 630 computing path segments, a child controller computes the path 631 segments as requested in the message and sends the parent controller 632 a reply message to reply the request message, which contains the path 633 segments computed. The details of the path segments are hidden from 634 the parent, which sees each of the path segments as a link with a 635 cost. 637 A reply message for computing path segments (PSRep message for short) 638 comprises: 640 o The global tunnel identifier (GTID) and the path identifier (PID). 641 For the path of the tunnel, the path segments are computed. 643 o The address or identifier of the start-node (saying X) in the 644 domain controlled by the child controller. From this node, the 645 path segments are computed. 647 o For each shortest path segment from node X to node Y computed, the 648 address or identifier of node Y and the cost of the shortest path 649 segment from node X to node Y. 651 The child controller stores the details about every shortest path 652 segment computed under the global tunnel identifier (GTID) and the 653 path identifier (PID) when it sends the reply message containing the 654 path segments to the parent controller. 656 The child controller may delete the path segments computed for the 657 global tunnel identifier (GTID) and the path identifier (PID) if it 658 does not receive any request for keeping them from the parent 659 controller for a given period of time. 661 The format of the PSRep message is as follows: 663 ::= 664 665 where: 666 ::= 667 668 [] 670 ::= 671 672 673 674 [ | ] 675 [] 677 6.2.1.5. Request for Removing Path Segments 679 After a shortest path satisfying a set of constraints from source A 680 to destination Z is computed, a parent controller may delete the path 681 segments computed and stored in the related child controllers, which 682 are not any part of the shortest path. A parent controller may send 683 a child controller a request message for removing the path segments 684 computed by the child controller and stored in the child controller. 686 1). A request message for removing path segments (RPSReq message for 687 short) comprises: 689 o The global tunnel identifier (GTID). 691 All the path segments stored under GTID in the child controller are 692 to be removed. 694 2). A request message for removing path segments comprises: 696 o The global tunnel identifier (GTID) and the path identifier (PID). 698 All the path segments stored under GTID and PID in the child 699 controller are to be removed. 701 3). A request message for removing path segments comprises: 703 o The global tunnel identifier (GTID) and the path identifier (PID) 705 o A list of start point (or node) addresses or identifiers. 707 All the path segments stored in the child controller under GTID and 708 PID and with a start point or node from the list of start point (or 709 node) addresses or identifiers are to be removed. 711 4). A request message for removing path segments comprises: 713 o The global tunnel identifier (GTID) and the path identifier (PID) 715 o A list of start point (or node) addresses or identifiers 717 o A list of pairs (start point, a list of end points), which 718 identifies the path segments from start point of each pair to each 719 of the end points in the list of the pairs. 721 In addition to the path segments as described in the previous 722 message, the path segments stored in the child controller under GTID 723 and PID and identified by the list of pairs are to be removed. 725 The format of the RPSReq message is as follows: 727 ::= 728 729 where: 730 :: = 731 732 [] 734 ::= 735 736 [] 737 [] 738 [] 740 ::= [] 742 ::= [] 743 ::= 745 ::= [] 747 6.2.1.6. Reply for Removing Path Segments 749 After removing the path segments as requested by a request message 750 for removing path segments from a parent controller, a child 751 controller sends the parent controller a reply message for removing 752 path segments. 754 A reply message for removing path segments (RPSRep message for short) 755 comprises: 757 o The global tunnel identifier (GTID) and the path identifier (PID) 759 o Status of the path segments removal: 761 Success: The path segments requested for removal are removed 762 successfully. 764 Fail: The path segments requested for removal can not be 765 removed. 767 o Error code and reasons for failure if the status is Fail. 769 The format of the RPSRep message is as follows: 771 ::= 772 773 where: 774 ::= 775 776 [] 778 ::= 779 780 [] 781 782 [] 784 6.2.1.7. Request for Keeping Path Segments 786 After a shortest path satisfying a set of constraints from source A 787 to destination Z is computed, a parent controller may send a request 788 message for keeping path segments to each of the related child 789 controllers to keep the path segments on the shortest path. 791 A request message for keeping path segments (KPSReq message for 792 short) comprises: 794 o The global tunnel identifier (GTID) and the path identifier (PID). 796 o A list of pairs (start point, end point), each of which identifies 797 the path segment from the start point of the pair to the end point 798 of the pair. 800 The child controller will keep the path segments given by the list of 801 pairs (start point, end point) stored under GTID and PID. It will 802 remove all the other path segments stored under GTID and PID. 804 The format of the KPSReq message is as follows: 806 ::= 807 808 where: 809 :: = 810 811 [] 813 ::= 814 815 816 818 ::= [] 819 ::= 821 6.2.1.8. Reply for Keeping Path Segments 823 After keeping path segments as requested by a request message for 824 keeping path segments from a parent controller, a child controller 825 sends the parent controller a reply message for keeping path 826 segments. 828 A reply message for keeping path segments (KPSRep message for short) 829 comprises: 831 o The global tunnel identifier (GTID) and the path identifier (PID). 833 o Status of the path segment retention: 835 Success: The path segments requested for retention are retained 836 successfully. 838 Fail: The path segments requested for retention can not be 839 retained. 841 o Error code and reasons for failure if the status is Fail. 843 The format of the KPSRep message is as follows: 845 ::= 846 847 where: 848 ::= 849 850 [] 852 ::= 853 854 855 856 [] 858 6.2.1.9. Request for Creating Tunnel Segment 860 After obtaining the end to end shortest point to point (P2P) path, a 861 parent controller creates a tunnel along the path crossing multiple 862 domains through sending a request message for creating tunnel segment 863 to each of the child controllers along the path in a reverse 864 direction to create a tunnel segment. 866 A request message for creating tunnel segment (CTSReq message for 867 short) comprises: 869 o The global tunnel identifier (GTID) and the path identifier (PID). 871 o A path segment from a start point to an end point for parent 872 without domain topology or a path segment details/ERO for parent 873 with domain topology. 875 o A label and an interface if the domain controlled by the child 876 control is not a destination domain. 878 For parent without domain topology, the child controller allocates 879 and reserves link bandwidth along the path segment identified by the 880 start point and end point, assigns labels along the path segment, and 881 writes cross connects on each of the nodes along the path segment. 883 For parent with domain topology, the child controller assigns labels 884 along the path segment ERO and writes cross connects on each of the 885 nodes along the path segment. The link bandwidth along the path 886 segment is allocated and reserved by the parent controller. 888 For the non destination domain, the child controller writes the cross 889 connect on the edge node to the downstream domain using the label and 890 the interface from the downstream domain in the message. 892 For the non source domain, the child controller will include a label 893 and an interface in a message to be sent to the parent controller. 894 The interface connects the edge node of the upstream domain along the 895 path. The label is allocated for the interface on the node that is 896 the next hop of the edge node. 898 The format of the CTSReq message is as follows: 900 ::= 901 902 where: 903 ::= 904 905 [] 907 ::= 908 909 910 911 [