idnits 2.17.1 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.3 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 969. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 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 == Line 460 has weird spacing: '...tically using...' == Line 851 has weird spacing: '...ensions in...' -- 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 6768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GMPLS-RTG' is mentioned on line 133, but not defined == Missing Reference: 'RFC2119' is mentioned on line 198, but not defined == Unused Reference: 'RFC3979' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'STITCH' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'LMP' is defined on line 869, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-inter-domain-framework (ref. 'Inter-domain') -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LMP' -- No information found for draft-shiomoto-multiarea-te - is the name correct? == Outdated reference: A later version (-01) exists of draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kohei Shiomoto (NTT) 2 Internet Draft Dimitri Papadimitriou (Alcatel) 3 Jean-Louis Le Roux (France Telecom) 4 Martin Vigoureux (Alcatel) 5 Deborah Brungard (AT&T) 7 Expires: April 2006 October 2005 9 Requirements for GMPLS-based multi-region and 10 multi-layer networks (MRN/MLN) 12 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 This document may only be posted in an Internet-Draft. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on April . 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 Most of the initial efforts on Generalized MPLS (GMPLS) have been 49 related to environments hosting devices with a single switching 50 capability. The complexity raised by the control of such data 51 planes is similar to that seen in classical IP/MPLS networks. 53 By extending MPLS to support multiple switching technologies, GMPLS 54 provides a comprehensive framework for the control of a multi- 55 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 57 layered network of either a single switching technology or multiple 58 switching technologies. In GMPLS, a switching technology domain 59 defines a region, and a network of multiple switching types is 60 referenced in this document as a multi-region network (MRN). When 61 referring in general to a layered network, which may consist of 62 either a single or multiple regions, this document uses the term, 63 Multi-layer Network (MLN). This draft defines a framework for GMPLS 64 based multi-region/multi-layer networks and lists a set of 65 functional requirements. 67 Table of Contents 69 1. Introduction...................................................2 70 2. Conventions used in this document..............................4 71 3. Positioning....................................................4 72 3.1. Data plane layers and control plane regions..................5 73 3.2. Services.....................................................5 74 3.3. Vertical and Horizontal interaction and integration..........6 75 4. Key concepts of GMPLS-based MLNs and MRNs......................6 76 4.1. Interface Switching Capability...............................7 77 4.2. Multiple Interface Switching Capabilities....................7 78 4.2.1. Networks with multi-switching capable hybrid nodes.........8 79 4.3. Integrated Traffic Engineering (TE) and Resource Control.....9 80 4.3.1. Triggered signaling........................................9 81 4.3.2. FA-LSP....................................................10 82 4.3.3. Virtual network topology (VNT)............................10 83 5. Service networks provided over MRN/MLN........................11 84 6. Requirements..................................................11 85 6.1. Scalability.................................................11 86 6.2. LSP resource utilization....................................12 87 6.2.1. FA-LSP release and setup..................................12 88 6.2.2. Virtual TE-Link...........................................12 89 6.3. LSP Attribute inheritance...................................14 90 6.4. Verification of the LSP.....................................14 91 6.5. Disruption minimization.....................................14 92 6.6. Stability...................................................14 93 6.7. Computing paths with and without nested signaling...........15 94 6.8. Handling single-switching and multi-switching type capable 95 nodes............................................................16 96 6.9. Advertisement of the available adaptation resource..........16 97 7. Security Considerations.......................................17 98 8. References....................................................17 99 8.1. Normative Reference.........................................17 100 8.2. Informative References......................................18 101 9. Author's Addresses............................................18 102 10. Intellectual Property Considerations.........................19 103 11. Full Copyright Statement.....................................20 105 1. Introduction 106 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 108 Generalized MPLS (GMPLS) extends MPLS to handle multiple switching 109 technologies: packet switching, layer-two switching, TDM switching, 110 wavelength switching, and fiber switching (see [RFC3945]). The 111 Interface Switching Capability (ISC) concept is introduced for 112 these switching technologies and is designated as follows: PSC 113 (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time 114 Division Multiplex capable), LSC (lambda switch capable), and FSC 115 (fiber switch capable). 117 Service providers may operate networks where multiple different 118 switching technologies exist. The representation, in a GMPLS 119 control plane, of a switching technology domain is referred to as a 120 region [HIER]. 122 A switching type describes the ability of a node to forward data of 123 a particular data plane technology, and uniquely identifies a 124 network region. A layer describes a data plane switching 125 granularity level (e.g. VC4, VC-12). A data plane layer is 126 associated with a region in the control plane (e.g. VC4 associated 127 to TDM, IP associated to PSC). However, more than one data plane 128 layer can be associated to the same region (e.g. both VC4 and VC12 129 are associated to TDM). Thus, a control plane region, identified by 130 its switching type value (e.g. TDM), can itself be sub-divided into 131 smaller granularity based on the bandwidth that defines the "data 132 plane switching layers" e.g. from VC-11 to VC4-256c. The Interface 133 Switching Capability Descriptor (ISCD) [GMPLS-RTG], identifying the 134 interface switching type, the encoding type and the switching 135 bandwidth granularity, enable the characterization of the 136 associated layers. 138 A network comprising transport nodes with multiple data plane 139 layers of either the same ISC or different ISCs, controlled by a 140 single GMPLS control plane instance, is called a Multi-Layer 141 Network (MLN). To differentiate a network supporting LSPs of 142 different switching technologies (ISCs) from a single region 143 network, a network supporting more than one switching technology is 144 called a Multi-Region Network (MRN). 146 MRNs can be categorized according to the distribution of the 147 switching type values amongst the LSRs: 148 - Network elements are single switching capable LSRs and 149 different types of LSRs form the network. 150 - Network elements are multi-switching capable LSRs i.e. nodes 151 hosting at least more than one switching capability. Multi- 152 switching capable LSRs are further 153 classified as "simplex" and "hybrid" nodes (see Section 4.2). 154 - Any combination of the above two elements. A network composed 155 of both single and multi-switching capable LSRs. 157 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 159 Since GMPLS provides a comprehensive framework for the control of 160 different switching capabilities, a single GMPLS instance may be 161 used to control the MRNs/MLNs enabling rapid service provisioning 162 and efficient traffic engineering across all switching capabilities. 163 In such networks, TE Links are consolidated into a single Traffic 164 Engineering Database (TED). Since this TED contains the information 165 relative to all the different regions/layers existing in the 166 network, a path across multiple regions/layers can be computed 167 using this TED. Thus optimization of network resources can be 168 achieved across multiple regions/layers. 170 Consider, for example, a MRN consisting of IP/MPLS routers and TDM 171 cross-connects. Assume that a packet LSP is routed between source 172 and destination IP/MPLS routers, and that the LSP can be routed 173 across the PSC-region (i.e. utilizing only resources of the IP/MPLS 174 level topology). If the performance objective for the LSP is not 175 satisfied, new TE links may be created between the IP/MPLS routers 176 across the TDM-region (for example, VC-12 links) and the LSP can be 177 routed over those links. Further, even if the LSP can be 178 successfully established across the PSC-region, TDM hierarchical 179 LSPs across the TDM region between the IP/MPLS routers may be 180 established and used if doing so enables meeting an operator's 181 objectives on network resources available (e.g. link bandwidth, and 182 adaptation port between regions) across the multiple regions. The 183 same considerations hold when VC4 LSPs are provisioned to provide 184 extra flexibility for the VC12 and/or VC11 layers in a MLN. 186 This document describes the requirements to support multi- 187 region/multi-layer networks. There is no intention to specify 188 solution specific elements in this document. The applicability of 189 existing GMPLS protocols and any protocol extensions to the MRN/MLN 190 will be addressed in separate documents [MRN-EVAL]. 192 2. Conventions used in this document 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 196 this document are to be interpreted as described in RFC 2119 197 [RFC2119]. 199 3. Positioning 201 A multi-region network (MRN) is always a multi-layer network (MLN) 202 since the network devices on region boundaries bring together 203 different ISCs. A MLN, however, is not necessarily a MRN since 204 multiple layers could be fully contained within a single region. 205 For example, VC12, VC4, and VC4-4c are different layers of the TDM 206 region. 208 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 210 3.1. Data plane layers and control plane regions 212 A data plane layer is a collection of network resources capable of 213 terminating and/or switching data traffic of a particular format. 214 These resources can be used for establishing LSPs or connectionless 215 traffic delivery. For example, VC-11 and VC4-64c represent two 216 different layers. 218 From the control plane viewpoint, an LSP region is defined as a set 219 of one or several data plane layers that share the same type of 220 switching technology, that is, the same switching type. The 221 currently defined regions are: PSC, L2SC, TDM, LSC, and FSC regions. 222 Hence, an LSP region is a technology domain (identified by the ISC 223 type) for which data plane resources (i.e. data links) are 224 represented into the control plane as an aggregate of TE 225 information associated with a set of links (i.e. TE links). For 226 example VC-11 and VC4-64c capable TE links are part of the same TDM 227 region. Multiple layers can thus exist in a single region network. 229 Note also that the region is a control plane only concept. That is, 230 layers of the same region share the same switching technology and, 231 therefore, need the same set of technology specific signaling 232 objects. 234 3.2. Services 236 A service provider's network may be divided into different service 237 layers. The customer's network is considered from the provider's 238 perspective as the highest service layer. It interfaces to the 239 highest service layer of the service provider's network. 240 Connectivity across the highest service layer of the service 241 provider's network may be provided with support from successively 242 lower service layers. Service layers are realized via a hierarchy 243 of network layers located generally in several regions and commonly 244 arranged according to the switching capabilities of network devices. 246 For instance some customers purchase Layer 1 (i.e. transport) 247 services from the service provider, some Layer 2 (e.g. ATM), while 248 others purchase Layer 3 (IP/MPLS) services. The service provider 249 realizes the services by a stack of network layers located within 250 one or more network regions. The network layers are commonly 251 arranged according to the switching capabilities of the devices in 252 the networks. Thus, a customer network may be provided on top of 253 the GMPLS-based multi-region/multi-layer network. For example, a 254 Layer One service (realized via the network layers of TDM, and/or 255 LSC, and/or FSC regions) may support a Layer Two network (realized 256 via ATM VP/VC) which may itself support a Layer Three network 257 (IP/MPLS region). The supported data plane relationship is a data- 258 plane client-server relationship where the lower layer provides a 259 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 261 service for the higher layer using the data links realized in the 262 lower layer. 264 Services provided by a GMPLS-based multi-region/multi-layer network 265 are referred to as "Multi-region/Multi-layer network services". For 266 example legacy IP and IP/MPLS networks can be supported on top of 267 multi-region/multi-layer networks. It has to be emphasized that 268 delivery of such diverse services is a strong motivator for the 269 deployment of multi-region/multi-layer networks. 271 3.3. Vertical and Horizontal interaction and integration 273 Vertical interaction is defined as the collaborative mechanisms 274 within a network element that is capable of supporting more than 275 one switching capability and of realizing the client/server 276 relationships between them. Protocol exchanges between two network 277 controllers managing different regions are also a vertical 278 interaction. Integration of these interactions as part of the 279 control plane is referred to as vertical integration. The latter 280 refers thus to the collaborative mechanisms within a single control 281 plane instance driving multiple switching capabilities. Such a 282 concept is useful in order to construct a framework that 283 facilitates efficient network resource usage and rapid service 284 provisioning in carrier's networks that are based on multiple 285 switching technologies. 287 In a strict sense, horizontal interaction is defined as the 288 protocol exchange between network controllers that manage transport 289 nodes within a given region (i.e. nodes with the same switching 290 capability). For instance, the control plane interaction between 291 two LSC network elements is an example of horizontal interaction. 292 GMPLS protocol operations handle horizontal interactions within the 293 same routing area. The case where the interaction takes place 294 across a domain boundary, such as between two routing areas within 295 the same network layer, is currently being evaluated as part of the 296 inter-domain work [Inter-domain], and is referred to as horizontal 297 integration. Thus horizontal integration refers to the 298 collaborative mechanisms between network partitions and/or 299 administrative divisions such as routing areas or autonomous 300 systems. This distinction gets blurred when administrative domains 301 match layer boundaries. Horizontal interaction is extended to cover 302 such case. For example, the collaborative mechanisms in place 303 between two lambda switching capable areas relate to horizontal 304 integration. On the other hand, the collaborative mechanisms in 305 place in a network that supports IP/MPLS over TDM switching could 306 be described as vertical and horizontal integration in the case 307 where each network belongs to a separate area. 309 4. Key concepts of GMPLS-based MLNs and MRNs 310 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 312 A network comprising transport nodes with multiple data plane 313 layers of either the same ISC or different ISCs, controlled by a 314 single GMPLS control plane instance, is called a Multi-Layer 315 Network (MLN). A sub-set of MLNs consists of networks supporting 316 LSPs of different switching technologies (ISCs). A network 317 supporting more than one switching technology is called a Multi- 318 Region Network (MRN). 320 4.1. Interface Switching Capability 322 The Interface Switching Capability (ISC) is introduced in GMPLS to 323 support various kinds of switching technology in a unified way 324 [GMPLS-ROUTING]. An ISC is identified via a switching type. 326 A switching type (also referred to as the switching capability 327 types) describes the ability of a node to forward data of a 328 particular data plane technology, and uniquely identifies a network 329 region. The following ISC types (and, hence, regions) are defined: 330 PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more 331 precisely, each interface connecting a data link to a node) in a 332 GMPLS network is associated with an ISC. 334 The ISC value is advertised as a part of the Interface Switching 335 Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end 336 associated with a particular link interface. Apart from the ISC, 337 the ISCD contains information, such as the encoding type, the 338 bandwidth granularity, and the unreserved bandwidth on each of 339 eight priorities at which LSPs can be established. The ISCD does 340 not "identify" network layers, it uniquely characterizes 341 information associated to one or more network layers. 343 TE link end advertisements may contain multiple ISCDs. This can be 344 interpreted as advertising a multi-layer (or multi-switching) TE 345 link end. 347 4.2. Multiple Interface Switching Capabilities 349 In a MLN, network elements may be single-switching or multi- 350 switching type capable nodes. Single-switching type capable nodes 351 advertise the same ISC value as part of their ISCD sub-TLV(s) to 352 describe the termination capabilities of their TE Link(s). This 353 case is described in [GMPLS-ROUTING]. 355 Multi-switching capable LSRs are classified as "simplex" and 356 "hybrid" nodes. Simplex and Hybrid nodes are categorized according 357 to the way they advertise these multiple ISCs: 359 - A simplex node can terminate links with different switching 360 capabilities each of them connected to the node by a single link 361 interface. So, it advertises several TE Links each with a single 362 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 364 ISC value as part of its ISCD sub-TLVs. For example, an LSR with 365 PSC and TDM links each of which is connected to the LSR via single 366 interface. 368 - A hybrid node can terminate links with different switching 369 capabilities terminating on the same interface. So, it advertises 370 at least one TE Link containing more than one ISCDs with different 371 ISC values. For example, a node comprising of PSC and TDM links, 372 which are interconnected via internal links. The external 373 interfaces connected to the node have both PSC and TDM capability. 375 Additionally TE link advertisements issued by a simplex or a hybrid 376 node may need to provide information about the node's internal 377 adaptation capabilities between the switching technologies 378 supported. That is, the node's capability to perform layer border 379 node functions. 381 4.2.1. Networks with multi-switching capable hybrid nodes 383 The network contains at least one hybrid node, zero or more simplex 384 nodes, and a set of single switching capable nodes. 386 Figure 5a shows an example hybrid node. The hybrid node has two 387 switching elements (matrices), which support, for instance, TDM and 388 PSC switching respectively. The node terminates two PSC and TDM 389 links (Link1 and Link2 respectively). It also has internal link 390 connecting the two swtching elements. 392 The two switching elements are internally interconnected in such a 393 way that it is possible to terminate some of the resources of, say, 394 Link2 and provide through them adaptation for PSC traffic 395 received/sent over the PSC interface (#b). This situation is 396 modeled in GMPLS by connecting the local end of Link2 to the TDM 397 switching element via an additional interface realizing the 398 termination/adaptation function. Two ways are possible to set up 399 PSC LSPs. Available resource advertisement e.g. Unreserved and 400 Min/Max LSP Bandwidth should cover both two ways. 402 Network element 403 ............................. 404 : -------- : 405 : | PSC | : 406 Link1 -------------<->--|#a | : 407 : +--<->---|#b | : 408 : | -------- : 409 TDM : | ---------- : 410 +PSC : +--<->--|#c TDM | : 411 Link2 ------------<->--|#d | : 412 : ---------- : 414 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 416 :............................ 418 Figure 5a. Hybrid node. 420 4.3. Integrated Traffic Engineering (TE) and Resource Control 422 In GMPLS-based multi-region/multi-layer networks, TE Links are 423 consolidated into a single Traffic Engineering Database (TED). 424 Since this TED contains the information relative to all the layers 425 of all regions in the network, a path across multiple layers 426 (possibly crossing multiple regions) can be computed using the 427 information in this TED. Thus optimization of network resources 428 across the multiple layers of the same region and multiple regions 429 can be achieved. 431 These concepts allow for the operation of one network layer over 432 the topology (that is, TE links) provided by other network layer(s) 433 (for example, the use of a lower layer LSC LSP carrying PSC LSPs). 434 In turn, a greater degree of control and inter-working can be 435 achieved, including (but not limited too): 436 - dynamic establishment of Forwarding Adjacency LSPs (see Section 437 4.3.3) 438 - provisioning of end-to-end LSPs with dynamic triggering of FA 439 LSPs 441 Note that in a multi-layer/multi-region network that includes 442 multi-switching type capable nodes, an explicit route used to 443 establish an end-to-end LSP can specify nodes that belong to 444 different layers or regions. In this case, a mechanism to control 445 the dynamic creation of FA LSPs may be required. 447 There is a full spectrum of options to control how FA LSPs are 448 dynamically established. It can be subject to the control of a 449 policy, which may be set by a management component, and which may 450 require that the management plane is consulted at the time that the 451 FA LSP is established. Alternatively, the FA LSP can be established 452 at the request of the control plane without any management control. 454 4.3.1. Triggered signaling 456 When an LSP crosses the boundary from an upper to a lower layer, it 457 may be nested into a lower layer FA LSP that crosses the lower 458 layer. From signaling perspective, there are two alternatives to 459 establish lower layer FA LSP: static and dynamic. Decision will be 460 made either by the operator or automatically using features like 461 TE auto-mesh, for instance. If such a lower layer LSP does not 462 already exist, the LSP may be established dynamically. Such a 463 mechanism is referred to as "triggered signaling". 465 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 467 4.3.2. FA-LSP 469 Once an LSP is created across a layer, it can be used as a data 470 link in an upper layer. 472 Furthermore, it can be advertised as a TE-link, allowing other 473 nodes to consider the LSP as a TE link for their path computation 474 [HIER]. An LSP created either statically or dynamically by one 475 instance of the control plane and advertised as a TE link into the 476 same instance of the control plane is called a FA-LSP. The TE-link 477 associated to an FA-LSP is called an FA. An FA has the special 478 characteristic of not requiring a routing adjacency (peering) 479 between its ends yet still guaranteeing control plane connectivity 480 between the FA-LSP ends based on a signaling adjacency. A FA is a 481 useful and powerful tool for improving the scalability of GMPLS 482 Traffic Engineering (TE) capable networks. 484 The aggregation of LSPs enables the creation of a vertical (nested) 485 LSP Hierarchy. A set of FA-LSPs across or within a lower layer can 486 be used during path selection by a higher layer LSP. Likewise, the 487 higher layer LSPs may be carried over dynamic data links realized 488 via LSPs (just as they are carried over any "regular" static data 489 links). This process requires the nesting of LSPs through a 490 hierarchical process [HIER]. The TED contains a set of LSP 491 advertisements from different layers that are identified by the 492 ISCD contained within the TE link advertisement associated with the 493 LSP [GMPLS-ROUTING]. 495 4.3.3. Virtual network topology (VNT) 497 A set of one or more of lower-layer LSPs provides information for 498 efficient path handling in upper-layer(s) of the MLN, or, in other 499 words, provides a virtual network topology to the upper-layers. For 500 instance, a set of LSPs, each of which is supported by an LSC LSP, 501 provides a virtual network topology to the layers of a PSC region, 502 assuming that the PSC region is connected to the LSC region. Note 503 that a single lower-layer LSP is a special case of VNT. The virtual 504 network topology is configured by setting up or tearing down the 505 LSC LSPs. By using GMPLS signaling and routing protocols, the 506 virtual network topology can be adapted to traffic demands. 508 Reconfiguration of the virtual network topology may be triggered by 509 traffic demand change, topology configuration change, signaling 510 request from the upper layer, and network failure. For instance, by 511 reconfiguring the virtual network topology according to the traffic 512 demand between source and destination node pairs, network 513 performance factors, such as maximum link utilization and residual 514 capacity of the network, can be optimized [MAMLTE]. Reconfiguration 515 is performed by computing the new VNT from the traffic demand 516 matrix and optionally from the current VNT. Exact details are 517 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 519 outside the scope of this document. However, this method may be 520 tailored according to the Service Provider's policy regarding 521 network performance and quality of service (delay, loss/disruption, 522 utilization, residual capacity, reliability). 524 5. Service networks provided over MRN/MLN 526 A customer network may be provided on top of a server MRN/MLN 527 network (such as a transport network) which is operated by a 528 service provider. For example legacy IP or IP/MPLS networks can be 529 provided on top of GMPLS packet or optical networks [IW-MIG-FW]. 530 The relationship between the networks is a client/server 531 relationship and, such services are referred to as "MRN/MLN 532 services". 534 The customer network may be provided either as part of the MRN/MLN 535 or in a separate network instance distinct from the MRN/MLN. There 536 could also be an administrative boundary between the customer 537 network and the MRN/MLN operated by the service provider. All 538 requirements described in this document SHOULD be applicable if 539 there is an administrative boundary between the customer network 540 and the MRN/MLN operated by service provider. 542 Impact on the customer network design, operation, and 543 administration SHOULD be minimized. For instance, the design for 544 address assignment and IGP area division should be kept independent 545 from the underlying MRN/MLN. 547 The MRN/MLN SHOULD provide mechanisms to allow an administrative 548 boundary between the customer network and the MRN/MLN. 550 6. Requirements 552 6.1. Scalability 554 The MRN/MLN relies on a unified traffic engineering and routing 555 model. The TED in each LSR is populated with TE-links from all 556 layers of all regions. This may lead to a huge amount of 557 information that has to be flooded and stored within the network. 558 Furthermore, path computation times, which may be of great 559 importance during restoration, will depend on the size of the TED. 561 Thus MRN/MLN routing mechanisms MUST be designed to scale well with 562 an increase of any of the following: 563 - Number of nodes 564 - Number of TE-links (including FA-LSPs) 565 - Number of LSPs 566 - Number of regions and layers 567 - Number of ISCDs per TE-link. 569 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 571 6.2. LSP resource utilization 573 It MUST be possible to utilize network resources efficiently. 574 Particularly, resource usage in all layers SHOULD be optimized as a 575 whole (i.e. across all layers), in a coordinated manner, (ie taking 576 all layers into account). The number of lower-layer LSPs carrying 577 upper-layer LSPs SHOULD be minimized as much as possible (Note that 578 multiple LSPs may be used for load balance) . Unneccesary lower- 579 layer LSPs SHOULD be avoided. 581 6.2.1. FA-LSP release and setup 583 Statistical multiplexing can only be employed in PSC and L2SC 584 regions. A PSC or L2SC LSP may or may not consume the maximum 585 reservable bandwidth of the FA LSP that carries it. On the other 586 hand, a TDM, or LSC LSP always consumes a fixed amount of bandwidth 587 as long as it exists (and is fully instantiated) because 588 statistical multiplexing is not available. 590 If there is low traffic demand, some FA LSPs, which do not carry 591 any LSP may be released so that resources are released. Note that 592 if a small fraction of the available bandwidth is still under use, 593 the nested LSPs can also be re-routed optionally using the make- 594 before-break technique. Alternatively, the FA LSPs may be retained 595 for future usage. Release or retention of underutilized FA LSPs is 596 a policy decision. 598 As part of the re-optimization process, the solution MUST allow 599 rerouting of FA LSPs while keeping interface identifiers of 600 corresponding TE links unchanged. 602 Additional FA LSPs MAY also be created based on policy, which might 603 consider residual resources and the change of traffic demand across 604 the region. By creating the new FA LSPs, the network performance 605 such as maximum residual capacity may increase. 607 As the number of FA LSPs grows, the residual resource may decrease. 608 In this case, re-optimization of FA LSPs MAY be invoked according 609 the policy. 611 Any solution MUST include measures to protect against network 612 destabilization caused by the rapid set up and tear down of LSPs as 613 traffic demand varies near a threshold. 615 6.2.2. Virtual TE-Link 617 It may be considered disadvantageous to fully instantiate (i.e. 618 pre-provision) the set of lower layer LSPs since this may reserve 619 bandwidth that could be used for other LSPs in the absence of the 620 upper-layer traffic. 622 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 624 However, in order to provision upper-layer LSPs across the lower- 625 layer, the LSPs MAY still be advertised into the upper-layer as 626 though they had been fully established. Such TE links that 627 represent the possibility of an underlying LSP are termed "virtual 628 TE-link". Note that this is not a mandatory (MUST) requirement 629 since even if there are no LSPs advertised to the higher layer, it 630 is possible to route an upper layer LSP into a lower layer based on 631 the lower layer's TE-links and making assumptions that proper 632 hierarchical LSPs in the lower layer will be dynamically created as 633 needed. 635 If an upper-layer LSP that makes use of a virtual TE-Link is set up, 636 the underlying LSP MUST be immediately signaled in the lower layer 637 if it has not been established. 639 If virtual TE-Links are used in place of pre-established LSPs, the 640 TE links across the upper-layer can remain stable using pre- 641 computed paths while wastage of bandwidth within the lower-layer 642 and unnecessary reservation of adaptation ports at the border nodes 643 can be avoided. 645 The concept of VNT can be extended to allow the virtual TE-links to 646 form part of the VNT. The combination of the fully provisioned TE- 647 links and the virtual TE-links defines the VNT across the lower 648 layer. 650 The solution SHOULD provide operations to facilitate the build-up 651 of such virtual TE-links, taking into account the (forecast) 652 traffic demand and available resource in the lower-layer. 654 Virtual TE-links MAY be modified dynamically (by adding or removing 655 virtual TE links) according to the change of the (forecast) traffic 656 demand and the available resource in the lower-layer. 658 Any solution MUST include measures to protect against network 659 destabilization caused by the rapid changes in the virtual network 660 topology as traffic demand varies near a threshold. 662 The VNT can be changed by setting up and/or tearing down virtual TE 663 links as well as by modifying real links (i.e. the fully 664 provisioned LSPs). 666 The maximum number of virtual TE links that can be configured 667 SHOULD be well-engineered. 669 How to design the VNT and how to manage it are out of scope of this 670 document and will be treated in a companion document on solution. 672 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 674 6.3. LSP Attribute inheritance 676 TE-Link parameters SHOULD be inherited from the parameters of the 677 LSP that provides the TE link, and so from the TE links in the 678 lower layer that are traversed by the LSP. 679 These include: 680 - Interface Switching Capability 681 - TE metric 682 - Maximum LSP bandwidth per priority level 683 - Unreserved bandwidth for all priority levels 684 - Maximum Reservable bandwidth 685 - Protection attribute 686 - Minimum LSP bandwidth (depending on the Switching Capability) 688 Inheritance rules MUST be applied based on specific policies. 689 Particular attention should be given to the inheritance of TE 690 metric (which may be other than a strict sum of the metrics of the 691 component TE links at the lower layer) and protection attributes. 693 6.4. Verification of the LSP 695 When the LSP is created, it SHOULD be verified that it has been 696 established before it can be used by an upper layer LSP. Note, this 697 is not within the GMPLS capability scope for non-PSC interfaces. 699 6.5. Disruption minimization 701 When reconfiguring the VNT according to a change in traffic demand, 702 the upper-layer LSP might be disrupted. Such disruption MUST be 703 minimized. 705 When residual resource decreases to a certain level, some LSPs MAY 706 be released according to local or network policies. There is a 707 trade-off between minimizing the amount of resource reserved in the 708 lower layer LSPs and disrupting higher layer traffic (i.e. moving 709 the traffic to other TE-LSPs so that some LSPs can be released). 710 Such traffic disruption MAY be allowed but MUST be under the 711 control of policy that can be configured by the operator. Any 712 repositioning of traffic MUST be as non-disruptive as possible (for 713 example, using make-before-break). 715 6.6. Stability 717 The path computation is dependent on the network topology and 718 associated link state. The path computation stability of an upper 719 layer may be impaired if the VNT changes frequently and/or if the 720 status and TE parameters (TE metric for instance) of links in the 721 virtual network topology changes frequently. 723 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 725 In this context, robustness of the VNT is defined as the capability 726 to smooth changes that may occur and avoid their propagation into 727 higher layers. Changes of the VNT may be caused by the creation 728 and/or deletion of several LSPs. 730 Creation and deletion of LSPs MAY be triggered by adjacent layers 731 or through operational actions to meet traffic demand change, 732 topology change, signaling request from the upper layer, and 733 network failure. Routing robustness SHOULD be traded with 734 adaptability with respect to the change of incoming traffic 735 requests. 737 A full mesh of LSPs MAY be created between every pair of border 738 nodes of the PSC region. The merit of a full mesh of PSC TE-LSPs is 739 that it provides stability to the PSC-level routing. That is, the 740 forwarding table of an PSC-LSR is not impacted by re-routing 741 changes within the lower-layer (e.g., TDM layer). Further, there is 742 always full PSC reachability and immediate access to bandwidth to 743 support PSC LSPs. But it also has significant drawbacks, since it 744 requires the maintenance of n^2 RSVP-TE sessions, which may be 745 quite CPU and memory consuming (scalability impact). Also this may 746 lead to significant bandwidth wasting if LSP with a certain amount 747 of reserved bandwidth is used. 748 Note that the use of virtual TE-links solves the bandwidth wasting 749 issue, and may reduce the control plane overload. 751 6.7. Computing paths with and without nested signaling 753 Path computation MAY take into account LSP region and layer 754 boundaries when computing a path for an LSP. For example, path 755 computation MAY restrict the path taken by an LSP to only the links 756 whose interface switching capability is PSC. 758 Interface switching capability is used as a constraint in computing 759 the path. A TDM-LSP is routed over the topology composed of TE 760 links of the same TDM layer. In calculating the path for the LSP, 761 the TE database MAY be filtered to include only links where both 762 end include requested LSP switching type. In this way hierarchical 763 routing is done by using a TE database filtered with respect to 764 switching capability (that is, with respect to particular layer). 766 If triggered signaling is allowed, the path computation mechanism 767 MAY produce a route containing multiple layers/ regions. The path 768 is computed over the multiple layers/regions even if the path is 769 not "connected" in the same layer as the endpoints of the path 770 exist. Note that here we assume that triggered signaling will be 771 invoked to make the path "connected", when the upper-layer 772 signaling request arrives at the boundary node. 774 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 776 The upper-layer signaling request may contain a loose ERO, and the 777 boundary node is responsible for creation of the lower-layer FA-LSP. 778 When the boundary node receives the signaling setup request and 779 determines that it has to expand the loose ERO content by creating 780 the lower-layer FA-LSP, it will create the lower layer FA-LSP 781 accordingly. Once the lower-layer LSP is established, the ERO 782 contents for the upper-layer signaling setup request are expanded 783 to include the lower-layer FA-LSP and signaling setup for the 784 upper-layer LSP are carried in-band of the lower-layer LSP. 786 The upper-layer signaling request may contain a strict ERO 787 specifying the lower layer FA-LSP route. In this case, the boundary 788 node is responsible for decision as to which it should use the path 789 contained in the strict ERO or it should re-compute the path within 790 in the lower-layer. 792 Even in case the lower-layer FA-LSPs are already established, a 793 signaling request may also be encoded as loose ERO. In this 794 situation, it is up to the boundary node to decide whether it 795 should a new lower-layer FA-LSP or it should use the existing 796 lower-layer FA-LSPs. 798 We should note that the lower-layer FA-LSP can be advertised just 799 as an FA-LSP in the upper-layer or an IGP adjacency can be brought 800 up on the lower-layer FA-LSP. 802 6.8. Handling single-switching and multi-switching type capable 803 nodes 805 The MRN/MLN can consist of single-switching type capable and multi- 806 switching type capable nodes. The path computation mechanism in the 807 MLN SHOULD be able to compute paths consisting of any combination 808 of such nodes. 810 Both single switching capable and multi-switching (simplex or 811 hybrid) capable nodes could play the role of layer boundary. 812 MRN/MLN Path computation SHOULD handle TE topologies built of any 813 combination of single switching, simplex and hybrid nodes 815 6.9. Advertisement of the available adaptation resource 817 A hybrid node SHOULD maintain resources and advertise the resource 818 information on its internal links, the links required for vertical 819 (layer) integration. Likewise, path computation elements SHOULD be 820 prepared to use the availability of termination/adaptation 821 resources as a constraint in MRN/MLN path computations to reduce 822 the higher layer LSP setup blocking probability because of the lack 823 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 825 of necessary termination/ adaptation resources in the lower 826 layer(s). 828 The advertisement of the adaptation capability to terminate LSPs of 829 lower-region and forward traffic in the upper-region is REQUIRED, 830 as it provides critical information when performing multi-region 831 path computation. 833 The mechanism SHOULD cover the case where the upper-layer links 834 which are directly connected to upper-layer switching element and 835 the ones which are connected through internal links between upper- 836 layer element and lower-layer element coexist (See section 4.2.1). 838 7. Security Considerations 840 The current version of this document does not introduce any new 841 security considerations as it only lists a set of requirements. In 842 the future versions, new security requirements may be added. 844 8. References 846 8.1. Normative Reference 848 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 849 Technology", BCP 79, RFC 3979, March 2005. 851 [GMPLS-ROUTING] K.Kompella and Y.Rekhter, "Routing Extensions in 852 Support of Generalized Multi-Protocol Label 853 Switching," draft-ietf-ccamp-gmpls-routing-09.txt, 854 October 2003 (work in progress). 856 [Inter-domain] A.Farrel, J-P. Vasseur, and A.Ayyangar, "A 857 framework for inter-domain MPLS traffic 858 engineering," draft-ietf-ccamp-inter-domain- 859 framework, work in progress. 861 [HIER] K.Kompella and Y.Rekhter, "LSP hierarchy with 862 generalized MPLS TE," draft-ietf-mpls-lsp-hierarchy- 863 08.txt, work in progress, Sept. 2002. 865 [STITCH] Ayyangar, A. and Vasseur, JP., "Label Switched Path 866 Stitching with Generalized MPLS Traffic Engineering", 867 draft-ietf-ccamp-lsp-stitching, work in progress. 869 [LMP] J. Lang, "Link management protocol (LMP)," draft- ietf- 870 ccamp-lmp-10.txt (work in progress), October 2003. 872 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 874 [RFC3945] E.Mannie (Ed.), "Generalized Multi-Protocol Label 875 Switching (GMPLS) Architecture", RFC 3945, October 876 2004. 878 8.2. Informative References 880 [MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic 881 engineering using hierarchical LSPs in GMPLS 882 networks", draft-shiomoto-multiarea-te, work in 883 progress. 885 [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., 886 Shiomoto, K., Vigoureux, M.,"Evaluation of existing 887 GMPLS Protocols against Multi Layer and Multi Region 888 Networks (MLN/MRN)", draft-leroux-ccamp-gmpls-mrn- 889 eval, work in progress. 891 [IW-MIG-FW] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., 892 Brungard, D., Oki, E., Inoue, I., " Framework for 893 IP/MPLS-GMPLS interworking in support of IP/MPLS to 894 GMPLS migration ", draft-shiomoto-ccamp-mpls-gmpls- 895 interwork-fmwk-00.txt, work in progress. 897 9. Author's Addresses 899 Kohei Shiomoto 900 NTT Network Service Systems Laboratories 901 3-9-11 Midori-cho, 902 Musashino-shi, Tokyo 180-8585, Japan 903 Email: shiomoto.kohei@lab.ntt.co.jp 905 Dimitri Papadimitriou 906 Alcatel 907 Francis Wellensplein 1, 908 B-2018 Antwerpen, Belgium 909 Phone : +32 3 240 8491 910 Email: dimitri.papadimitriou@alcatel.be 912 Jean-Louis Le Roux 913 France Telecom R&D, 914 Av Pierre Marzin, 915 22300 Lannion, France 916 Email: jeanlouis.leroux@francetelecom.com 918 Martin Vigoureux 919 Alcatel 920 Route de Nozay, 91461 Marcoussis cedex, France 921 Phone: +33 (0)1 69 63 18 52 922 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 924 Email: martin.vigoureux@alcatel.fr 926 Deborah Brungard 927 AT&T 928 Rm. D1-3C22 - 200 929 S. Laurel Ave., Middletown, NJ 07748, USA 930 Phone: +1 732 420 1573 931 Email: dbrungard@att.com 933 Contributors 935 Eiji Oki (NTT Network Service Systems Laboratories) 936 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan 937 Phone: +81 422 59 3441 Email: oki.eiji@lab.ntt.co.jp 939 Ichiro Inoue (NTT Network Service Systems Laboratories) 940 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan 941 Phone: +81 422 59 3441 Email: ichiro.inoue@lab.ntt.co.jp 943 Emmanuel Dotaro (Alcatel) 944 Route de Nozay, 91461 Marcoussis cedex, France 945 Phone : +33 1 6963 4723 Email: emmanuel.dotaro@alcatel.fr 947 10. Intellectual Property Considerations 949 The IETF takes no position regarding the validity or scope of any 950 Intellectual Property Rights or other rights that might be claimed 951 to pertain to the implementation or use of the technology described 952 in this document or the extent to which any license under such 953 rights might or might not be available; nor does it represent that 954 it has made any independent effort to identify any such rights. 955 Information on the procedures with respect to rights in RFC 956 documents can be found in BCP 78 and BCP 79. 958 Copies of IPR disclosures made to the IETF Secretariat and any 959 assurances of licenses to be made available, or the result of an 960 attempt made to obtain a general license or permission for the use 961 of such proprietary rights by implementers or users of this 962 specification can be obtained from the IETF on-line IPR repository 963 at http://www.ietf.org/ipr. 965 The IETF invites any interested party to bring to its attention any 966 copyrights, patents or patent applications, or other proprietary 967 rights that may cover technology that may be required to implement 968 this standard. Please address the information to the IETF at ietf- 969 ipr@ietf.org. 971 The IETF has been notified by Tellabs Operations, Inc. of 972 intellectual property rights claimed in regard to some or all of 973 the specification contained in this document. For more information, 974 draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt October 2005 976 see http://www.ietf.org/ietf/IPR/tellabs-ipr-draft-shiomoto-ccamp- 977 gmpls-mrn-reqs.txt 979 11. Full Copyright Statement 981 Copyright (C) The Internet Society (2005). This document is subject 982 to the rights, licenses and restrictions contained in BCP 78, and 983 except as set forth therein, the authors retain all their rights. 985 This document and the information contained herein are provided on 986 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 987 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 988 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 989 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 990 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 991 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 992 PARTICULAR PURPOSE.