idnits 2.17.1 draft-wdj-pce-for-inter-layer-path-computation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5296 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: 'RFC4655' is mentioned on line 102, but not defined == Missing Reference: 'PCE-INTER-LAYER-FRWK' is mentioned on line 372, but not defined == Missing Reference: 'RFC3031' is mentioned on line 103, but not defined == Missing Reference: 'RFC3945' is mentioned on line 104, but not defined == Missing Reference: 'RFC5088' is mentioned on line 416, but not defined == Missing Reference: 'RFC5212' is mentioned on line 107, but not defined == Missing Reference: 'RFC5089' is mentioned on line 416, but not defined == Missing Reference: 'RFC5440' is mentioned on line 554, but not defined == Unused Reference: 'ITUT-G709' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC4328' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC5150' is defined on line 618, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Wang 3 Internet-Draft Z. Wang 4 Intended status: Standards Track X. Fu 5 Expires: April 29, 2010 ZTE Corporation 6 October 26, 2009 8 Path Computation Element (PCE) Extensions for Inter-Layer Path 9 Computation 10 draft-wdj-pce-for-inter-layer-path-computation-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document mainly describes the extensions of multiple PCE inter- 49 layer path computation with inter-PCE communication. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. Scenario Statement and Requirements Overview . . . . . . . . . 3 56 2.1. Scenario Statement . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Requirements Overview . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Inter-Layer Optimal Path Computation Procedure . . . . . . . . 6 60 4.1. Confirmation of The Topology Connectivity . . . . . . . . 6 61 4.2. Inter-layer TE Links . . . . . . . . . . . . . . . . . . . 6 62 4.3. Confirmation of Inter-Layer Border LSR . . . . . . . . . . 7 63 4.4. Discovery of Inter-layer PCEs . . . . . . . . . . . . . . 8 64 4.5. Communication of Inter-layer PCEs . . . . . . . . . . . . 9 65 4.6. Optimal Inter-layer Path Computation by BRPC . . . . . . . 9 66 5. Routing Protocol Extensions for Inter-Layer PCE Discovery . . 9 67 5.1. Extension of PATH-SCOPE Sub-TLV . . . . . . . . . . . . . 10 68 5.2. PCE-LAYER Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 69 5.3. NEIG-PCE-LAYER Sub-TLV . . . . . . . . . . . . . . . . . . 13 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 72 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 The Path Computation Element (PCE) defined in [RFC4655] is an entity 78 that is capable of computing a network path or route based on a 79 network graph and applying computational constraints. 81 A network may comprise multiple layers. In [PCE-INTER-LAYER-FRWK], 82 there are three inter-layer path computation models defined to 83 perform PCE-based inter-layer path computation, namely Single PCE 84 Computation, Multiple PCE Computation with inter-PCE communication, 85 and Multiple PCE Computation without inter-PCE communication. Mainly 86 by scalability, automation and confidentiality considerations, 87 multiple PCE computation instead of single PCE computation is more 88 concerned. In this mode, a PCE has the topology visibility of one or 89 more layers (but not all layers, in this document, only one layer 90 being considered). 92 This document mainly describes the extensions of multiple PCE inter- 93 layer path computation with inter-PCE communication. 95 1.1. Conventions Used in This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 This document uses terminology from the PCE-based path computation 102 architecture [RFC4655] and also common terminology from Multi 103 Protocol Label Switching (MPLS) [RFC3031], Generalized MPLS (GMPLS) 104 [RFC3945], Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic 105 Engineering [PCE-INTER-LAYER-FRWK], OSPF Protocol Extensions for Path 106 Computation Element (PCE) Discovery [RFC5088], and Multi-Layer 107 Networks [RFC5212]. 109 2. Scenario Statement and Requirements Overview 111 2.1. Scenario Statement 113 In the model of multiple PCE inter-layer path computation, there is 114 at least one PCE in each layer. Each PCE has the topology visibility 115 restricted to its own layer. When an ingress LSR tries to set up an 116 end-to-end LSP to an egress LSR is set up in the higher-layer 117 network, as a PCC it will select a PCE located in its layer and send 118 a path computation request to the PCE. At this time, the PCE will be 119 confronted with such secenarios: 121 o As absence of essential TE link in the higher-layer network, the 122 network topology of the whole layer is divided into at least two 123 independent partitions. 125 o The border LSRs of each partition MAY be produced and a lower- 126 layer network exists between the pairs of border LSRs belonging to 127 two different partitions. 129 o The border LSRs MAY originate TE links connected to the lower- 130 layer network. 132 o The ingress LSR and the egress LSR MAY be located in different 133 partitions. 135 o When receiving a path computation request from the ingress LSR in 136 the higher-layer, this higher-layer PCE will select one border LSR 137 of the partition that the ingress LSR is located in and another 138 border LSR of the partition that the egress LSR is located in 139 respectively. This pair of LSRs will be taken as the head-end and 140 the tail-end nodes which are included in the inter-layer path 141 computation request sent to the lower-layer PCE. As the number of 142 the border LSRs in each partition is usually more than one, 143 higher-layer PCE will produce such pairs of border LSRs. 145 o As there can be at least one PCE in each layer,,the higher-layer 146 PCE SHOULD select one from the lower-layer PCEs according to the 147 information advertised by them and send a inter-layer path 148 computation request about the pairs of border LSRs to the selected 149 lower-layer PCE. 151 o In order to allow for effective PCE selection by PCCs, 152 furthermore, a PCC needs to know the layer that the PCE is located 153 in and the neighbor layer toward which the PCE can compute paths. 154 Here, the neighbor layer is usually lower than its own layer 155 according to multi-layer technology. 157 2.2. Requirements Overview 159 The multiple PCE inter-layer path computation mechanism MUST satisfy 160 the following requirements. 162 For the higher-layer PCE, it MUST identify connectivity of its own 163 layer topology by some algorithm. When the topology is no-connected, 164 if the head-end node and the tail-end node lie in two independent 165 partitions respectively, inter-layer path solution will have to be 166 considered. 168 As there is no direct TE link between partitions in non-connected 169 topology, the higher-layer PCE SHOULD designate border LSRs to the 170 lower-layer. Generally in one partition, obtainment of border LSR 171 lies in whether the LSR has a TE link connected to the lower-layer 172 network. If so, this LSR will be considered as a border LSR of the 173 partition. An independent partition SHOULD usually have at least one 174 border LSR. Similarly, the lower-layer PCE should also designate 175 border LSRs which should have a TE link connected to the higher-layer 176 network. 178 In each layer, PCE discovery information should include the layer 179 into which the PCE has visibility. 181 In each layer, PCE discovery information should include the neighbor 182 layer to which the PCE can send path computation request. In this 183 case, the local-layer is usually higher, and the neighbor layer is 184 lower. Since a NE receives discovery information of PCEs in the 185 local-layer, as a PCC, it should know about which PCEs are in the 186 same layer and which neighbor layer the PCEs can communicate with. 187 When a path computation request is originated from this NE, firstly 188 it should estimate the neighbor layer that the path passes through if 189 possible. 191 A PCE discovery mechanism MUST allow that PCEs in different layers 192 know about their discovery information each other, especially their 193 local layer, neighbor layer, and the computation capability. Such 194 information MAY be got by flooding mechanism of some routing 195 protocol. So PCE discovery mechanism permits PCEs belonging to 196 different layers get discovery information each other, especially the 197 information about local layer, adjacent layer, and PCE's computing 198 capability etc. Some of PCEs in different layers and with inter- 199 layer computing capability can be chosen and consist of a PCE 200 topology. Then in this PCE topology the PCEs' discovery information 201 can be gotten by starting an instance of some routing protocol with 202 flooding mechanism. According to the PCEs' discovery information, as 203 a PCC, a higher-layer PCE may choose a suitable one from many 204 adjacent lower-layer PCEs with inter-layer path computing capability 205 in the PCE topology to compute an inter-layer path. 207 3. Terminology 209 BRPC: Backward-Recursive PCE-Based Computation. 211 FSC: Fiber Switching Capability. 213 GMPLS: Generalized Multi-Protocol Label Switching. 215 LSC: Lambda Switching Capability. 217 L2SC: Layer2 Switching Capability. 219 LSP: Label Switched Path. 221 LSR: Label Switching Router. 223 MPLS: Multi-Protocol Label Switching. 225 PCC: Path Computation Client. 227 PCE: Path Computation Element. 229 PCReq: Path Computation Request. 231 PCRsp: Path Computation Respond. 233 PSC: Packet Switching Capability. 235 TDM: Time Division Multiplex. 237 TE: Traffic Engineering. 239 4. Inter-Layer Optimal Path Computation Procedure 241 4.1. Confirmation of The Topology Connectivity 243 The PCE in the local layer will compute the optimal path from the 244 ingress LSR to the egress LSR according to the information included 245 by the PCReq message belonging to PCEP. 247 Generally, only when the network topology of the whole layer is 248 divided into two or more partitions resulting from lack of TE links, 249 and the ingress LSR and the egress LSR are respectively located in 250 the different partitions, inter-layer path computation will be 251 considered by the PCE. 253 4.2. Inter-layer TE Links 255 Whether it is higher-layer or lower-layer PCE needs to get the TE 256 attribute of inter-layer TE links during the process of inter-layer 257 TE LSP computation. 259 Between the local port belonging to one inter-layer border LSR in the 260 side of higher-layer and the remote port belonging to the other one 261 in the side of lower-layer, one-way inter-layer TE links usually 262 appear in pairs. Among them, one is form the local port to the 263 remote port, and the other is in the opposite direction. In other 264 words, both of them consist of a bidirectional TE link. The former 265 is originated from an inter-layer border LSR in the higher-layer, and 266 it belongs to the scope of higher-layer topology into which only the 267 higher-layer PCEs have visibility. Similarly the latter is 268 originated from an inter-layer border LSR in the lower-layer, and it 269 belongs to the scope of lower-layer topology into which only the 270 lower-layer PCEs have visibility. 272 By an inter-layer TE link, an adaptation is completed from one type 273 of switch capability to another one(e.g., electrical switching to 274 optical switching, etc.). 276 4.3. Confirmation of Inter-Layer Border LSR 278 Inter-layer border LSRs are respectively located on the boundary of 279 the high-layer and lower-layer networks. Each of them has at least 280 one unidirectional TE link connected to the other inter-layer border 281 LSR in the adjacent layer. 283 Before a higher-layer PCE begins to compute an inter-layer path, it 284 SHOULD collect the information about all of inter-layer border LSRs 285 in its local layer. And it MAY combine the inter-layer border LSRs 286 belonging to the partition in which the ingress LSR is located with 287 the inter-layer border LSRs belonging to the partition in which the 288 egress LSR is located into many pairs of inter-layer border LSRs. By 289 this combination, many pairs of inter-layer border LSRs are formed 290 and as end LSRs provided for the lower-layer PCE to compute end-to- 291 end paths across the lower-layer network. That is, a PCReq message 292 which is sent to lower-layer PCE and is used to do inter-layer path 293 computation will include many pairs of ingress and egress LSRs. 295 ----- ----- ----- ----- ----- 296 | LSR |...| LSR | | PCE | | LSR |...| LSR | 297 | H1 | | H2 | | Hi | | H'1 | | H'2 | 298 /----- . -----\ --+-- /----- -----\ 299 / . \ | / \ 300 -----/ ----- ... \----- | -----/ ----- ... \----- 301 | LSR | |LSP | | LSR | | | LSR | |LSP | | LSR | 302 | H6 | |Head | | H3 | | | H'6 | |End | | H'3 | 303 -----\ ----- . /----- | -----\ .----- . /----- 304 \ . / | \ . . / 305 \----- -----/ | \----- -----/ 306 | LSR |...| LSR | --+-- | LSR |...| LSR | 307 | H5 | | H4 | | PCE | | H'5 | | H'4 | 308 -----\ -----\ | Lo | /----- /----- 309 \ . . \ ----- / . ./ 310 \ . . \ / . ./ 311 \ . . \----- -----/ . ./ 312 \ | LSR |...| LSR | / 313 \ | L1 | | L2 | / 314 \ /----- -----\ / 315 \ / \ / 316 -----/ \----- 317 | LSR | | LSR | 318 | L6 | | L3 | 319 -----\ /----- 320 \ / 321 \----- -----/ 322 | LSR |...| LSR | 323 | L5 | | L4 | 324 ----- ----- 326 4.4. Discovery of Inter-layer PCEs 328 From PCEP's point of view, inter-layer PCE communication is also a 329 kind of communication between PCC and PCE. The requesting entity 330 will be looked as a PCC, and the requested entity will be looked as a 331 PCE. 333 So PCE discovery mechanism permits PCEs belonging to different layers 334 get discovery information each other, especially the information 335 about local layer, adjacent layer, and PCE's computing capability 336 etc. Some of PCEs in different layers and with inter-layer computing 337 capability can be chosen and consist of a PCE topology. Then in this 338 PCE topology the PCEs' discovery information can be gotten by 339 starting an instance of some routing protocol with flooding 340 mechanism. Only in this PCE topology can this routing protocol 341 instance run. Its flooding contents are limited to the discovery 342 information of those PCEs that are added to the PCE topology and can 343 not be beyond the scope of the PCE topology. According to the PCEs' 344 discovery information, as a PCC, a higher-layer PCE may choose a 345 suitable one from many adjacent lower-layer PCEs with inter-layer 346 path computing capability in the PCE topology to compute an inter- 347 layer path. 349 4.5. Communication of Inter-layer PCEs 351 If the higher-layer PCE decides to start inter-layer path 352 computation, it will confirm as many pairs of end inter-layer LSRs as 353 possible firstly. Then as a PCC, the higher-layer PCE will choose a 354 suitable lower layer PCE according to the discovery information 355 flooded by the lower layer PCEs and send a request to it for 356 computing paths of the pairs of end inter-layer LSRs. 358 Since a inter-layer TE link includes the information about inter- 359 layer LSRs on the both ends of it, when the lower-layer PCE receives 360 the PCReq message, it can find the correspondent inter-layer TE links 361 in its local-layer topology according to the message which includes 362 many pairs of end inter-layer LSRs in the side of the higher-layer. 363 By each inter-layer TE link, pairs of end inter-layer LSRs in the 364 side of the lower-layer can be found. 366 Thus the lower-layer PCE can compute at least one inter-layer path by 367 the above information and respond the computation result to the 368 higher-layer PCE. 370 4.6. Optimal Inter-layer Path Computation by BRPC 372 In [PCE-INTER-LAYER-FRWK], BRPC is recommended to solve the problem 373 of multiple PCE inter-layer path computation by considering layers as 374 separate domains. BRPC is always started by the higher-layer PCE 375 according to the response of lower-layer PCE about lower-layer path 376 computation results. In addition, if multiple paths about a common 377 pair of end LSRs are needed, all the complete paths will be ordered 378 in some optimal strategy(e.g., minimum hops number, minimum aggregate 379 te-metrics, etc.). 381 5. Routing Protocol Extensions for Inter-Layer PCE Discovery 383 In a multi-layer network model, multiple PCEs MAY have the function 384 of inter-layer path computation. It may be necessary or desirable 385 for a higher-layer PCE to choose a lower-layer PCE by the PCE 386 discovery information originated from the lower-layer PCE. 388 Since the number of local-layer PCEs may be usually more than one, 389 the PCEs' discovery information to which now is added local-layer and 390 adjacent layer information needs to be flooded through all the layers 391 unless safety is considered. By this way, as a PCC, when a higher- 392 layer PCE needs to send a path computation request to a lower-layer 393 PCE, it can dynamically choose a suitable one but not be allocated a 394 fixed one according to the flooded layers' information from all the 395 PCEs in the lower-layer. That is, all the PCEs belonging to all 396 different layers will form a PCE topology and MAY participate in an 397 independent IGP (OSPF or IS-IS) instance. This PCE topology's 398 visibility MUST be opened only for these PCEs. 400 In [RFC5088] and [RFC5089], PCE discovery information is referred to. 401 It is usually composed of the PCE location, the PCE path computation 402 scope, the set of PCE-Domain(s), the set of neighbor PCE-Domain(s), 403 and the set of communication capabilities etc. Here according to the 404 above description, for the purpose of layer information automatic 405 discovery and dynamically choosing among PCEs from different layers, 406 the set of PCE-Layer(s) and the set of neighbor PCE Layer(s) SHOULD 407 be added to the PCE discovery information. 409 Considering the two new types of PCE discovery information, the sub- 410 TLVs that may be carried within the PCED TLV will be extended. The 411 following sections describe the new extended sub-TLVs. 413 5.1. Extension of PATH-SCOPE Sub-TLV 415 In view of layer information discovery, here PATH-SCOPE Sub-TLV in 416 [RFC5088] and [RFC5089] is extended. Yd bit is added to PATH-SCOPE 417 Sub-TLV and the new sub-TLV has the following format: 419 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type = 2 | Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |0|1|2|3|4|5|6| Reserved |PrefL|PrefR|PrefS|PrefY| Res | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Type: 2 428 Length: 4 429 Value: This comprises a 2-octet flags field where each bit 430 represents a supported path scope, as well as four 431 preference fields used to specify PCE preferences. 433 The following bits are defined: 435 Bit Path Scope 437 0 L bit: Can compute intra-area paths. 438 1 R bit: Can act as PCE for inter-area TE LSP 439 computation. 440 2 Rd bit: Can act as a default PCE for inter-area TE LSP 441 computation. 442 3 S bit: Can act as PCE for inter-AS TE LSP computation. 443 4 Sd bit: Can act as a default PCE for inter-AS TE LSP 444 computation. 445 5 Y bit: Can act as PCE for inter-layer TE LSP 446 computation. 447 6 Yd bit: Can act as a default PCE for inter-layer TE LSP 448 computation. 450 PrefL field: PCE's preference for intra-area TE LSP computation. 452 PrefR field: PCE's preference for inter-area TE LSP computation. 454 PrefS field: PCE's preference for inter-AS TE LSP computation. 456 PrefY field: PCE's preference for inter-layer TE LSP computation. 458 Res: Reserved for future use. 460 The L, R, S, and Y bits are set when the PCE can act as a PCE for 461 intra-area, inter-area, inter-AS, or inter-layer TE LSP computation, 462 respectively. These bits are non-exclusive. 464 Similarly, when set, the Yd bit indicates that the PCE can act as a 465 default PCE for inter-layer TE LSP computation (that is, the PCE can 466 compute a path toward an adjacent layer). When the Yd bit is set, 467 the PCED TLV MUST NOT contain a NEIG-PCE-LAYER sub-TLV. 469 When the Y bit is clear, the Yd bit SHOULD be clear on transmission 470 and MUST be ignored on receipt. 472 5.2. PCE-LAYER Sub-TLV 474 The PCE-LAYER sub-TLV specifies a PCE-LAYER into which the PCE has 475 topology visibility and through which the PCE can compute paths. The 476 PCE-LAYER sub-TLV SHOULD be present when PCE-Layers for which the PCE 477 can operate cannot be inferred by other IGP information: for 478 instance, when the PCE is inter-layer capable (i.e., when the Y bit 479 is set) and the flooding scope is the entire visible layer topology 480 and the entire PCE topology that is composed of all the PCEs from all 481 of layers. A PCED TLV may include multiple PCE-LAYER sub-TLVs when 482 the PCE has visibility into multiple PCE-Layers. 484 The PCE-LAYER sub-TLV has the following format: 486 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type = 6 | Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Layer-type | Reserved | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Layer ID | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 PCE-LAYER sub-TLV format 498 Type: 6 499 Length: 8 500 Current five layer-type values are defined: 501 1 PSC layer 502 2 L2SC layer 503 3 TDM layer 504 4 LSC layer 505 5 FSC layer 507 Layer ID: This indicates the 32-bit Layer ID of a layer where the 508 PCE has visibility and can compute paths. 510 5.3. NEIG-PCE-LAYER Sub-TLV 512 The NEIG-PCE-LAYER sub-TLV specifies a neighbor PCE-Layer toward 513 which a PCE can compute paths. It means that the PCE can take part 514 in the computation of inter-layer TE LSPs with paths that transit 515 this neighbor PCE-Layer. 517 For each PCE-LAYER sub-TLV, this neighbor layer usually refers to the 518 lower adjacent layer. 520 The NEIG-PCE-LAYER sub-TLV has the following format: 522 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type = 7 | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Layer-type | Reserved | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Layer ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 NEIG-PCE-LAYER sub-TLV format 534 Type: 7 535 Length: 8 536 Current five layer-type values are defined: 537 1 PSC layer 538 2 L2SC layer 539 3 TDM layer 540 4 LSC layer 541 5 FSC layer 543 Layer ID: This indicates the 32-bit Layer ID of a neighbor layer 544 toward which the PCE can compute paths. 546 The NEIG-PCE-LAYER sub-TLV MUST be present at least once if the Y bit 547 is set and the Yd bit is cleared. 549 6. Security Considerations 551 The inter-layer path computation procedure relies on the use of the 552 PCEP and as such is subjected to the potential attacks listed in 553 Section 10 of [RFC5440]. In addition to the security mechanisms 554 described in [RFC5440] with regards to spoofing, snooping, 555 falsification, and denial of service, an implementation MAY support a 556 policy module governing the conditions under which a PCE should 557 participate in the inter-layer path computation. 559 In addition, each layer topology's confidentiality should be 560 especially considered. 562 For the purpose of network topology safety and confidentiality, the 563 following points should be paid attention to: 565 o For each PCE in the PCE topology, the flooding scope of its 566 discovery information is limited only to the local-layer topology 567 and the PCE topology. 569 o For the PCEs outside the PCE topology, the flooding scope of its 570 discovery information is limited only to the local-layer topology. 572 o For the PCEs of each layer, not all the PCEs can be added to the 573 PCE topology. Only those which have the capability of inter-layer 574 path computation are qualified for being added to the PCE 575 topology. 577 o For confidentiality consideration, users can add the PCEs to the 578 PCE topology or move them out of it dynamically. But if inter- 579 layer path computation need to be desired, in each layer at least 580 a PCE with the capability of inter-layer path computation should 581 be add to the PCE topology. As a result, some of the PCEs in each 582 layer are invisible to the PCEs in other layers, that is, the 583 PCEs' visibility in one layer is partially opened to other layers. 585 7. Acknowledgments 587 The RFC text was produced using Marshall Rose's xml2rfc tool. 589 The authors would like to extend their warmest thanks to the ZTE's 590 PCE software engineers. 592 8. Normative References 594 [ITUT-G709] 595 ITU-T, "Interface for the Optical Transport Network 596 (OTN)", G.709 Recommendation (and Amendment 1) , 597 October 2001. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 603 (TE) Extensions to OSPF Version 2", RFC 3630, 604 September 2003. 606 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 607 of Generalized Multi-Protocol Label Switching (GMPLS)", 608 RFC 4203, October 2005. 610 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 611 Hierarchy with Generalized Multi-Protocol Label Switching 612 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 614 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 615 Switching (GMPLS) Signaling Extensions for G.709 Optical 616 Transport Networks Control", RFC 4328, January 2006. 618 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 619 "Label Switched Path Stitching with Generalized 620 Multiprotocol Label Switching Traffic Engineering (GMPLS 621 TE)", RFC 5150, February 2008. 623 Authors' Addresses 625 Dajiang Wang 626 ZTE Corporation 627 12F,ZTE Plaza,No.19,Huayuan East Road,Haidian District 628 Beijing 100191 629 P.R.China 631 Phone: +8613811795408 632 Email: wang.dajiang@zte.com.cn 633 URI: http://wwwen.zte.com.cn/ 635 Zhenyu Wang 636 ZTE Corporation 637 12F,ZTE Plaza,No.19,Huayuan East Road,Haidian District 638 Beijing 100191 639 P.R.China 641 Phone: +8613911266628 642 Email: wang.zhenyu1@zte.com.cn 643 Xihua Fu 644 ZTE Corporation 645 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 646 Xi An 710065 647 P.R.China 649 Phone: +8613798412242 650 Email: fu.xihua@zte.com.cn 651 URI: http://wwwen.zte.com.cn/