idnits 2.17.1 draft-ietf-ccamp-gmpls-mln-reqs-11.txt: 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, updated by RFC 4748 on line 1312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1295. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kohei Shiomoto (NTT) 3 Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) 4 Intended Status: Informational Jean-Louis Le Roux (France Telecom) 5 Created: May 28, 2008 Martin Vigoureux (Alcatel-Lucent) 6 Expires: November 28, 2008 Deborah Brungard (AT&T) 8 Requirements for GMPLS-Based Multi-Region and 9 Multi-Layer Networks (MRN/MLN) 11 draft-ietf-ccamp-gmpls-mln-reqs-11.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- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire in May 2008. 39 Abstract 41 Most of the initial efforts to utilize Generalized MPLS (GMPLS) 42 have been related to environments hosting devices with a single 43 switching capability. The complexity raised by the control of such 44 data planes is similar to that seen in classical IP/MPLS networks. 45 By extending MPLS to support multiple switching technologies, GMPLS 46 provides a comprehensive framework for the control of a multi- 47 layered network of either a single switching technology or multiple 48 switching technologies. 50 In GMPLS, a switching technology domain defines a region, and a 51 network of multiple switching types is referred to in this document 52 as a Multi-Region Network (MRN). When referring in general to a 53 layered network, which may consist of either a single or multiple 54 regions, this document uses the term, Multi-Layer Network (MLN). 55 This document defines a framework for GMPLS based multi-region / 56 multi-layer networks and lists a set of functional requirements. 58 Table of Contents 59 1. Introduction.................................................3 60 1.1. Scope......................................................4 61 2. Conventions Used in this Document............................5 62 2.1. List of Acronyms...........................................5 63 3. Positioning..................................................6 64 3.1. Data Plane Layers and Control Plane Regions................6 65 3.2. Service Layer Networks.....................................6 66 3.3. Vertical and Horizontal Interaction and Integration........7 67 3.4. Motivation.................................................8 68 4. Key Concepts of GMPLS-Based MLNs and MRNs....................9 69 4.1. Interface Switching Capability.............................9 70 4.2. Multiple Interface Switching Capabilities.................10 71 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes.11 72 4.3. Integrated Traffic Engineering (TE) and Resource Control..11 73 4.3.1. Triggered Signaling.....................................12 74 4.3.2. FA-LSPs.................................................12 75 4.3.3. Virtual Network Topology (VNT)..........................13 76 5. Requirements................................................14 77 5.1. Handling Single-Switching and Multi-Switching-Type-Capable 78 Nodes.....................................................14 79 5.2. Advertisement of the Available Adjustment Resource........14 80 5.3. Scalability...............................................15 81 5.4. Stability.................................................16 82 5.5. Disruption Minimization...................................16 83 5.6. LSP Attribute Inheritance.................................16 84 5.7. Computing Paths With and Without Nested Signaling.........17 85 5.8. LSP Resource Utilization..................................18 86 5.8.1. FA-LSP Release and Setup................................18 87 5.8.2. Virtual TE-Links........................................19 88 5.9. Verification of the LSPs..................................20 89 5.10. Management...............................................20 90 6. Security Considerations.....................................23 91 7. IANA Considerations.........................................23 92 8. Acknowledgements............................................23 93 9. References..................................................23 94 9.1. Normative Reference.......................................23 95 9.2. Informative References....................................24 96 10. Authors' Addresses.........................................25 97 11. Contributors' Addresses....................................26 98 12. Intellectual Property Considerations.......................26 99 13. Full Copyright Statement...................................27 101 1. Introduction 103 Generalized MPLS (GMPLS) extends MPLS to handle multiple switching 104 technologies: packet switching, layer-2 switching, TDM switching, 105 wavelength switching, and fiber switching (see [RFC3945]). The 106 Interface Switching Capability (ISC) concept is introduced for 107 these switching technologies and is designated as follows: PSC 108 (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time 109 Division Multiplex capable), LSC (lambda switch capable), and FSC 110 (fiber switch capable). 112 The representation, in a GMPLS control plane, of a switching 113 technology domain is referred to as a region [RFC4206]. A switching 114 type describes the ability of a node to forward data of a 115 particular data plane technology, and uniquely identifies a network 116 region. A layer describes a data plane switching granularity level 117 (e.g., VC4, VC-12). A data plane layer is associated with a region 118 in the control plane (e.g., VC4 is associated with TDM, MPLS is 119 associated with PSC). However, more than one data plane layer can 120 be associated with the same region (e.g., both VC4 and VC12 are 121 associated with TDM). Thus, a control plane region, identified by 122 its switching type value (e.g., TDM), can be sub-divided into 123 smaller granularity component networks based on "data plane 124 switching layers". The Interface Switching Capability Descriptor 125 (ISCD) [RFC4202], identifying the interface switching capability 126 (ISC), the encoding type, and the switching bandwidth granularity, 127 enables the characterization of the associated layers. 129 In this document, we define a Multi Layer Network (MLN) to be a 130 Traffic Engineering (TE) domain comprising multiple data plane 131 switching layers either of the same ISC (e.g., TDM) or different 132 ISC (e.g., TDM and PSC) and controlled by a single GMPLS control 133 plane instance. We further define a particular case of MLNs. A 134 Multi Region Network (MRN) is defined as a TE domain supporting at 135 least two different switching types (e.g., PSC and TDM), either 136 hosted on the same device or on different ones, and under the 137 control of a single GMPLS control plane instance. 139 MLNs can be further categorized according to the distribution of 140 the ISCs among the Label Switching Routers (LSRs): 142 - Each LSR may support just one ISC. 143 Such LSRs are known as single-switching-type-capable LSRs. 144 The MLN may comprise a set of single-switching-type-capable LSRs 145 some of which support different ISCs. 146 - Each LSR may support more than one ISC at the same time. 147 - Such LSRs are known as multi-switching-type-capable LSRs, and 148 can be further classified as either "simplex" or "hybrid" nodes 149 as defined in Section 4.2. 151 - The MLN may be constructed from any combination of single- 152 switching-type-capable LSRs and multi-switching-type-capable 153 LSRs. 155 Since GMPLS provides a comprehensive framework for the control of 156 different switching capabilities, a single GMPLS instance may be 157 used to control the MLN/MRN. This enables rapid service 158 provisioning and efficient traffic engineering across all switching 159 capabilities. In such networks, TE Links are consolidated into a 160 single Traffic Engineering Database (TED). Since this TED contains 161 the information relative to all the different regions and layers 162 existing in the network, a path across multiple regions or layers 163 can be computed using this TED. Thus optimization of network 164 resources can be achieved across the whole MLN/MRN. 166 Consider, for example, a MRN consisting of packet- switch capable 167 routers and TDM cross-connects. Assume that a packet Label Switched 168 Path (LSP) is routed between source and destination packet-switch 169 capable routers, and that the LSP can be routed across the PSC- 170 region (i.e., utilizing only resources of the packet region 171 topology). If the performance objective for the packet LSP is not 172 satisfied, new TE links may be created between the packet-switch 173 capable routers across the TDM-region (for example, VC-12 links) 174 and the LSP can be routed over those TE links. Furthermore, even if 175 the LSP can be successfully established across the PSC-region, TDM 176 hierarchical LSPs across the TDM region between the packet-switch 177 capable routers may be established and used if doing so is 178 necessary to meet the operator's objectives for network resources 179 availability (e.g., link bandwidth). The same considerations hold 180 when VC4 LSPs are provisioned to provide extra flexibility for the 181 VC12 and/or VC11 layers in an MLN. 183 Sections 3 and 4 of this document provide further background 184 information of the concepts and motivation behind multi-region and 185 multi-layer networks. Section 5 presents detailed requirements for 186 protocols used to implement such networks. 188 1.1.Scope 190 Early sections of this document describe the motivations and 191 reasoning that require the development and deployment of MRN/MLN. 192 Later sections of this document set out the required features that 193 the GMPLS control plane must offer to support MRN/MLN. There is no 194 intention to specify solution- specific and/or protocol elements in 195 this document. The applicability of existing GMPLS protocols and 196 any protocol extensions to the MRN/MLN is addressed in separate 197 documents [MRN-EVAL]. 199 This document covers the elements of a single GMPLS control plane 200 instance controlling multiple layers within a given TE domain. A 201 control plane instance can serve one, two or more layers. Other 202 possible approaches such as having multiple control plane instances 203 serving disjoint sets of layers are outside the scope of this 204 document. It is most probable that such a MLN or MRN would be 205 operated by a single Service Provider, but this document does not 206 exclude the possibility of two layers (or regions) being under 207 different administrative control (for example, by different Service 208 Providers that share a single control plane instance) where the 209 administrative domains are prepared to share a limited amount of 210 information. 212 For such TE domain to interoperate with edge nodes/domains 213 supporting non-GMPLS interfaces (such as those defined by other 214 SDOs), an interworking function may be needed. Location and 215 specification of this function are outside the scope of this 216 document (because interworking aspects are strictly under the 217 responsibility of the interworking function). 219 This document assumes that the interconnection of adjacent MRN/MLN 220 TE domains makes use of [RFC4726] when their edges also support 221 inter- domain GMPLS RSVP-TE extensions. 223 2. Conventions Used in this Document 225 Although this is not a protocol specification, the key words "MUST", 226 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 227 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in this 228 document to highlight requirements, and are to be interpreted as 229 described in RFC 2119 [RFC2119]. 231 2.1.List of Acronyms 233 ERO: Explicit Route Object 234 FA: Forwarding Adjacency 235 FA-LSP: Forwarding Adjacency Label Switched Path 236 FSC: Fiber Switching Capable 237 ISC: Interface Switching Capability 238 ISCD: Interface Switching Capability Descriptor 239 L2SC: Layer-2 Switching Capable 240 LSC: Lambda Switching Capable 241 LSP: Label Switched Path 242 LSR: Label Switching Router 243 MLN: Multi-Layer Network 244 MRN: Multi-Region Network 245 PSC: Packet Switching Capable 246 SRLG: Shared Risk Ling Group 247 TDM: Time-Division Switch Capable 248 TE: Traffic Engineering 249 TED: Traffic Engineering Database 250 VNT: Virtual Network Topology 252 3. Positioning 254 A multi-region network (MRN) is always a multi-layer network (MLN) 255 since the network devices on region boundaries bring together 256 different ISCs. A MLN, however, is not necessarily a MRN since 257 multiple layers could be fully contained within a single region. 258 For example, VC12, VC4, and VC4-4c are different layers of the TDM 259 region. 261 3.1. Data Plane Layers and Control Plane Regions 263 A data plane layer is a collection of network resources capable of 264 terminating and/or switching data traffic of a particular format 265 [RFC4397]. These resources can be used for establishing LSPs for 266 traffic delivery. For example, VC-11 and VC4-64c represent two 267 different layers. 269 From the control plane viewpoint, an LSP region is defined as a set 270 of one or more data plane layers that share the same type of 271 switching technology, that is, the same switching type. For example, 272 VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. 273 The regions that are currently defined are: PSC, L2SC, TDM, LSC, 274 and FSC. Hence, an LSP region is a technology domain (identified by 275 the ISC type) for which data plane resources (i.e., data links) are 276 represented into the control plane as an aggregate of TE 277 information associated with a set of links (i.e., TE links). For 278 example VC-11 and VC4-64c capable TE links are part of the same TDM 279 region. Multiple layers can thus exist in a single region network. 281 Note also that the region may produce a distinction within the 282 control plane. Layers of the same region share the same switching 283 technology and, therefore, use the same set of technology-specific 284 signaling objects and technology-specific value setting of TE link 285 attributes within the control plane, but layers from different 286 regions may use different technology-specific objects and TE 287 attribute values. This means that it may not be possible to simply 288 forward the signaling message between LSR hosting different 289 switching technologies because change in some of the signaling 290 objects (for example, the traffic parameters) when crossing a 291 region boundary even if a single control plane instance is used to 292 manage the whole MRN. We may solve this issue by using triggered 293 signaling (see Section 4.3.1). 295 3.2. Service Layer Networks 297 A service provider's network may be divided into different service 298 layers. The customer's network is considered from the provider's 299 perspective as the highest service layer. It interfaces to the 300 highest service layer of the service provider's network. 301 Connectivity across the highest service layer of the service 302 provider's network may be provided with support from successively 303 lower service layers. Service layers are realized via a hierarchy 304 of network layers located generally in several regions and commonly 305 arranged according to the switching capabilities of network devices. 307 For instance some customers purchase Layer 1 (i.e., transport) 308 services from the service provider, some Layer 2 (e.g., ATM), while 309 others purchase Layer 3 (IP/MPLS) services. The service provider 310 realizes the services by a stack of network layers located within 311 one or more network regions. The network layers are commonly 312 arranged according to the switching capabilities of the devices in 313 the networks. Thus, a customer network may be provided on top of 314 the GMPLS-based multi-region/multi-layer network. For example, a 315 Layer 1 service (realized via the network layers of TDM, and/or LSC, 316 and/or FSC regions) may support a Layer 2 network (realized via ATM 317 VP/VC) which may itself support a Layer 3 network (IP/MPLS region). 318 The supported data plane relationship is a data plane client-server 319 relationship where the lower layer provides a service for the 320 higher layer using the data links realized in the lower layer. 322 Services provided by a GMPLS-based multi-region/multi-layer network 323 are referred to as "Multi-region/Multi-layer network services". For 324 example, legacy IP and IP/MPLS networks can be supported on top of 325 multi-region/multi-layer networks. It has to be emphasized that 326 delivery of such diverse services is a strong motivator for the 327 deployment of multi-region/multi-layer networks. 329 A customer network may be provided on top of a server GMPLS-based 330 MRN/MLN which is operated by a service provider. For example, a 331 pure IP and/or an IP/MPLS network can be provided on top of GMPLS- 332 based packet over optical networks [RFC5146]. The relationship 333 between the networks is a client/server relationship and, such 334 services are referred to as "MRN/MLN services". In this case, the 335 customer network may form part of the MRN/MLN, or may be partially 336 separated, for example to maintain separate routing information but 337 retain common signaling. 339 3.3. Vertical and Horizontal Interaction and Integration 341 Vertical interaction is defined as the collaborative mechanisms 342 within a network element that is capable of supporting more than 343 one layer or region and of realizing the client/server 344 relationships between the layers or regions. Protocol exchanges 345 between two network controllers managing different regions or 346 layers are also a vertical interaction. Integration of these 347 interactions as part of the control plane is referred to as 348 vertical integration. Thus, this refers to the collaborative 349 mechanisms within a single control plane instance driving multiple 350 network layers part of the same region or not. Such a concept is 351 useful in order to construct a framework that facilitates efficient 352 network resource usage and rapid service provisioning in carrier 353 networks that are based on multiple layers, switching technologies, 354 or ISCs. 356 Horizontal interaction is defined as the protocol exchange between 357 network controllers that manage transport nodes within a given 358 layer or region. For instance, the control plane interaction 359 between two TDM network elements switching at OC-48 is an example 360 of horizontal interaction. GMPLS protocol operations handle 361 horizontal interactions within the same routing area. The case 362 where the interaction takes place across a domain boundary, such as 363 between two routing areas within the same network layer, is 364 evaluated as part of the inter- domain work [RFC4726], and is 365 referred to as horizontal integration. Thus, horizontal integration 366 refers to the collaborative mechanisms between network partitions 367 and/or administrative divisions such as routing areas or autonomous 368 systems. 370 This distinction needs further clarification when administrative 371 domains match layer/region boundaries. Horizontal interaction is 372 extended to cover such cases. For example, the collaborative 373 mechanisms in place between two lambda switching capable areas 374 relate to horizontal integration. On the other hand, the 375 collaborative mechanisms in place between a packet switching 376 capable (e.g., IP/MPLS) domain and a separate time division 377 switching capable (e.g., VC4 SDH) domain over which it operates are 378 part of the horizontal integration while it can also be seen as a 379 first step towards vertical integration. 381 3.4.Motivation 383 The applicability of GMPLS to multiple switching technologies 384 provides a unified control and management approach for both LSP 385 provisioning and recovery. Indeed, one of the main motivations for 386 unifying the capabilities and operations of the GMPLS control plane 387 is the desire to support multi-LSP-region [RFC4206] routing and 388 Traffic Engineering (TE) capabilities. For instance, this enables 389 effective network resource utilization of both the Packet/Layer2 390 LSP regions and the Time Division Multiplexing (TDM) or Lambda LSP 391 regions in high capacity networks. 393 The rationales for GMPLS controlled multi-layer/multi-region 394 networks are summarized below: 396 - The maintenance of multiple instances of the control plane on 397 devices hosting more than one switching capability not only 398 increases the complexity of their interactions but also increases 399 the total amount of processing individual instances would handle. 401 - The unification of the addressing spaces helps in avoiding 402 multiple identifiers for the same object (a link, for instance, 403 or more generally, any network resource). On the other hand such 404 aggregation does not impact the separation between the control 405 plane and the data plane. 407 - By maintaining a single routing protocol instance and a single TE 408 database per LSR, a unified control plane model removes the 409 requirement to maintain a dedicated routing topology per layer 410 and therefore does not mandate a full mesh of routing adjacencies 411 as is the case with overlaid control planes. 413 - The collaboration between technology layers where the control 414 channel is associated with the data channel (e.g. packet/framed 415 data planes) and technology layers where the control channel is 416 not directly associated with the data channel (SONET/SDH, G.709, 417 etc.) is facilitated by the capability within GMPLS to associate 418 in-band control plane signaling to the IP terminating interfaces 419 of the control plane. 421 - Resource management and policies to be applied at the edges of 422 such a MRN/MLN is made more simple (fewer control to management 423 interactions) and more scalable (through the use of aggregated 424 information). 426 - Multi-region/multi-layer traffic engineering is facilitated as 427 TE-links from distinct regions/layers are stored within the same 428 TE Database. 430 4. Key Concepts of GMPLS-Based MLNs and MRNs 432 A network comprising transport nodes with multiple data plane 433 layers of either the same ISC or different ISCs, controlled by a 434 single GMPLS control plane instance, is called a Multi-Layer 435 Network (MLN). A sub-set of MLNs consists of networks supporting 436 LSPs of different switching technologies (ISCs). A network 437 supporting more than one switching technology is called a Multi- 438 Region Network (MRN). 440 4.1. Interface Switching Capability 442 The Interface Switching Capability (ISC) is introduced in GMPLS to 443 support various kinds of switching technology in a unified way 444 [RFC4202]. An ISC is identified via a switching type. 446 A switching type (also referred to as the switching capability 447 type) describes the ability of a node to forward data of a 448 particular data plane technology, and uniquely identifies a network 449 region. The following ISC types (and, hence, regions) are defined: 450 PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more 451 precisely, each interface connecting a data link to a node) in a 452 GMPLS network is associated with an ISC. 454 The ISC value is advertised as a part of the Interface Switching 455 Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end 456 associated with a particular link interface [RFC4202]. Apart from 457 the ISC, the ISCD contains information including the encoding type, 458 the bandwidth granularity, and the unreserved bandwidth on each of 459 eight priorities at which LSPs can be established. The ISCD does 460 not "identify" network layers, it uniquely characterizes 461 information associated to one or more network layers. 463 TE link end advertisements may contain multiple ISCDs. This can be 464 interpreted as advertising a multi-layer (or multi-switching- 465 capable) TE link end. That is, the TE link end (and therefore the 466 TE link) is present in multiple layers. 468 4.2. Multiple Interface Switching Capabilities 470 In an MLN, network elements may be single-switching-type-capable or 471 multi-switching-type-capable nodes. Single-switching-type-capable 472 nodes advertise the same ISC value as part of their ISCD sub-TLV(s) 473 to describe the termination capabilities of each of their TE 474 Link(s). This case is described in [RFC4202]. 476 Multi-switching-type-capable LSRs are classified as "simplex" or 477 "hybrid" nodes. Simplex and hybrid nodes are categorized according 478 to the way they advertise these multiple ISCs: 480 - A simplex node can terminate data links with different switching 481 capabilities where each data link is connected to the node by a 482 separate link interface. So, it advertises several TE Links each 483 with a single ISC value carried in its ISCD sub-TLV (following 484 the rules defined in [RFC4206]). For example, an LSR with PSC and 485 TDM links each of which is connected to the LSR via a separate 486 interface. 488 - A hybrid node can terminate data links with different switching 489 capabilities where the data links are connected to the node by 490 the same interface. So, it advertises a single TE Link 491 containing more than one ISCD each with a different ISC value. 492 For example, a node may terminate PSC and TDM data links and 493 interconnect those external data links via internal links. The 494 external interfaces connected to the node have both PSC and TDM 495 capabilities. 497 Additionally, TE link advertisements issued by a simplex or a 498 hybrid node may need to provide information about the node's 499 internal adjustment capacity between the switching technologies 500 supported. The term "adjustment" capacity refers to the property of 501 an hybrid node to interconnect different switching capabilities it 502 provides through its external interfaces.. This information allows 503 path computation to select an end- to-end multi-layer or multi- 504 region path that includes links of different switching capabilities 505 that are joined by LSRs that can adapt the signal between the links. 507 4.2.1.Networks with Multi-Switching-Type-Capable Hybrid Nodes 509 This type of network contains at least one hybrid node, zero or 510 more simplex nodes, and a set of single-switching-type-capable 511 nodes. 513 Figure 1 shows an example hybrid node. The hybrid node has two 514 switching elements (matrices), which support, for instance, TDM and 515 PSC switching respectively. The node terminates a PSC and a TDM 516 link (Link1 and Link2 respectively). It also has an internal link 517 connecting the two switching elements. 519 The two switching elements are internally interconnected in such a 520 way that it is possible to terminate some of the resources of, say, 521 Link2 and provide adjustment for PSC traffic received/sent over the 522 PSC interface (#b). This situation is modeled in GMPLS by 523 connecting the local end of Link2 to the TDM switching element via 524 an additional interface realizing the termination/adjustment 525 function. There are two possible ways to set up PSC LSPs through 526 the hybrid node. Available resource advertisement (i.e., Unreserved 527 and Min/Max LSP Bandwidth) should cover both of these methods. 529 ............................. 530 : Network element : 531 : -------- : 532 : | PSC | : 533 Link1 -------------<->--|#a | : 534 : | | : 535 : +--<->---|#b | : 536 : | -------- : 537 : | ---------- : 538 TDM : +--<->--|#c TDM | : 539 +PSC : | | : 540 Link2 ------------<->--|#d | : 541 : ---------- : 542 :............................ 544 Figure 1. Hybrid node. 546 4.3. Integrated Traffic Engineering (TE) and Resource Control 548 In GMPLS-based multi-region/multi-layer networks, TE Links may be 549 consolidated into a single Traffic Engineering Database (TED) for 550 use by the single control plane instance. Since this TED contains 551 the information relative to all the layers of all regions in the 552 network, a path across multiple layers (possibly crossing multiple 553 regions) can be computed using the information in this TED. Thus, 554 optimization of network resources across the multiple layers of the 555 same region and across multiple regions can be achieved. 557 These concepts allow for the operation of one network layer over 558 the topology (that is, TE links) provided by other network layers 559 (for example, the use of a lower layer LSC LSP carrying PSC LSPs). 560 In turn, a greater degree of control and inter-working can be 561 achieved, including (but not limited too): 563 - Dynamic establishment of Forwarding Adjacency (FA) LSPs 564 [RFC4206] (see Sections 4.3.2 and 4.3.3). 566 - Provisioning of end-to-end LSPs with dynamic triggering of FA 567 LSPs. 569 Note that in a multi-layer/multi-region network that includes 570 multi- switching-type-capable nodes, an explicit route used to 571 establish an end-to-end LSP can specify nodes that belong to 572 different layers or regions. In this case, a mechanism to control 573 the dynamic creation of FA-LSPs may be required (see Sections 4.3.2 574 and 4.3.3). 576 There is a full spectrum of options to control how FA-LSPs are 577 dynamically established. The process can be subject to the control 578 of a policy, which may be set by a management component, and which 579 may require that the management plane is consulted at the time that 580 the FA-LSP is established. Alternatively, the FA-LSP can be 581 established at the request of the control plane without any 582 management control. 584 4.3.1. Triggered Signaling 586 When an LSP crosses the boundary from an upper to a lower layer, it 587 may be nested into a lower layer FA-LSP that crosses the lower 588 layer. From a signaling perspective, there are two alternatives to 589 establish the lower layer FA-LSP: static (pre-provisioned) and 590 dynamic (triggered). A pre-provisioned FA-LSP may be initiated 591 either by the operator or automatically using features like TE 592 auto-mesh [RFC4972]. If such a lower layer LSP does not already 593 exist, the LSP may be established dynamically. Such a mechanism is 594 referred to as "triggered signaling". 596 4.3.2. FA-LSPs 598 Once an LSP is created across a layer from one layer border node to 599 another, it can be used as a data link in an upper layer. 601 Furthermore, it can be advertised as a TE-link, allowing other 602 nodes to consider the LSP as a TE link for their path computation 603 [RFC4206]. An LSP created either statically or dynamically by one 604 instance of the control plane and advertised as a TE link into the 605 same instance of the control plane is called a Forwarding Adjacency 606 LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE 607 link is called a Forwarding Adjacency (FA). An FA has the special 608 characteristic of not requiring a routing adjacency (peering) 609 between its end points yet still guaranteeing control plane 610 connectivity between the FA-LSP end points based on a signaling 611 adjacency. An FA is a useful and powerful tool for improving the 612 scalability of GMPLS Traffic Engineering (TE) capable networks 613 since multiple higher layer LSPs may be nested (aggregated) over a 614 single FA-LSP. 616 The aggregation of LSPs enables the creation of a vertical (nested) 617 LSP Hierarchy. A set of FA-LSPs across or within a lower layer can 618 be used during path selection by a higher layer LSP. Likewise, the 619 higher layer LSPs may be carried over dynamic data links realized 620 via LSPs (just as they are carried over any "regular" static data 621 links). This process requires the nesting of LSPs through a 622 hierarchical process [RFC4206]. The TED contains a set of LSP 623 advertisements from different layers that are identified by the 624 ISCD contained within the TE link advertisement associated with the 625 LSP [RFC4202]. 627 If a lower layer LSP is not advertised as an FA, it can still be 628 used to carry higher layer LSPs across the lower layer. For example, 629 if the LSP is set up using triggered signaling, it will be used to 630 carry the higher layer LSP that caused the trigger. Further, the 631 lower layer remains available for use by other higher layer LSPs 632 arriving at the boundary. 634 Under some circumstances it may be useful to control the 635 advertisement of LSPs as FAs during the signaling establishment of 636 the LSPs [DYN-HIER]. 638 4.3.3. Virtual Network Topology (VNT) 640 A set of one or more of lower-layer LSPs provides information for 641 efficient path handling in upper-layer(s) of the MLN, or, in other 642 words, provides a virtual network topology (VNT) to the upper- 643 layers. For instance, a set of LSPs, each of which is supported by 644 an LSC LSP, provides a virtual network topology to the layers of a 645 PSC region, assuming that the PSC region is connected to the LSC 646 region. Note that a single lower-layer LSP is a special case of the 647 VNT. The virtual network topology is configured by setting up or 648 tearing down the lower layer LSPs. By using GMPLS signaling and 649 routing protocols, the virtual network topology can be adapted to 650 traffic demands. 652 A lower-layer LSP appears as a TE-link in the VNT. Whether the 653 diversely-routed lower-layer LSPs are used or not, the routes of 654 lower-layer LSPs are hidden from the upper layer in the VNT. Thus, 655 the VNT simplifies the upper-layer routing and traffic engineering 656 decisions by hiding the routes taken by the lower-layer LSPs. 657 However, hiding the routes of the lower-layer LSPs may lose 658 important information that is needed to make the higher-layer LSPs 659 reliable. For instance, the routing and traffic engineering in the 660 IP/MPLS layer does not usually consider how the IP/MPLS TE links 661 are formed from optical paths that are routed in the fiber layer. 662 Two optical paths may share the same fiber link in the lower-layer 663 and therefore they may both fail if the fiber link is cut. Thus the 664 shared risk properties of the TE links in the VNT must be made 665 available to the higher layer during path computation. Further, the 666 topology of the VNT should be designed so that any single fiber cut 667 does not bisect the VNT. These issues are addressed later in this 668 document. 670 Reconfiguration of the virtual network topology may be triggered by 671 traffic demand changes, topology configuration changes, signaling 672 requests from the upper layer, and network failures. For instance, 673 by reconfiguring the virtual network topology according to the 674 traffic demand between source and destination node pairs, network 675 performance factors, such as maximum link utilization and residual 676 capacity of the network, can be optimized. Reconfiguration is 677 performed by computing the new VNT from the traffic demand matrix 678 and optionally from the current VNT. Exact details are outside the 679 scope of this document. However, this method may be tailored 680 according to the service provider's policy regarding network 681 performance and quality of service (delay, loss/disruption, 682 utilization, residual capacity, reliability). 684 5. Requirements 686 5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes 688 The MRN/MLN can consist of single-switching-type-capable and multi- 689 switching-type-capable nodes. The path computation mechanism in the 690 MLN should be able to compute paths consisting of any combination 691 of such nodes. 693 Both single-switching-type-capable and multi-switching-type-capable 694 (simplex or hybrid) nodes could play the role of layer boundary. 695 MRN/MLN Path computation should handle TE topologies built of any 696 combination of nodes. 698 5.2. Advertisement of the Available Adjustment Resource 700 A hybrid node should maintain resources on its internal links (the 701 links required for vertical (layer) integration). Likewise, path 702 computation elements should be prepared to use the availability of 703 termination/ adjustment resources as a constraint in MRN/MLN path 704 computations to reduce the higher layer LSP setup blocking 705 probability caused by the lack of necessary termination/adjustment 706 resources in the lower layer(s). 708 The advertisement of the adjustment capability to terminate LSPs of 709 lower-region and forward traffic in the upper-region is REQUIRED, 710 as it provides critical information when performing multi-region 711 path computation. 713 The path computation mechanism should cover the case where the 714 upper-layer links which are directly connected to upper-layer 715 switching element and the ones which are connected through internal 716 links between upper-layer element and lower-layer element coexist 717 (see Section 4.2.1). 719 5.3. Scalability 721 The MRN/MLN relies on unified routing and traffic engineering 722 models. 724 - Unified routing model: By maintaining a single routing protocol 725 instance and a single TE database per LSR, a unified control 726 plane model removes the requirement to maintain a dedicated 727 routing topology per layer, and therefore does not mandate a full 728 mesh of routing adjacencies per layer. 730 - Unified TE model: The TED in each LSR is populated with TE-links 731 from all layers of all regions (TE link interfaces on multiple- 732 switching-capability LSRs can be advertised with multiple ISCDs). 733 This may lead to an increase in the amount of information that 734 has to be flooded and stored within the network. 736 Furthermore, path computation times, which may be of great 737 importance during restoration, will depend on the size of the TED. 739 Thus MRN/MLN routing mechanisms MUST be designed to scale well with 740 an increase of any of the following: 742 - Number of nodes 743 - Number of TE-links (including FA-LSPs) 744 - Number of LSPs - Number of regions and layers 745 - Number of ISCDs per TE-link. 747 Further, design of the routing protocols MUST NOT prevent TE 748 information filtering based on ISCDs. The path computation 749 mechanism and the signaling protocol SHOULD be able to operate on 750 partial TE information. 752 Since TE Links can advertise multiple Interface Switching 753 Capabilities (ISCs), the number of links can be limited (by 754 combination) by using specific topological maps referred to as VNTs 755 (Virtual Network Topologies). The introduction of virtual 756 topological maps leads us to consider the concept of emulation of 757 data plane overlays. 759 5.4. Stability 761 Path computation is dependent on the network topology and 762 associated link state. The path computation stability of an upper 763 layer may be impaired if the VNT changes frequently and/or if the 764 status and TE parameters (the TE metric, for instance) of links in 765 the VNT changes frequently. In this context, robustness of the VNT 766 is defined as the capability to smooth changes that may occur and 767 avoid their propagation into higher layers. Changes to the VNT may 768 be caused by the creation, deletion, or modification of LSPs. 770 Protocol mechanisms MUST be provided to enable creation, deletion, 771 and modification of LSPs triggered through operational actions. 772 Protocol mechanisms SHOULD be provided to enable similar functions 773 triggered by adjacent layers. Protocol mechanisms MAY be provided 774 to enable similar functions to adapt to the environment changes 775 such as traffic demand changes, topology changes, and network 776 failures. Routing robustness should be traded with adaptability of 777 those changes. 779 5.5. Disruption Minimization 781 When reconfiguring the VNT according to a change in traffic demand, 782 the upper-layer LSP might be disrupted. Such disruption to the 783 upper layers must be minimized. 785 When residual resource decreases to a certain level, some lower 786 layer LSPs may be released according to local or network policies. 787 There is a trade-off between minimizing the amount of resource 788 reserved in the lower layer and disrupting higher layer traffic 789 (i.e. moving the traffic to other TE-LSPs so that some LSPs can be 790 released). Such traffic disruption may be allowed, but MUST be 791 under the control of policy that can be configured by the operator. 792 Any repositioning of traffic MUST be as non-disruptive as possible 793 (for example, using make-before-break). 795 5.6. LSP Attribute Inheritance 797 TE-Link parameters should be inherited from the parameters of the 798 LSP that provides the TE-link, and so from the TE-links in the 799 lower layer that are traversed by the LSP. 801 These include: 803 - Interface Switching Capability 804 - TE metric 805 - Maximum LSP bandwidth per priority level 806 - Unreserved bandwidth for all priority levels 807 - Maximum Reservable bandwidth 808 - Protection attribute 809 - Minimum LSP bandwidth (depending on the Switching Capability) 810 - SRLG 812 Inheritance rules must be applied based on specific policies. 813 Particular attention should be given to the inheritance of TE 814 metric (which may be other than a strict sum of the metrics of the 815 component TE links at the lower layer), protection attributes, and 816 SRLG. 818 As described earlier, hiding the routes of the lower-layer LSPs may 819 lose important information necessary to make LSPs in the higher 820 layer network reliable. SRLGs may be used to identify which lower- 821 layer LSPs share the same failure risk so that the potential risk 822 of the VNT becoming disjoint can be minimized, and so that resource 823 disjoint protection paths can be set up in the higher layer. How to 824 inherit the SRLG information from the lower layer to the upper 825 layer needs more discussion and is out of scope of this document. 827 5.7. Computing Paths With and Without Nested Signaling 829 Path computation can take into account LSP region and layer 830 boundaries when computing a path for an LSP. Path computation may 831 restrict the path taken by an LSP to only the links whose interface 832 switching capability is PSC. For example, suppose that a TDM-LSP is 833 routed over the topology composed of TE links of the same TDM layer. 834 In calculating the path for the LSP, the TED may be filtered to 835 include only links where both end include requested LSP switching 836 type. In this way hierarchical routing is done by using a TED 837 filtered with respect to switching capability (that is, with 838 respect to particular layer). 840 If triggered signaling is allowed, the path computation mechanism 841 may produce a route containing multiple layers/regions. The path is 842 computed over the multiple layers/regions even if the path is not 843 "connected" in the same layer as the endpoints of the path exist. 844 Note that here we assume that triggered signaling will be invoked 845 to make the path "connected", when the upper-layer signaling 846 request arrives at the boundary node. 848 The upper-layer signaling request MAY contain an ERO (Explicit 849 Route Object) that includes only hops in the upper layer, in which 850 case the boundary node is responsible for triggered creation of the 851 lower-layer FA-LSP using a path of its choice, or for the selection 852 of any available lower layer LSP as a data link for the higher 853 layer. This mechanism is appropriate for environments where the TED 854 is filtered in the higher layer, where separate routing instances 855 are used per layer, or where administrative policies prevent the 856 higher layer from specifying paths through the lower layer. 858 Obviously, if the lower layer LSP has been advertised as a TE link 859 (virtual or real) into the higher layer, then the higher layer 860 signaling request MAY contain the TE link identifier and so 861 indicate the lower layer resources to be used. But in this case, 862 the path of the lower layer LSP can be dynamically changed by the 863 lower layer at any time. 865 Alternatively, the upper-layer signaling request MAY contain an ERO 866 specifying the lower layer FA-LSP route. In this case, the boundary 867 node MAY decide whether it should use the path contained in the 868 strict ERO or re-compute the path within the lower-layer. 870 Even in the case that the lower-layer FA-LSPs are already 871 established, a signaling request may also be encoded as a loose ERO. 872 In this situation, it is up to the boundary node to decide whether 873 it should create a new lower-layer FA-LSP or it should use an 874 existing lower-layer FA-LSPs. 876 The lower-layer FA-LSP can be advertised just as an FA-LSP in the 877 upper-layer or an IGP adjacency can be brought up on the lower- 878 layer FA-LSP. 880 5.8. LSP Resource Utilization 882 Resource usage in all layers should be optimized as a whole (i.e., 883 across all layers), in a coordinated manner, (i.e., taking all 884 layers into account). The number of lower-layer LSPs carrying 885 upper-layer LSPs should be minimized (note that multiple LSPs may 886 be used for load balancing). Lower-layer LSPs that could have their 887 traffic re-routed onto other LSPs are unnecessary and should be 888 avoided. 890 5.8.1. FA-LSP Release and Setup 892 If there is low traffic demand, some FA-LSPs that do not carry any 893 higher-layer LSP may be released so that lower-layer resources are 894 released and can be assigned to other uses. Note that if a small 895 fraction of the available bandwidth of an FA-LSP is still in use, 896 the nested LSPs can also be re-routed to other FA-LSPs (optionally 897 using the make-before-break technique) to completely free up the 898 FA-LSP. Alternatively, unused FA-LSPs may be retained for future 899 use. Release or retention of underutilized FA-LSPs is a policy 900 decision. 902 As part of the re-optimization process, the solution MUST allow 903 rerouting of an FA-LSP while keeping interface identifiers of 904 corresponding TE links unchanged. Further, this process MUST be 905 possible while the FA-LSP is carrying traffic (higher layer LSPs) 906 with minimal disruption to the traffic. 908 Additional FA-LSPs may also be created based on policy, which might 909 consider residual resources and the change of traffic demand across 910 the region. By creating the new FA-LSPs, the network performance 911 such as maximum residual capacity may increase. 913 As the number of FA-LSPs grows, the residual resource may decrease. 914 In this case, re-optimization of FA-LSPs may be invoked according 915 to policy. 917 Any solution MUST include measures to protect against network 918 destabilization caused by the rapid setup and teardown of LSPs as 919 traffic demand varies near a threshold. 921 Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly 922 advertise the LSP as a TE link and to coordinate into which routing 923 instances the TE link should be advertised. 925 5.8.2. Virtual TE-Links 927 It may be considered disadvantageous to fully instantiate (i.e. 928 pre- provision) the set of lower layer LSPs that provide the VNT 929 since this might reserve bandwidth that could be used for other 930 LSPs in the absence of upper-layer traffic. 932 However, in order to allow path computation of upper-layer LSPs 933 across the lower-layer, the lower-layer LSPs may be advertised into 934 the upper-layer as though they had been fully established, but 935 without actually establishing them. Such TE links that represent 936 the possibility of an underlying LSP are termed "virtual TE-links." 937 It is an implementation choice at a layer boundary node whether to 938 create real or virtual TE-links, and the choice if available in an 939 implementation MUST be under the control of operator policy. Note 940 that there is no requirement to support the creation of virtual TE- 941 links, since real TE-links (with established LSPs) may be used, and 942 even if there are no TE-links (virtual or real) advertised to the 943 higher layer, it is possible to route a higher layer LSP into a 944 lower layer on the assumptions that proper hierarchical LSPs in the 945 lower layer will be dynamically created (triggered) as needed. 947 If an upper-layer LSP that makes use of a virtual TE-Link is set up, 948 the underlying LSP MUST be immediately signaled in the lower layer. 950 If virtual TE-Links are used in place of pre-established LSPs, the 951 TE-links across the upper-layer can remain stable using pre- 952 computed paths while wastage of bandwidth within the lower-layer 953 and unnecessary reservation of adaptation resource at the border 954 nodes can be avoided. 956 The solution SHOULD provide operations to facilitate the build-up 957 of such virtual TE-links, taking into account the (forecast) 958 traffic demand and available resource in the lower-layer. 960 Virtual TE-links can be added, removed or modified dynamically (by 961 changing their capacity) according to the change of the (forecast) 962 traffic demand and the available resource in the lower-layer. It 963 MUST be possible to add, remove, and modify virtual TE-links in a 964 dynamic way. 966 Any solution MUST include measures to protect against network 967 destabilization caused by the rapid changes in the virtual network 968 topology as traffic demand varies near a threshold. 970 The concept of the VNT can be extended to allow the virtual TE- 971 links to form part of the VNT. The combination of the fully 972 provisioned TE-links and the virtual TE-links defines the VNT 973 provided by the lower layer. The VNT can be changed by setting up 974 and/or tearing down virtual TE links as well as by modifying real 975 links (i.e., the fully provisioned LSPs). How to design the VNT and 976 how to manage it are out of scope of this document. 978 In some situations, selective advertisement of the preferred 979 connectivity among a set of border nodes between layers may be 980 appropriate. Further decreasing the number of advertisement of the 981 virtual connectivity can be achieved by abstracting the topology 982 (between border nodes) using models similar to those detailed in 983 [RFC4847]. 985 5.9. Verification of the LSPs 987 When a lower layer LSP is established for use as a data link by a 988 higher layer, the LSP may be verified for correct connectivity and 989 data integrity before it is made available for use. Such mechanisms 990 are data technology-specific and are beyond the scope of this 991 document, but the GMPLS protocols SHOULD provide mechanisms for the 992 coordination of data link verification. 994 5.10. Management 996 A MRN/MLN requires management capabilities. Operators need to have 997 the same level of control and management for switches and links in 998 the network that they would have in a single layer or single region 999 network. 1001 We can consider two different operational models: (1) Per-layer 1002 management entities, (2) Cross-layer management entities. 1004 Regarding per-layer management entities, it is possible for the MLN 1005 to be managed entirely as separate layers although that somewhat 1006 defeats the objective of defining a single multi-layer network. In 1007 this case, separate management systems would be operated for each 1008 layer, and those systems would be unaware of the fact that the layers 1009 were closely coupled in the control plane. In such a deployment, as 1010 LSPs were automatically set up as the result of control plane 1011 requests from other layers (for example, triggered signaling), the 1012 management applications would need to register the creation of the 1013 new LSPs and the depletion of network resources. Emphasis would be 1014 placed on the layer boundary nodes to report the activity to the 1015 management applications. 1017 A more likely scenario is to apply a closer coupling of layer 1018 management systems with cross-layer management entities. This might 1019 be achieved through a unified management system capable of operating 1020 multiple layers, or by a meta-management system that coordinates the 1021 operation of separate management systems each responsible for 1022 individual layers. The former case might only be possible with the 1023 development of new management systems, while the latter is feasible 1024 through the coordination of existing network management tools. 1026 Note that when a layer boundary also forms an administrative boundary 1027 it is highly unlikely that there will be unified multi-layer 1028 management. In this case, the layers will be separately managed by 1029 the separate administrative entities, but there may be some "leakage" 1030 of information between the administrations in order to facilitate the 1031 operation of the MLN. For example, the management system in the lower 1032 layer network might automatically issue reports on resource 1033 availability (coincident with TE routing information), and alarm 1034 events. 1036 This discussion comes close to an examination of how a VNT might be 1037 managed and operated. As noted in Section 5.8, issues of how to 1038 design and manage a VNT are out of scope for this document, but it 1039 should be understood, that the VNT is a client layer construct built 1040 from server layer resources. This means that the operation of a VNT 1041 is a collaborative activity between layers. This activity is possible 1042 even if the layers are from separate administrations, but in this 1043 case the activity may also have commercial implications. 1045 MIB modules exist for the modeling and management of GMPLS networks 1046 [RFC4802], [RFC4803]. Some deployments of GMPLS networks may choose 1047 to use MIB modules to operate individual network layers. In these 1048 cases, operators may desire to coordinate layers through a further 1049 MIB module that could be developed. Multi-layer protocol solutions 1050 (that is solutions where a single control plane instance operates in 1051 more than one layer) SHOULD be manageable through MIB modules. A 1052 further MIB module to coordinate multiple network layers with this 1053 control plane MIB module may be produced. 1055 OAM tools are important to the successful deployment of all networks. 1057 OAM requirements for GMPLS networks are described in [GMPLS-OAM]. 1058 That document points out that protocol solutions for individual 1059 network layers should include mechanisms for OAM or to make use of 1060 OAM features inherent in the physical media of the layers. Further 1061 discussion of individual layer OAM is out of scope of this document. 1063 When operating OAM in a MLN, consideration must be given to how to 1064 provide OAM for end-to-end LSPs that cross domain boundaries and how 1065 to coordinate errors and alarms detected in a server layer that need 1066 to be reported to the client layer. These operational choices MUST be 1067 left open to the service provider and so MLN protocol solutions MUST 1068 include the following features: 1070 - Within the context and technology capabilities of the highest 1071 technology layer of an LSP (i.e., the technology layer of the first 1072 hop), it MUST be possible to enable end-to-end OAM on a MLN LSP. 1073 This function appears to the ingress LSP as normal LSP-based OAM 1074 [GMPLS-OAM], but at layer boundaries, depending on the technique 1075 used to span the lower layers, client layer OAM operations may need 1076 to mapped to server layer OAM operations. Most such requirements 1077 are highly dependent on the OAM facilities of the data plane 1078 technologies of client and server layers. However, control plane 1079 mechanisms used in the client layer per [GMPLS-OAM] MUST map and 1080 enable OAM in the server layer. 1082 - OAM operation enabled per [GMPLS-OAM] in a client layer for an LSP 1083 MUST operate for that LSP along its entire length. This means that 1084 if an LSP crosses a domain of a lower layer technology, the client 1085 layer OAM operation must operate seamlessly within the client layer 1086 at both ends of the client layer LSP. 1088 - OAM function operating within a server layer MUST be controllable 1089 from the client layer such that the server layer LSP(s) that 1090 support a client layer LSP have OAM enabled at the request of the 1091 client layer. Such control SHOULD be subject to policy at the layer 1092 boundary just as automatic provisioning and LSP requests to the 1093 server layer are subject to policy. 1095 - The status including errors and alarms applicable to a server layer 1096 LSP MUST be available to the client layer. This information SHOULD 1097 be configurable to be automatically notified to the client layer at 1098 the layer boundary and SHOULD be subject to policy so that the 1099 server layer may filter or hide information supplied to the client 1100 layer. Furthermore, the client layer SHOULD be able to select to 1101 not receive any or all such information. 1103 Note that the interface between layers lies within network nodes and 1104 is, therefore, not necessarily the subject of a protocol 1105 specification. Implementations MAY use standardized techniques (such 1106 as MIB modules) to convey status information (such as errors and 1107 alarms) between layers, but that is out of scope for this document. 1109 6. Security Considerations 1111 The MLN/MRN architecture does not introduce any new security 1112 requirements over the general GMPLS architecture described in 1113 [RFC3945]. Additional security considerations form MPLS and GMPLS 1114 networks are described in [MPLS-SEC]. 1116 However, where the separate layers of a MLN/MRN network are 1117 operated as different administrative domains, additional security 1118 considerations may be given to the mechanisms for allowing inter- 1119 layer LSP setup, for triggering lower-layer LSPs, or for VNT 1120 management. Similarly, consideration may be given to the amount of 1121 information shared between administrative domains, and the trade- 1122 off between multi-layer TE and confidentiality of information 1123 belonging to each administrative domain. 1125 It is expected that solution documents will include a full analysis 1126 of the security issues that any protocol extensions introduce. 1128 7. IANA Considerations 1130 This informational document makes no requests to IANA for action. 1132 8. Acknowledgements 1134 The authors would like to thank Adrian Farrel and the participants 1135 of ITU-T Study Group 15 Question 14 for their careful review. The 1136 authors would like to thank the IESG review team for rigorous review: 1137 special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu, 1138 and Dave Ward. 1140 9. References 1142 9.1. Normative Reference 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, March 1997. 1147 [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label 1148 Switching (GMPLS) Architecture", RFC 3945, October 2004. 1150 [RFC4202] Kompella, K., and Rekhter, Y., "Routing Extensions in 1151 Support of Generalized Multi-Protocol Label Switching 1152 (GMPLS)," RFC4202, October 2005. 1154 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths 1155 (LSP) Hierarchy with Generalized Multi-Protocol Label 1156 Switching (GMPLS) Traffic Engineering (TE)," RFC4206, 1157 Oct. 2005. 1159 [RFC4397] Bryskin, I., and Farrel, A., "A Lexicography for the 1160 Interpretation of Generalized Multiprotocol Label 1161 Switching (GMPLS) Terminology within the Context of the 1162 ITU-T's Automatically Switched Optical Network (ASON) 1163 Architecture", RFC 4397, February 2006. 1165 [RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A 1166 Framework for Inter-Domain Multiprotocol Label 1167 Switching Traffic Engineering", RFC 4726, November 2006. 1169 9.2. Informative References 1171 [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. 1172 and Ali, Z., "Procedures for Dynamically Signaled 1173 Hierarchical Label Switched Paths", draft-ietf-ccamp- 1174 lsp-hierarchy-bis, work in progress. 1176 [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, 1177 D., Shiomoto, K., Vigoureux, M., "Evaluation of 1178 Existing GMPLS Protocols Against Multi-Layer and 1179 Multi-Region Network (MLN/MRN) Requirements", draft- 1180 ietf-ccamp-gmpls-mln-eval, work in progress. 1182 [RFC5146] K. Kumaki (Editor), "Interworking Requirements to 1183 Support Operation of MPLS-TE over GMPLS Networks", 1184 RFC 5146, March 2008. 1186 [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and 1187 GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- 1188 security-framework, work in progress. 1190 [RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized 1191 Multiprotocol Label Switching (GMPLS) Traffic 1192 Engineering Management Information Base", RFC 4802, 1193 February 2007. 1195 [RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized 1196 Multiprotocol Label Switching (GMPLS) Label Switching 1197 Router (LSR) Management Information Base", RFC 4803, 1198 February 2007. 1200 [RFC4847] T. Takeda (Editor), " Framework and Requirements for 1201 Layer 1 Virtual Private Networks", RFC 4847, April 2007. 1203 [RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing 1204 Extensions for Discovery of Multiprotocol (MPLS) 1205 Label Switch Router (LSR) Traffic Engineering (TE) 1206 Mesh Membership", RFC 4972, July 2007. 1208 [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and Farrel, A., "OAM 1209 Requirements for Generalized Multi-Protocol Label 1210 Switching (GMPLS) Networks", draft-ietf-ccamp-gmpls-oam- 1211 requirements, work in progress. 1213 10. Authors' Addresses 1215 Kohei Shiomoto 1216 NTT Network Service Systems Laboratories 1217 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan 1218 Email: shiomoto.kohei@lab.ntt.co.jp 1220 Dimitri Papadimitriou 1221 Alcatel-Lucent 1222 Copernicuslaan 50, 1223 B-2018 Antwerpen, Belgium 1224 Phone : +32 3 240 8491 1225 Email: dimitri.papadimitriou@alcatel-lucent.be 1227 Jean-Louis Le Roux 1228 France Telecom R&D, 1229 Av Pierre Marzin, 1230 22300 Lannion, France 1231 Email: jeanlouis.leroux@orange-ft.com 1233 Martin Vigoureux 1234 Alcatel-Lucent 1235 Route de Nozay, 91461 Marcoussis cedex, France 1236 Phone: +33 (0)1 69 63 18 52 1237 Email: martin.vigoureux@alcatel-lucent.fr 1239 Deborah Brungard 1240 AT&T 1241 Rm. D1-3C22 - 200 1242 S. Laurel Ave., Middletown, NJ 07748, USA 1243 Phone: +1 732 420 1573 1244 Email: dbrungard@att.com 1246 11. Contributors' Addresses 1248 Eiji Oki 1249 NTT Network Service Systems Laboratories 1250 3-9-11 Midori-cho, Musashino-shi, 1251 Tokyo 180-8585, 1252 Japan 1253 Phone: +81 422 59 3441 1254 Email: oki.eiji@lab.ntt.co.jp 1256 Ichiro Inoue 1257 NTT Network Service Systems Laboratories 1258 3-9-11 Midori-cho, 1259 Musashino-shi, 1260 Tokyo 180-8585, 1261 Japan 1262 Phone: +81 422 59 3441 1263 Email: ichiro.inoue@lab.ntt.co.jp 1265 Emmanuel Dotaro 1266 Alcatel-Lucent 1267 Route de Nozay, 1268 91461 Marcoussis cedex, 1269 France 1270 Phone : +33 1 6963 4723 1271 Email: emmanuel.dotaro@alcatel-lucent.fr 1273 12. Intellectual Property Considerations 1275 The IETF takes no position regarding the validity or scope of any 1276 Intellectual Property Rights or other rights that might be claimed 1277 to pertain to the implementation or use of the technology described 1278 in this document or the extent to which any license under such 1279 rights might or might not be available; nor does it represent that 1280 it has made any independent effort to identify any such rights. 1281 Information on the procedures with respect to rights in RFC 1282 documents can be found in BCP 78 and BCP 79. 1284 Copies of IPR disclosures made to the IETF Secretariat and any 1285 assurances of licenses to be made available, or the result of an 1286 attempt made to obtain a general license or permission for the use 1287 of such proprietary rights by implementers or users of this 1288 specification can be obtained from the IETF on-line IPR repository 1289 at http://www.ietf.org/ipr. 1291 The IETF invites any interested party to bring to its attention any 1292 copyrights, patents or patent applications, or other proprietary 1293 rights that may cover technology that may be required to implement 1294 this standard. Please address the information to the IETF at ietf- 1295 ipr@ietf.org. 1297 13. Full Copyright Statement 1299 Copyright (C) The IETF Trust (2008). 1301 This document is subject to the rights, licenses and restrictions 1302 contained in BCP 78, and except as set forth therein, the authors 1303 retain all their rights. 1305 This document and the information contained herein are provided on 1306 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1307 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1308 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1309 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1310 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1311 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1312 FOR A PARTICULAR PURPOSE.