idnits 2.17.1 draft-zhaoyl-pce-dre-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1-2' is mentioned on line 120, but not defined == Missing Reference: '3-4' is mentioned on line 122, but not defined == Missing Reference: 'RFC5440' is mentioned on line 565, but not defined == Missing Reference: 'RFC5376' is mentioned on line 565, but not defined == Unused Reference: 'Ref1' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'Ref2' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'Ref3' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'Ref4' is defined on line 593, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group YL. Zhao 3 Internet-Draft J. Zhang 4 Intended status: Informational BUPT 5 Expires: April 25, 2013 RQ. Jing 6 China Telecom Beijing Research 7 Institute 8 DJ. Wang 9 XH. Fu 10 ZTE Corporation 11 October 22, 2012 13 Protocol Extension Requirement for Cooperation between PCE and 14 Distributed Routing Controller in GMPLS Networks 15 draft-zhaoyl-pce-dre-05 17 Abstract 19 Path Computation Element (PCE) is proposed for path computation in 20 multi-layer and multi-domain networks where PCE can be implemented in 21 either centralized method or distributed method. In the former case, 22 PCE can serve tens or hundreds of nodes simultaneously, while in the 23 later case, each node is equipped with a PCE, which can be regarded 24 as a distributed routing controller (DRC) in GMPLS networks and each 25 one of those provides similar path computation capability. PCE and 26 DRC have different advantages in path computation respectively. PCE 27 is suitable for cross-layer and cross-domain path computation, 28 especially in multi-constraints environment. But distributed routing 29 controller is good at path computation in parallel ways and 30 distributed network control in local domain. A cooperative path 31 computation architecture named Dual Routing Engine (DRE) is necessary 32 to be used in the future networks, for it based on the ideas of the 33 cooperation of these two types of path computation engines and can 34 take the advantages of both centralized and distributed method by 35 which the PCE is implemented. The corresponding PCE communication 36 protocol extension and other protocol requirements for cooperation 37 between PCE and distributed routing controller are listed in this 38 document to recommend the standard interfaces between different 39 components in DRE architecture. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on April 25, 2013. 58 Copyright Notice 60 Copyright (c) 2012 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 77 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5 79 4. Cooperative Architecture based on PCE and Distributed 80 Routing Controller . . . . . . . . . . . . . . . . . . . . . . 6 81 4.1. DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.2. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 5. Different Application Scenarios . . . . . . . . . . . . . . . 9 84 5.1. Cross layers and cross domains . . . . . . . . . . . . . . 10 85 5.2. Independent coexistence . . . . . . . . . . . . . . . . . 10 86 5.3. Security backup . . . . . . . . . . . . . . . . . . . . . 10 87 5.4. Policy-enabled . . . . . . . . . . . . . . . . . . . . . . 10 88 5.5. Constraint-based . . . . . . . . . . . . . . . . . . . . . 11 89 5.6. Service-oriented . . . . . . . . . . . . . . . . . . . . . 11 90 5.7. Cooperation between network level and node level . . . . . 11 91 6. PCEP Extension Requirements . . . . . . . . . . . . . . . . . 12 92 6.1. PCEP extension requirements for the communication 93 between RES and PCE . . . . . . . . . . . . . . . . . . . 12 94 6.2. PCEP extension requirement for the communication 95 between RES and DRC . . . . . . . . . . . . . . . . . . . 12 96 7. Other Protocol Extension Requirements . . . . . . . . . . . . 13 97 7.1. OSPF-TE extension requirement for the cooperative 98 architecture . . . . . . . . . . . . . . . . . . . . . . . 13 99 7.2. RSVP-TE extension requirement for the cooperative 100 architecture . . . . . . . . . . . . . . . . . . . . . . . 13 101 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 109 1. Introduction 111 Path Computation Element (PCE) is proposed to complete the 112 constraint-based shortest path computation in Multi-protocol Label 113 Switching (MPLS) and Generalized MPLS (GMPLS) multi-layer and multi- 114 domain networks [RFC4665]. And a series of Request for Comments 115 (RFCs) related to PCE technology, such as requirements for PCE 116 discovery, PCE Communication Protocol (PCEP), a backward recursive 117 PCE-based computation procedure (BRPC) and so on, have been 118 standardized. Studies have been proving that PCE is suitable for 119 cross-layer and cross-domain design of networks, capable of end-to- 120 end path computation under multiple constraints [1-2] and could be 121 potentially applied to resource assignment and routing optimization 122 [3-4]. PCE can be implemented either in centralized method or 123 distributed method. In the former case, PCE can serve tens or 124 hundreds of nodes simultaneously. while in the later case, each node 125 is equipped with a PCE, which can be regarded as a distributed 126 routing controller (DRC) in GMPLS networks and each one of them 127 provides similar path computation capability. DRC in GMPLS/ASON 128 control plane is good at the path computation in parallel ways and 129 distributed network control in local domain. On the other hand, DRC 130 can also be used in the management and configuration of resource in 131 internal node. Becaues of that the huge bandwidth requirement is 132 emerging, links with the transmission capacity of Tbit/s and 133 switching at Pbit/s are necessary for next generation optical 134 networks. According to the level of current photonics technology 135 level, the node's architecture should to be very complicated with 136 large power consumption. Therefore, how to configure the switching 137 architecture in the node will be a very important issue for the 138 entire network performance. On the other side, of course, PCE and 139 DRC has corresponding disadvantages respectively. 141 In order to optimize the performance of optical networks under 142 different application scenarios, PCE and distributed routing 143 controller are needed to cooperate with each other. A cooperative 144 path computation architecture named Dual Routing Engine (DRE) is 145 proposed, which includes two types of path computation engines, i.e. 146 PCE and distributed routing controller, and can combine advantages of 147 both of them. In this document, several different application 148 scenarios are described. And PCE communication protocol extension 149 and other protocol extension requirements for cooperation between PCE 150 and distributed routing controller are also listed here. 152 1.1. Conventions Used in This Document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Terminologies 160 LSR: Label Switching Router. 162 LSP: Label Switched Path. 164 PCC: Path Computation Client. Any client application requesting a 165 path computation to be performed by the Path Computation Element. 167 PCE (Path Computation Element): an entity (component, application or 168 network node) that is capable of computing a network path or route 169 based on a network graph and applying computational constraints. 171 PCEP: PCE Communication Protocols, the communication protocol between 172 PCC and PCE. 174 DRC: Distributed Routing Controller, the module that can complete 175 path computation in local domain or in internal node. 177 DRE: Dual Routing Engine, including PCE and DRC. 179 TED: Traffic Engineering Database. 181 RID: Resource Information Databases. 183 3. General Assumptions 185 PCE and distributed routing controller are two path computation 186 engines which have been standardized by IETF working group. They can 187 both complete the path computation in GMPLS networks. In order to 188 show how the cooperative architecture based on PCE and distributed 189 routing controller works, some assumptions as follows should be made 190 before. 192 o Each GMPLS-based control node is equipped with a distributed 193 routing controller which can complete the path computation in 194 local domain and even the path computation and resource 195 configuration in the internal node, and each domain is equipped 196 with no less than one PCE which can not only complete the intra- 197 domain path computation, but also complete the inter-domain path 198 computation. 200 o The topology and TE information are updated as soon as any change 201 occurs in the network, and the information kept at PCE and 202 distributed routing controller are synchronized by OSPF-TE. 204 o PCE and distributed routing controller can be selected arbitrary 205 according to the local routing strategy. 207 o Constraints and strategies can be considered by PCE during the 208 process of the intra-domain path computation and the inter-domain 209 path computation. 211 o An end-to-end path which crosses domains or crosses layers can be 212 completed by several PCEs or several DRCs or several PCEs and 213 DRCs. For example, the section of an end-to-end path in one 214 domain may be computed by PCE, but the other section of this path 215 in another domain may be computed by DRC. 217 4. Cooperative Architecture based on PCE and Distributed Routing 218 Controller 220 As shown in Fig. 1, cooperative architecture consists of Path 221 Computation Element (PCE) and distributed routing controller (DRC). 222 Both of them maintain Traffic Engineering Databases (TEDs) to keep 223 network topology and other status information within the scope of 224 their respective functions. There is a function module named Routing 225 Engine Selector (RES) at each control node, which is responsible for 226 managing the switchover to process between PCE and DRC,and choosing 227 the right one when a LSP setup request is arriving. RES,as well as 228 PCC when cooperating with PCE and DRC,can be implemented in 229 Connection Controller (CC) module of GMPLS-based control plane. 231 ------- ------- 232 | PCE |-------------------------| PCE | 233 ------- ------- 234 /|\ /|\ 235 / | \ / | \ 236 / | \ / | \ 237 -----------/---|---\---------- ----------/---|---\---------- 238 | / ------- \ | | / ------ \ | 239 | / | RES | \ | | / | RES | \ | 240 | / ---|--- \ | | / ---|--- \ | 241 | / /---|---\ \ | | / /---|---\ \ | 242 | / /| DRC |\ \ | | / /| DRC |\ \ | 243 | / / ------- \ \ | | / / ------- \ \ | 244 | / / \ \ | | / / \ \ | 245 | / / \ \ | | / / \ \ | 246 | / / \ \ | | / / \ \ | 247 | ------- ------- | | ------- ------- | 248 | | RES |-----------| RES |+---+| RES |-----------| RES || 249 | ---|--- ---|--- | | ---|--- ---|--- | 250 | ---|--- ---|--- | | ---|--- ---|--- | 251 | | DRC | | DRC || || DRC | | DRC || 252 | ------- ------- | | ------- ------- | 253 | domain A | | domain B | 254 ------------------------------ ----------------------------- 256 Fig.1 Cooperative architecture in multi-layer and multi-domain 257 networks 259 4.1. DRC 261 DRC offers general routing functions based on GMPLS/ASON control 262 plane which includeds linking state adverting, topology updating and 263 path computation. A typical DRC contains two essential modules that 264 are topology analysis module and path computation module. The former 265 floods network topology and resource information to synchronize TED 266 maintained on each node. The latter responds to a routing request 267 from Connection Controller (CC) and finds the optimized path solution 268 and returns it to CC. Besides these general routing functions, DRC 269 can also complete the resource allocation and configuration, which 270 refer to internal resource allocation, ports interconnection, and 271 switch fabric configuration in the internal node. This function is 272 getting more and more important as the structure of the internal node 273 is getting more and more complex. Detail of DRC's operation is out 274 of this document's scope. 276 4.2. PCE 278 PCE has particular advantage of centralized path computation in 279 multi-layer and multi-domain networks, especially in multi- 280 constraints environment. There is a Client/Server model between RES 281 and PCE. When RES sends a TE-LSP computation request to PCE, PCE 282 would perform path computation and returns the results back to RES. 284 As shown in Fig.2, RES chooses the best PCE based on a certain policy 285 first. It sends performance query requests to multiple related PCEs, 286 each of which evaluates itself individually and then feeds back to 287 the RES. RES gathers performance status information from PCEs and 288 decides which PCE is feasible. Thus a combination of RES and PCE is 289 founded. Secondly PCE deals with the path computation requests 290 coming from RES by using the message parser. A request will be 291 delivered towards path computation module if it carries path 292 information after the message parsing , otherwise , if it carries 293 policy information from RES, it should be firstlly interpreted by 294 policy parser along with local policy settings and then loaded into 295 path computation module. Finally path computation module implements 296 multi-constraint routing on the basis of the path information, policy 297 information and TE information. If path computation is successful, 298 the details of the whole route will be returned to RES. If it only 299 gets an incomplete route, a new application for path computation 300 request will be sent to the next hop RES. Then another PCE or DRC 301 will be selected to complement the incomplete route. 303 --------------------- 304 | RES |__________ 305 | in Domain A | | 306 --------------------- | 307 | | 308 1.Sending the path computation | 309 request to the selected PCE | 310 | | ____________________ 311 __________________________________ | |4. Whether Response | 312 | | | | to the RES in | 313 | ____________________ | | | domain A or to the | 314 | | | | | | next hop RES | 315 | | The Message Parser | | | | is depending on the| 316 | | | | | /| output of path | 317 | -------------------- | | / | computation module | 318 | | | | / ------------------- 319 | | | | / 320 | 2.Delivering the message | | / 321 | to policy parser or directively | | / 322 | to path computaton module | | / ----------------- 323 | according to the information |----+-----| RES | 324 | carried. | | in Domain B | 325 | | | | ----------------- 326 | ----------- ----------- | 327 | | | | | | 328 | | The | | Path | | 329 | | Policy | |Computation| | 330 | | Parser | | Module | | 331 | | | | | | 332 | ----------- ----------- | 333 | | | | 334 | 3.Passing the request to path | 335 | computation module after | 336 | policy parsing | 337 | | 338 | The Selected PCE | 339 |__________________________________| 341 Fig.2 The path computation request handlling procedure of PCE 343 5. Different Application Scenarios 345 Cooperation between PCE and DRC is one of the key issues in the 346 cooperative architecture, it can help to achieve fast and exact 347 routing. This section will list several typical application 348 scenarios of cooperation between PCE and DRC. 350 5.1. Cross layers and cross domains 352 It is necessary for PCE to collaborate with DRC when the requirements 353 for path computation occur in multi-layer and multi-domain GMPLS 354 networks. PCE could be shared among several domains or layers and 355 make the best use of the inter-domain and inter-layer network 356 resources. Obviously it is more suitable for inter-domain or inter- 357 layer path computation. In contrast to PCE, DRC usually runs in 358 fulfill intra-domain or intra-layer routing case. 360 5.2. Independent coexistence 362 Both PCE and DRC are working independently under this scenario. 363 While one customer applies a TE-LSP computation, the respective RES/ 364 RESs could select PCE or DRC arbitrarily. Of course each time only 365 one path computation engine can be selected. If a lot of 366 applications for path computation arrive simultaneously, the burst 367 computing load may also be balanced between them according to the 368 implementation of RES. The changing of topology and resource status 369 information should be maintained in PCE and DRC in time although it 370 is difficult to manage the information synchronization on both sides. 372 5.3. Security backup 374 The cooperation mechanisms among different engines make it possible 375 that PCE and DRC backup each other to enhance the routing security 376 and reliability, since they both satisfy the demands of path 377 computation from customers. When the working engine (e.g. PCE) 378 fails, computation tasks could be switched to another reserved engine 379 (e.g. DRC) as soon as possible. In such a case both PCE and DRC 380 should maintain the accordant network topology and resource status 381 information. 383 5.4. Policy-enabled 385 In order to compute the optimal path in consideration of traffic 386 engineering, different policies are implemented, which means there 387 are series of rules and actions from management plane or control 388 plane. PCE is obviously more suitable for policy-enabled path 389 computation framework than DRC. Tab.1 lists some typical policy 390 application instances that may be exerted to the cooperative path 391 computation architecture. New scenarios could occur as well as the 392 effective combinations of the above scenarios in the real networks. 394 +------------------------+------------------------------------------+ 395 | Policy application | Description | 396 | scenarios | | 397 +------------------------+------------------------------------------+ 398 | Policy configured | To centrally administer configured paths | 399 | paths | | 400 | Provider selection | To be applied in multi-provider | 401 | policy | topologies | 402 | Policy based | To provide constraints in a path | 403 | constraints | computation request | 404 | Advanced load | To balance the traffic load for the | 405 | balancing | whole network | 406 +------------------------+------------------------------------------+ 408 Policy-enabled path computation instances 410 Table 1 412 5.5. Constraint-based 414 Constraint-based path computation is a basic function especially for 415 TE-LSP establishment. Available bandwidth, diversity, Shared Risk 416 Link Group (SRLG), optical impairments, wavelength continuity and 417 other constraints are likely to be considered. However, it is 418 difficult to compute an optimal path with these constraints under the 419 condition of the general GMPLS/ASON routing architecture. The 420 centralized operation manner makes PCE easy to fulfill constraint- 421 based path computation. 423 5.6. Service-oriented 425 PCEs can collaborate to finish constraint-based path computation 426 without sharing TE information with each other, which are 427 particularly useful when end-to-end constraints have to be taken into 428 account because of protection and the diversity of path. PCEs should 429 play an important role in service-oriented applications such as Layer 430 1 Virtual Private Network (L1 VPN), Bandwidth on Demand (BoD) and so 431 on. Based on GMPLS/ASON architecture, the advantages of PCE and 432 service plane can be combined to implement the framework of service- 433 oriented application. 435 5.7. Cooperation between network level and node level 437 In this application scenario, PCE maintains Traffic Engineering 438 Databases (TEDs) to keep network topology and DRC maintains Resource 439 Information Databases (RIDs) to keep node internal topology and 440 resource status. Both of them maintain the status information within 441 the scope of their functions. Routing Engine Selector (RES) is 442 responsible for managing the switchover to process between PCE and 443 DRC and choosing the right one when a LSP setup request arrives. 445 The interconnection between different nodes is becoming a general 446 routing problem, which can be solved by PCE framework effectively, 447 especially in multi-domain, multi-layer and multi-constraints 448 scenarios. The interconnection within the node is the problem of 449 resource allocation and configuration, which refers to internal 450 resource allocation, ports interconnection, and switch fabric 451 configuration. Through the cooperation of PCE and DRC, we can make 452 resource configuration more effectively and improve the performance 453 of the entire optical networks. 455 6. PCEP Extension Requirements 457 As an extension of PCC, RES can not only complete the communication 458 between PCE and DRC, but also complete the cooperation between PCE 459 and DRC. There are some requirements of PCEP extension for the 460 cooperative path computation architecture and the procedure. 462 6.1. PCEP extension requirements for the communication between RES and 463 PCE 465 PCEP is the communication protocol between RES and PCE. However, 466 there are some extension requirements of PCEP in the cooperative path 467 computation architecture. 469 Firstly, an identification which appoints different application 470 scenarios should be added to the path computation request 471 messages(PCReq) from RES to PCE, and the corresponding data structure 472 should be defined according to different identifications. For 473 example, in the policy-enabled scenario, a policy object is necessary 474 to be defined in the message sent from RES to PCE, and PCE should be 475 able to parse the different policies and conduct the corresponding 476 operations during the procedure of path computation. 478 Secondly, in the reply message from PCE to RES, some indication 479 information should be contained besides the routes information, such 480 as the inter-domain loose path or the intra-domain path, the complete 481 end-to-end path or section path, some failure information and path 482 computation engine switchover requests. 484 6.2. PCEP extension requirement for the communication between RES and 485 DRC 487 DRC can complete the path computation in local domain in the 488 distributed method, which is usually implemented in the OSPF-TE 489 module of GMPLS-based control plane. After the path computation, DRC 490 returns the computation results to RES (CC) including the detailed 491 routes or some failure or indication information. 493 As another important application, DRC can complete the path 494 computation, resource management and configuration in the internal 495 node even the node structure is getting more and more complex. In 496 this application scenario, DRC has the function of routing and 497 resource allocation. 499 In all the application scenarios, DRC has all the analogous functions 500 with PCE and some different extension functions listed above. So 501 there is a requirement for application scenarios identification in 502 the communication message between RES and DRC. The communication 503 protocol between RES and DRC is necessary to be standardized because 504 of that the function of control node is getting more and more 505 complex. Because RES and DRC are implemented in the same control 506 node and DRC has similar functions with PCE, a simplified PCEP can be 507 used as the communication protocol between RES and DRC, which can 508 include the path computation request, identification and reply 509 messages only. 511 7. Other Protocol Extension Requirements 513 7.1. OSPF-TE extension requirement for the cooperative architecture 515 In the cooperative path computation architecture, the topology and TE 516 information should be kept and synchronized at each control node and 517 PCE in local domain, and should also be updated as soon as any change 518 occurs. Meanwhile, all the inter-domain links and TE information 519 should be kept and synchronized at each PCE. So there is an 520 extension requirement for OSPF-TE to guarantee the information at 521 each node synchronized in time. 523 Besides the normal topology and TE information, some other 524 constraints information may be necessary to be contained in the 525 OSPF-TE protocol flooding in the entire networks, such as the 526 physical impairment information. Then there is an extension 527 requirement for the OSPF-TE protocol to enable the synchronization of 528 all the constraint information at each node, which is of great value 529 for the path computation and resource allocation. 531 7.2. RSVP-TE extension requirement for the cooperative architecture 533 In different cooperation modes between PCE and DRC, an end-to-end 534 path may be computed by several PCE and DRC, and then be setup by 535 signaling from the source node to the destination node. However, 536 sometimes an end-to-end path which crosses domains or layers may be 537 computed and setup section by section. Signaling should be triggered 538 when a section path is gained. The current RSVP-TE protocol is 539 necessary to be extended to support this application scenario. 541 Furthermore, as the scheme of path and resource allocation in the 542 internal node is gained, the resource reservation and action of 543 switches are need to be conducted by some protocol as the control 544 node is getting more and more complex. RSVP-TE is the optimal option 545 for this need, and to be extended. 547 8. Discussions 549 According to the development of GMPLS networks, the cooperative 550 architecture can be introduced in two steps. First, PCE and DRC can 551 cooperate with each other to complete the path computation of the 552 entire networks at network level. Second, PCE and DRC can cooperate 553 with each other to complete the path computation at network level and 554 resource computation and allocation at node level with the scale of 555 network increasing and the structure of node getting more complex. 557 9. Security Considerations 559 The cooperation between PCE and DRC can enhance the security of 560 networks because they can backup each other. However, because the 561 information is kept at both PCE and DRC, especially in the condition 562 of the exchanging of information across domain boundaries is 563 necessary in the multi-domain operations, there are some security and 564 confidentiality risks, which can be minimized through the inheritance 565 of the security requirement defined [RFC5440] and [RFC5376]. 567 10. Acknowledgments 569 The RFC text was produced using Marshall Rose's xml2rfc tool. 571 11. References 573 11.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 576 Requirement Levels", RFC 2119, March 1997. 578 [RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 579 Element (PCE)-Based Architecture", RFC 4655, August 2006. 581 11.2. Informative References 583 [Ref1] Nishioka, Itaru., "End-to-End path routing with PCEs in 584 multi-domain GMPLS networks", July 2008. 586 [Ref2] Jabbari, Bijan., "On Constraints for Path Computation in 587 Multi-Layer Switched Networks", August 2007. 589 [Ref3] Giorgetti, A. and F. Paolucci, "Routing and Wavelength 590 Assignment in PCE-based Wavelength Switched Optical 591 Networks", September 2008. 593 [Ref4] Hayashi, Michiaki., "Advance Reservation-Based Network 594 Resource Manger for Optical Networks", February 2008. 596 Authors' Addresses 598 Yongli Zhao 599 BUPT 600 No.10,Xitucheng Road,Haidian District 601 Beijing 100876 602 P.R.China 604 Phone: +8613811761857 605 Email: yonglizhao@bupt.edu.cn 606 URI: http://www.bupt.edu.cn/ 608 Jie Zhang 609 BUPT 610 No.10,Xitucheng Road,Haidian District 611 Beijing 100876 612 P.R.China 614 Phone: +8613911060930 615 Email: lgr24@bupt.edu.cn 616 URI: http://www.bupt.edu.cn/ 617 Ruiquan Jing 618 China Telecom Beijing Research Institute 619 118 Xizhimenwai Avenue 620 Beijing 100035 621 P.R.China 623 Phone: +86-10-58552000 624 Email: jingrq@ctbri.com.cn 625 URI: http://www.ctbri.com.cn/ 627 Dajiang Wang 628 ZTE Corporation 629 No.16,Huayuan Road,Haidian District 630 Beijing 100191 631 P.R.China 633 Phone: +8613811795408 634 Email: wang.dajiang@zte.com.cn 635 URI: http://www.zte.com.cn/ 637 Xihua Fu 638 ZTE Corporation 639 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 640 Xi'an 710065 641 P.R.China 643 Phone: +8613798412242 644 Email: fu.xihua@zte.com.cn 645 URI: http://www.zte.com.cn/