idnits 2.17.1 draft-oki-pce-inter-layer-req-00.txt: -(269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 464. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LSP-HIER' is mentioned on line 128, but not defined == Unused Reference: 'PCE-DISC-REQ' is defined on line 408, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eiji Oki (Editor) 3 Internet Draft NTT 4 Category: Informational 5 Expires: April 2006 6 October 2005 8 PCC-PCE Communication Requirements for Inter-Layer Traffic 9 Engineering 11 draft-oki-pce-inter-layer-req-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The Path Computation Element (PCE) provides functions of path 38 computation in support of traffic engineering in Multi-Protocol Label 39 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 41 MPLS and GMPLS networks may be constructed from layered service 42 networks. It is advantageous for overall network efficiency to 43 provide end-to-end traffic engineering across multiple network layers. 44 PCE is a candidate solution for such requirements. 46 Generic requirements for a communication protocol between Path 47 Computation Clients (PCCs) and PCEs are presented in "PCE 48 Communication Protocol Generic Requirements". This document 49 complements the generic requirements and presents a detailed set of 50 PCC-PCE communication protocol requirements for inter-layer traffic 51 engineering. 53 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 1. Contributors 60 The following are the authors that contributed to the present 61 document: 63 Eiji Oki (NTT) 64 Jean-Louis Le Roux (France Telecom) 65 Kenji Kumaki (KDDI) 66 Adrian Farrel (Old Dog Consulting) 68 2. Terminology 70 LSP: Label Switched Path. 72 LSR: Label Switching Router. 74 PCC: Path Computation Client: any client application requesting a 75 path computation to be performed by a Path Computation Element. 77 PCE: Path Computation Element: an entity (component, application or 78 network node) that is capable of computing a network path or route 79 based on a network graph and applying computational constraints. 81 TED: Traffic Engineering Database which contains the topology and 82 resource information of the domain. The TED may be fed by IGP 83 extensions or potentially by other means. 85 TE LSP: Traffic Engineering Label Switched Path. 87 TE LSP head-end: head/source/ingress of the TE LSP. 89 TE LSP tail-end: tail/destination/egress of the TE LSP. 91 3. Introduction 93 The Path Computation Element (PCE) defined in [PCE-ARCH] is an entity 94 that is capable of computing a network path or route based on a 95 network graph, and applying computational constraints. 97 A network may comprise of multiple layers. These layers may represent 98 separations of technology (e.g., PSC, TDM VC4, TDM VC12, LSC) or a 99 distinction between client and server networking roles. In this 100 multi-layer network, LSP in lower layers are used to carry upper- 101 layer LSPs. The network topology formed by lower-layer LSPs and 102 advertised to the higher layer is called a Virtual Network Topology 103 (VNT) [MRN-REQ]. It is important to optimize network resource 104 utilization globally, i.e. taking into account all layers, rather 105 than optimizing resource utilization at each layer independently. 106 This allows achieving better network efficiency. This is what we call 107 Inter-layer traffic engineering. This includes mechanisms allowing to 108 compute end-to-end paths across layers, as known as inter-layer path 109 computation, and mechanisms for control and management of VNT by 110 setting up and releasing LSPs in lower layers [MRN-REQ]. 112 Inter-layer traffic engineering is included in the scope of the PCE 113 architecture [PCE-ARCH], and PCE can provide a suitable mechanism for 114 resolving inter-layer path computation issues. 115 The use of PCE for the control of the VNT is for further study. 117 This document presents a set of PCC-PCE communication protocol 118 requirements for inter-layer traffic engineering. It supplements the 119 generic requirements documented in [PCE-COM-REQ]. 121 4. Inter-Layer Traffic Engineering 123 This section describes key topics of inter-layer traffic engineering 124 in MPLS and GMPLS networks. 126 4.1. Inter-Layer Path Computation 128 [LSP-HIER] defines a way to signal an upper-layer LSP, whose explicit 129 route includes lower-layer(s) LSP paths. The computation of end-to- 130 end paths across layers is called Inter-Layer Path Computation. 132 An LSR in the higher-layer may not have information on the lower- 133 layer topology, particularly in an overlay or augmented model, and 134 hence may not be able to compute an end-to-end path across layers. 136 PCE-based Inter-Layer path computation, consists of relying on one or 137 more PCEs to compute an end-to-end path across layers. This could 138 rely on single PCE path computation where a single PCE have topology 139 information on multiple layers, and can compute an end-to-end path 140 considering all layers' topology, or on multiple PCEs computation 141 where a set of PCEs have information of a single layer topology and 142 collaborate together to build an end-to-end path. 144 A two-layer network is considered. The higher-layer network can be 145 considered as a packet-based IP/MPLS network or GMPLS network. The 146 lower-layer network is considered as a GMPLS optical network. The 147 bandwidth granularity of the lower layer is coarse. For example, the 148 bandwidth is equal to 2.5 Gbit/s or 10 Gbit/s. On the other hand, the 149 granularity of the higher layer is flexible and well engineered. 151 Consider the case where higher-layer LSPs are to be established end- 152 to-end across a lower-layer network. For example, packet LSPs carried 153 across an optical core. Connectivity across the lower-layer is 154 achieved by tunneling the higher-layer LSPs within lower-layer LSPs. 155 However, when the bandwidths of the higher-layer LSPs are much 156 smaller than the capacity of the lower-layer LSPs, the resources in 157 the lower layer are not fully utilized unless a mechanism is provided 158 to aggregate multiple higher-layer LSPs into a single lower-layer LSP. 160 There are two main options for routing a higher-layer LSP over a 161 lower-layer network. A single hop route uses a single edge-to-edge 162 lower-layer LSP that is managed as a single hop within the higher 163 layer. A multiple hop route uses a series of lower-layer LSPs each of 164 which appears to the higher-layer LSP as a single hop. 166 Lower-layer LSPs form a Virtual Network Topology, which can be used 167 for routing higher-layer LSPs or to carry IP traffic. Inter-layer 168 path computation for end-to-end LSPs in the higher-layer network that 169 span the lower-layer network may utilize the VNT, and PCE is a 170 candidate for computing the paths of such higher-layer LSPs within 171 the higher-layer network. PCEs could: 172 - perform a single computation on behalf of the ingress LSR using 173 information gathered from more than one layer. This mode is referred 174 as to Single PCE Computation in [PCE-ARCH]. 175 - perform a set of cooperated path computations on behalf of the 176 ingress LSR through cooperation between PCEs responsible for each 177 layer. This mode is referred as to Multiple PCE Computation with 178 inter-PCE communication in [PCE-ARCH]. 179 - perform separate path computations on behalf of the TE LSP head-end 180 and each transit LSR that is the entry point to a new layer. This 181 mode is referred as to Multiple PCE Computation (without inter-PCE 182 communication) in [PCE-ARCH]. This option utilizes per-layer path 183 computation performed independently by successive PCEs. Since there 184 is no PCE-PCE communication, and since each PCE is responsible for a 185 single layer only, there are no requirements placed on the PCC-PCE 186 communications protocol above those already defined for single domain 187 operation described in [PCE-COM-REQ]. Therefore this option is not 188 discussed further in this document. 190 When PCE returns to PCC a computed explicit path that would be 191 acceptable for use for MPLS and GMPLS LSPs once converted to an 192 Explicit Route Object (ERO) for use in RSVP-TE signaling, two options 193 could be considered as: 194 -Option 1: Mono-layer path. There are two cases. The first case is 195 that the PCE computes a path that includes already established lower 196 layer-LSPs: that is the ERO includes sub-object(s) corresponding to 197 lower layer hierarchical LSPs. This does not trigger new lower layer- 198 LSP setup but the utilization of existing lower-layer LSPs. The other 199 is that the PCE computes a path that includes loose hop(s). The 200 higher layer would select which lower layers to use and would select 201 the entry and exit points from those layers, but would not select the 202 path across the layers. A transit LSR corresponding to the entry 203 point is expected to expand the loose hop. Path expansion process on 204 border LSR may result either in the selection of an existing lower 205 layer LSP, or in the computation and setup of a new lower-layer LSP. 206 -Option 2: Multi-layer path. The PCE computes a "multi-layer" path 207 that can include the complete path of one or more lower-layer LSPs 208 not yet established. In that case the ERO contains paths of lower- 209 layer LSPs to be established. The signaling of the higher-layer LSP 210 will trigger the establishment of the lower-layer LSPs (nested 211 signaling). 213 4.2. VNT Management 215 As a result of inter-layer path computation, PCE may determine that 216 there are insufficient lower-layer LSPs to support this or future 217 higher-layer LSPs. New lower-layer LSPs are needed in order to 218 satisfy the high-layer LSP requests or to efficiently manage the 219 utilization of lower-layer network resources. In other words, the VNT 220 needs to be controlled or managed in cooperation with inter-layer 221 path computation. 223 While PCE is responsible for inter-layer path computation, VNT 224 management may be performed by other network elements. The 225 relationship between VNT management and PCE for inter-layer 226 computation is for further study. 228 5. Inter-layer Path Computation Models 230 The generic PCC-PCE communication protocol requirements [PCE-COM-REQ] 231 are limited to basic path computation scenarios and generic concerns. 232 They do not necessarily cover all the requirements for inter-layer 233 traffic engineering and further requirements are stated in section 6 234 of this document to address the specific problem statements set out 235 in this section. 237 As stated in Section 4.1, two PCE modes defined in the PCE 238 architecture can be used to perform inter-layer path computation. 239 They are discussed below. 241 5.1. Single PCE Inter-Layer Path Computation 243 In Figure 1, higher-layer LSRs (H1, H2, H3 and H4) are connected by 244 an end-to-end higher-layer LSP. This is supported by a lower-layer 245 LSP (H2-L1-L2-H3) that traverses the lower-layer LSRs (L1 and L2) but 246 is presented as a single hop (H2-H3) in the higher-layer. A single 247 PCE manages the entire network and has visibility into both layers. 249 ----- 250 | PCE | 251 ----- 253 ----- ----- ----- ----- 254 | LSR |--| LSR |................| LSR |--| LSR | 255 | H1 | | H2 | | H3 | | H4 | 256 ----- -----\ /----- ----- 257 \----- -----/ 258 | LSR |--| LSR | 259 | L1 | | L2 | 260 ----- ----- 262 Figure 1 : Single PCE with Multi-Layer Visibility 264 5.2. Multiple PCE Inter-Layer Path Computation 266 In Figure 2, there is one PCE in each layer. PCEs of each layer 267 collaborate together to compute an end-to-end path across layers. PCE 268 Hi is responsible for computations in the higher layer and may 269 �consult�Ewith PCE Lo to compute paths across the lower layer. PCE Lo 270 is responsible for path computation in lower layer. A simple 271 cooperation could be: PCE Hi requests a path H2-H3 to PCE Lo. Of 272 course more complex cooperation may be required if an end-to-end 273 optimal path is desired. 275 ----- 276 | PCE | 277 | Hi | 278 --+-- 279 | 280 ----- ----- | ----- ----- 281 | LSR |--| LSR |............|...........| LSR |--| LSR | 282 | H1 | | H2 | | | H3 | | H4 | 283 ----- -----\ --+-- /----- ----- 284 \ | PCE | / 285 \ | Lo | / 286 \ ----- / 287 \ / 288 \----- -----/ 289 | LSR |--| LSR | 290 | L1 | | L2 | 291 ----- ----- 293 Figure 2 : Cooperating Single-Layer PCEs 295 6. PCC-PCE Communication Requirements for Inter-Layer Traffic 296 Engineering 298 This section sets out additional requirements not covered in [PCE- 299 COM-REQ] specific to the problems of multi-layer TE. 301 6.1. PCC-PCE Communication 303 The PCC-PCE communication protocol MUST allow requests and replies 304 for inter-layer path computation. 306 This requires no additional messages, but implies the following 307 additional constraints to be added to the PCC-PCE communication 308 protocol. 310 6.1.1 Control of Inter-Layer Path Computation 312 A request from a PCC to a PCE SHOULD indicate whether inter-layer 313 path computation is allowed. In the absence of such an indication, 314 the default is that inter-layer path computation is not allowed. 316 Therefore, a request from a PCC to a PCE MUST support the inclusion 317 of such an indication. 319 6.1.2 Control of Type of Path to be Computed 321 A request from a PCC to a PCE MUST allow controlling the type path to 322 be computed: A mono-layer path that includes already established 323 lower layer-LSP, a mono-layer path that includes loose hop(s), or a 324 multi-layer path that can include the complete path of one or more 325 lower-layer LSPs not yet established. 327 When multi-layer path computation is requested, a response from a PCE 328 to a PCC MUST support the inclusion, as part of end-to-end path, of 329 the path of the lower-layer LSPs to be established. 331 6.1.3 Communication of Inter-Layer Constraints 333 A request from a PCC to a PCE MUST support the inclusion of 334 constraints for multiple layers. This includes the switching type(s) 335 and encoding type(s) that can, must, or must not be used. 337 6.1.4 Cooperation Between PCEs 339 When each layer is controlled by a PCE, which only has access to the 340 topology information of its layer, the PCEs of each layer need to 341 cooperate to perform inter-layer path computation. In this case, 342 communication between PCEs is required for inter-layer path 343 computation. A PCE that behaves as a client is defined as a PCC [PCE- 344 ARCH]. 346 The PCC-PCE communication protocol MUST allow requests and replies 347 for cooperative inter-layer path computation. 349 6.1.5 Inter-Layer Diverse paths 351 The PCE communication protocol MUST allow for the computation of 352 diverse inter-Layer paths. A request from a PCC to a PCE MUST support 353 the inclusion of multiple path request, with the desired level of 354 diversity at each layer (link, node, SRLG). 356 6.2. Supportive Network Models 358 The PCC-PCE communication protocol SHOULD allow several architectural 359 alternatives for interworking between MPLS and GMPLS networks: 360 overlay, integrated and augmented models [RFC3945]. 362 7. Manageability considerations 364 Manageability of inter-layer traffic engineering with PCE must 365 address the following consideration for section 6.1. 367 - need for a MIB module for control and monitoring 368 - need for built-in diagnostic tools 369 - configuration implication for the protocol 371 8. Security Considerations 373 Inter-layer traffic engineering with PCE may raise new security 374 issues when PCE-PCE communication is done between different layer 375 networks for inter-layer path computation. Security issues may also 376 exist when a single PCE is granted full visibility of TE information 377 that applies to multiple layers. 379 It is expected that solutions for inter-layer protocol extensions 380 will address these issues in detail using security techniques such as 381 authentication. 383 9. Acknowledgment 385 We would like to thank Kohei Shiomoto and Ichiro Inoue for their 386 useful comments. 388 10. References 390 10.1 Normative Reference 392 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 393 requirements levels", RFC 2119, March 1997. 395 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 396 Architecture", RFC 3945, October 2004. 398 10.2 Informative Reference 400 [PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, "Path Computation 401 Element (PCE) Architecture", draft-ietf-pce-architecture (work in 402 progress). 404 [PCE-COM-REQ] J. Ash, J.L Le Roux et al., "PCE Communication Protocol 405 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs (work in 406 progress). 408 [PCE-DISC-REQ] JL Le Roux et al., "Requirements for Path Computation 409 Element (PCE) Discovery", draft-ietf-pce-discovery-reqs (work in 410 progress). 412 [MRN-REQ] K. Shiomoto et al., "Requirements for GMPLS-based multi- 413 region networks (MRN) ", draft-shiomoto-ccamp-gmpls-mrn-reqs (work in 414 progress). 416 11. Authors�EAddresses 418 Eiji Oki 419 NTT 420 3-9-11 Midori-cho, 421 Musashino-shi, Tokyo 180-8585, Japan 422 Email: oki.eiji@lab.ntt.co.jp 424 Jean-Louis Le Roux 425 France Telecom R&D, 426 Av Pierre Marzin, 427 22300 Lannion, France 428 Email: jeanlouis.leroux@francetelecom.com 430 Kenji Kumaki 431 KDDI Corporation 432 Garden Air Tower 433 Iidabashi, Chiyoda-ku, 434 Tokyo 102-8460, JAPAN 435 Phone: +81-3-6678-3103 436 Email: ke-kumaki@kddi.com 438 Adrian Farrel 439 Old Dog Consulting 440 Email: adrian@olddog.co.uk 442 12. Intellectual Property Statement 444 The IETF takes no position regarding the validity or scope of any 445 Intellectual Property Rights or other rights that might be claimed to 446 pertain to the implementation or use of the technology described in 447 this document or the extent to which any license under such rights 448 might or might not be available; nor does it represent that it has 449 made any independent effort to identify any such rights. Information 450 on the procedures with respect to rights in RFC documents can be 451 found in BCP 78 and BCP 79. 453 Copies of IPR disclosures made to the IETF Secretariat and any 454 assurances of licenses to be made available, or the result of an 455 attempt made to obtain a general license or permission for the use of 456 such proprietary rights by implementers or users of this 457 specification can be obtained from the IETF on-line IPR repository at 458 http://www.ietf.org/ipr. 460 The IETF invites any interested party to bring to its attention any 461 copyrights, patents or patent applications, or other proprietary 462 rights that may cover technology that may be required to implement 463 this standard. Please address the information to the IETF at ietf- 464 ipr@ietf.org. 466 Disclaimer of Validity 468 This document and the information contained herein are provided on an 469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 471 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 472 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 473 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Copyright Statement 478 Copyright (C) The Internet Society (2005). This document is subject 479 to the rights, licenses and restrictions contained in BCP 78, and 480 except as set forth therein, the authors retain all their rights.