idnits 2.17.1 draft-ietf-ccamp-gmpls-mln-eval-06.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1066. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1079. 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 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 (July 2008) is 5757 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux (Ed.) 3 Internet Draft France Telecom 4 Category: Informational 5 Expires: January 2009 D. Papadimitriou (Ed.) 6 Alcatel-Lucent 8 July 2008 10 Evaluation of Existing GMPLS Protocols Against Multi Layer 11 and Multi Region Networks (MLN/MRN) 13 draft-ietf-ccamp-gmpls-mln-eval-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in 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 Abstract 39 This document provides an evaluation of Generalized Multi-Protocol 40 Label Switching (GMPLS) protocols and mechanisms against the 41 requirements for Multi-Layer Networks (MLN) and Multi-Region Networks 42 (MRN). In addition, this document identifies areas where additional 43 protocol extensions or procedures are needed to satisfy these 44 requirements, and provides guidelines for potential extensions. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC-2119. 52 Table of Contents 54 1. Introduction................................................3 55 2. MLN/MRN Requirements Overview...............................4 56 3. Analysis....................................................5 57 3.1. Multi Layer Network Aspects.................................5 58 3.1.1. Support for Virtual Network Topology Reconfiguration........5 59 3.1.1.1. Control of FA-LSPs Setup/Release..........................5 60 3.1.1.2. Virtual TE-Links..........................................6 61 3.1.1.3. Traffic Disruption Minimization During FA Release.........7 62 3.1.1.4. Stability.................................................8 63 3.1.2. Support for FA-LSP Attributes Inheritance...................8 64 3.1.3. FA-LSP Connectivity Verification............................8 65 3.1.4. Scalability.................................................9 66 3.1.5. Operations and Management of the MLN/MRN...................10 67 3.1.5.1. MIB Modules..............................................10 68 3.1.5.2. OAM......................................................10 69 3.2. Specific Aspects for Multi-Region Networks.................11 70 3.2.1. Support for Multi-Region Signaling.........................11 71 3.2.2. Advertisement of Adjustment Capacities.....................12 72 4. Evaluation Conclusion......................................15 73 4.1. Traceability of Requirements...............................15 74 5. Security Considerations....................................19 75 6. IANA Considerations........................................19 76 7. Acknowledgments............................................19 77 8. References.................................................19 78 8.1. Normative References.......................................19 79 8.2. Informative References.....................................20 80 9. Editors' Addresses.........................................21 81 10. Contributors' Addresses....................................22 82 11. Intellectual Property Statement............................22 84 1. Introduction 86 Generalized MPLS (GMPLS) extends MPLS to handle multiple switching 87 technologies: packet switching, layer-2 switching, TDM switching, 88 wavelength switching, and fiber switching (see [RFC3945]). The 89 Interface Switching Capability (ISC) concept is introduced for 90 these switching technologies and is designated as follows: PSC 91 (Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time 92 Division Multiplex capable), LSC (Lambda Switch Capable), and FSC 93 (Fiber Switch Capable). The representation, in a GMPLS control 94 plane, of a switching technology domain is referred to as a region 95 [RFC4206]. A switching type describes the ability of a node to 96 forward data of a particular data plane technology, and uniquely 97 identifies a network region. 99 A data plane switching layer describes a data plane switching 100 granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are 101 three different layers. [MLN-REQ] defines a Multi Layer Network 102 (MLN) to be a TE domain comprising multiple data plane switching 103 layers either of the same ISC (e.g. TDM) or different ISC (e.g. TDM 104 and PSC) and controlled by a single GMPLS control plane instance. 105 [MLN-REQ] further defines a particular case of MLNs. A Multi Region 106 Network (MRN) is defined as a TE domain supporting at least two 107 different switching types (e.g., PSC and TDM), either hosted on the 108 same device or on different ones, and under the control of a single 109 GMPLS control plane instance. 111 The objectives of this document are to evaluate existing GMPLS 112 mechanisms and protocols ([RFC3945], [RFC4202], [RFC3471], 113 [RFC3473]) against the requirements for MLN and MRN, defined in 114 [MLN-REQ]. From this evaluation, we identify several areas where 115 additional protocol extensions and modifications are required to meet 116 these requirements, and provide guidelines for potential extensions. 118 A summary of MLN/MRN requirements is provided in section 2. Then 119 section 3 evaluates for each of these requirements, whether current 120 GMPLS protocols and mechanisms meet the requirements. When the 121 requirements are not met by existing protocols, the document 122 identifies whether the required mechanisms could rely on GMPLS 123 protocols and procedure extensions or whether it is entirely out of 124 the scope of GMPLS protocols. 126 Note that this document specifically addresses GMPLS control plane 127 functionality for MLN/MRN in the context of a single administrative 128 control plane partition. Partitions of the control plane where 129 separate layers are under distinct administrative control are for 130 future study. 132 This document uses terminologies defined in [RFC3945], [RFC4206], and 133 [MLN-REQ]. 135 2. MLN/MRN Requirements Overview 137 Section 5 of [MLN-REQ] lists a set of functional requirements for 138 Multi Layer/Region Networks (MLN/MRN). These requirements are 139 summarized below, and a mapping with sub-sections of [MLN-REQ] is 140 provided. 142 Here is the list of requirements that apply to MLN (and thus to MRN): 144 - Support for robust Virtual Network Topology (VNT) reconfiguration. 145 This implies the following requirements: 147 - Optimal control of Forwarding Adjacency LSP (FA-LSP) setup and 148 release (Section 5.8.1 of [MLN-REQ]); 150 - Support for virtual TE-links (Section 5.8.2 of [MLN-REQ]); 152 - Traffic Disruption minimization during FA-LSP release (Section 153 5.5 of [MLN-REQ]); 155 - Stability (Section 5.4 of [MLN-REQ]); 157 - Support for FA-LSP attributes inheritance (Section 5.6 of 158 [MLN-REQ]); 160 - Support for FA-LSP data plane connectivity verification 161 (Section 5.9 of [MLN-REQ]); 163 - MLN Scalability (section 5.3 of [MLN-REQ]); 165 - MLN OAM (section 5.10 of [MLN-REQ]); 167 Here is the list of requirements that apply to MRN only: 169 - Support for Multi-Region signaling (section 5.7 of [MLN-REQ]); 171 - Advertisement of the adjustment capacity (section 5.2 of 172 [MLN-REQ]); 174 3. Analysis 176 3.1. Multi Layer Network Aspects 178 3.1.1. Support for Virtual Network Topology Reconfiguration 180 A set of lower-layer FA-LSPs provides a Virtual Network Topology 181 (VNT) to the upper-layer [MLN-REQ]. By reconfiguring the VNT (FA-LSP 182 setup/release) according to traffic demands between source and 183 destination node pairs within a layer, network performance factors 184 such as maximum link utilization and residual capacity of the network 185 can be optimized. Such optimal VNT reconfiguration implies several 186 mechanisms that are analyzed in the following sections. 188 Note that the VNT approach is just one possible approach to perform 189 inter-layer Traffic Engineering. 191 3.1.1.1. Control of FA-LSPs Setup/Release 193 In a Multi-Layer Network, FA-LSPs are created, modified, released 194 periodically according to the change of incoming traffic demands from 195 the upper layer. 197 This implies a TE mechanism that takes into account the demands 198 matrix, the TE topology and potentially the current VNT, in order to 199 compute and setup a new VNT. 201 Several functional building blocks are required to support such TE 202 mechanism: 204 - Discovery of TE topology and available resources. 206 - Collection of upper layer traffic demands. 208 - Policing and scheduling of VNT resources with regard to traffic 209 demands and usage (that is, decision to setup/release FA-LSPs). The 210 functional component in charge of this function is called a VNT 211 Manager (VNTM) [PCE-INTER]. 213 - VNT Paths Computation according to TE topology, and potentially 214 taking into account the old (existing) VNT to minimize changes. The 215 Functional component in charge of VNT computation may be 216 distributed on network elements or may be performed on an external 217 element (such as a Path Computation Element (PCE), [RFC4655]). 219 - FA-LSP setup/release. 221 GMPLS routing protocols provide TE topology discovery. 222 GMPLS signaling protocols allow setting up/releasing FA-LSPs. 224 VNTM functions (resources policing/scheduling, decision to 225 setup/release FA-LSPs, FA-LSP configuration) are out of the scope of 226 GMPLS protocols. Such functionalities can be achieved directly on 227 layer border LSRs, or through one or more external tools. When an 228 external tool is used, an interface is required between the VNTM and 229 the network elements so as to setup/release FA-LSPs. This could use 230 standard management interfaces such as [RFC4802]. 232 The set of traffic demands of the upper layer is required for the 233 VNT Manager to take decisions to setup/release FA-LSPs. Such 234 traffic demands include satisfied demands, for which one or more 235 upper layer LSP have been successfully setup, as well as unsatisfied 236 demands and future demands, for which no upper layer LSP has been 237 setup yet. The collection of such information is beyond the scope of 238 GMPLS protocols. Note that it may be partially inferred from 239 parameters carried in GMPLS signaling or advertised in GMPLS 240 routing. 242 Finally, the computation of FA-LSPs that form the VNT can be 243 performed directly on layer border LSRs or on an external element 244 (such as a Path Computation Element (PCE), [RFC4655]), and this is 245 independent of the location of the VNTM. 247 Hence, to summarize, no GMPLS protocol extensions are required to 248 control FA-LSP setup/release. 250 3.1.1.2. Virtual TE-Links 252 A Virtual TE-link is a TE-link between two upper layer nodes that is 253 not actually associated with a fully provisioned FA-LSP in a lower 254 layer. A Virtual TE-link represents the potentiality to setup an FA- 255 LSP in the lower layer to support the TE-link that has been 256 advertised. A Virtual TE-link is advertised as any TE-link, following 257 the rules in [RFC4206] defined for fully provisioned TE-links. In 258 particular, the flooding scope of a Virtual TE-link is within an IGP 259 area, as is the case for any TE-link. 261 If an upper-layer LSP attempts (through a signaling message) to make 262 use of a Virtual TE-link, the underlying FA-LSP is immediately 263 signaled and provisioned (provided there are available resources in 264 the lower layer) in the process known as triggered signaling. 266 The use of Virtual TE-links has two main advantages: 268 - Flexibility: allows the computation of an LSP path using TE-links 269 without needing to take into account the actual provisioning status 270 of the corresponding FA-LSP in the lower layer; 272 - Stability: allows stability of TE-links in the upper layer, while 273 avoiding wastage of bandwidth in the lower layer, as data plane 274 connections are not established until they are actually needed. 276 Virtual TE-links are setup/deleted/modified dynamically, according to 277 the change of the (forecast) traffic demand, operator's policies for 278 capacity utilization, and the available resources in the lower layer. 280 The support of Virtual TE-links requires two main building blocks: 282 - A TE mechanism for dynamic modification of Virtual TE-link 283 Topology; 285 - A signaling mechanism for the dynamic setup and deletion of virtual 286 TE-links. Setting up a virtual TE-link requires a signaling 287 mechanism allowing an end-to-end association between Virtual 288 TE-link end points so as to exchange link identifiers as well as 289 some TE parameters. 291 The TE mechanism responsible for triggering/policing dynamic 292 modification of Virtual TE-links is out of the scope of GMPLS 293 protocols. 295 Current GMPLS signaling does not allow setting up and releasing 296 Virtual TE-links. Hence GMPLS signaling must be extended to support 297 Virtual TE-links. 299 We can distinguish two options for setting up Virtual TE-links: 301 - The Soft FA approach that consists of setting up the FA-LSP in the 302 control plane without actually activating cross connections in the 303 data plane. On the one hand, this requires state maintenance on all 304 transit LSRs (N square issue), but on the other hand this may allow 305 for some admission control. Indeed, when a soft-FA is activated, 306 the resources may be no longer available for use by other soft-FAs 307 that have common links. These soft-FA will be dynamically released 308 and corresponding virtual TE-links are deleted. The soft-FA LSPs 309 may be setup using procedures similar to those described in 310 [RFC4872] for setting up secondary LSPs. 312 - The remote association approach that simply consists of exchanging 313 virtual TE-links IDs and parameters directly between TE-link end 314 points. This does not require state maintenance on transit LSRs, 315 but reduces admission control capabilities. Such an association 316 between Virtual TE-link end-points may rely on extensions to the 317 RSVP-TE ASON Call procedure ([RFC4974]). 319 Note that the support of Virtual TE-links does not require any GMPLS 320 routing extension. 322 3.1.1.3. Traffic Disruption Minimization During FA Release 324 Before deleting a given FA-LSP, all nested LSPs have to be rerouted 325 and removed from the FA-LSP to avoid traffic disruption. 326 The mechanisms required here are similar to those required for 327 graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism 328 allows for the deletion of a TE-link without disrupting traffic of 329 TE-LSPs that were using the TE-link. 331 Hence, GMPLS routing and/or signaling extensions are required 332 to support graceful deletion of TE-links. This may utilize the 333 procedures described in [GR-SHUT]: A transit LSR notifies a head-end 334 LSR that a TE-link along the path of a LSP is going to be torn down, 335 and also withdraws the bandwidth on the TE-link so that it is not 336 used for new LSPs. 338 3.1.1.4. Stability 340 The stability of upper-layer LSP may be impaired if the VNT undergoes 341 frequent changes. In this context robustness of the VNT is defined as 342 the capability to smooth the impact of these changes and avoid their 343 subsequent propagation. 345 Guaranteeing VNT stability is out of the scope of GMPLS protocols and 346 relies entirely on the capability of the TE and VNT management 347 algorithms to minimize routing perturbations. This requires that the 348 algorithms take into account the old VNT when computing a new VNT, 349 and try to minimize the perturbation. 351 Note that a full mesh of lower-layer LSPs may be created between 352 every pair of border nodes between the upper and lower layers. The 353 merit of a full mesh of lower-layer LSPs is that it provides 354 stability to the upper layer routing. That is, forwarding table used 355 in the upper layer is not impacted if the VNT undergoes changes. 356 Further, there is always full reachability and immediate access to 357 bandwidth to support LSPs in the upper layer. But it also has 358 significant drawbacks, since it requires the maintenance of n^2 RSVP- 359 TE sessions, where n is the number of border nodes, which may be 360 quite CPU and memory consuming (scalability impact). Also this may 361 lead to significant bandwidth wastage. Note that the use of virtual 362 TE-links solves the bandwidth wastage issue, and may reduce the 363 control plane overload. 365 3.1.2. Support for FA-LSP Attributes Inheritance 367 When a FA TE Link is advertised, its parameters are inherited from 368 the parameters of the FA-LSP, and specific inheritance rules are 369 applied. 371 This relies on local procedures and policies and is out of the scope 372 of GMPLS protocols. Note that this requires that both head-end and 373 tail-end of the FA-LSP are driven by same policies. 375 3.1.3. FA-LSP Connectivity Verification 377 Once fully provisioned, FA-LSP liveliness may be achieved by 378 verifying its data plane connectivity. 380 FA-LSP connectivity verification relies on technology specific 381 mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using BFD; 382 etc.) as for any other LSP. Hence this requirement is out of the 383 scope of GMPLS protocols. 385 The GMPLS protocols should provide mechanisms for the coordination 386 of data link verification in the upper layer network where data 387 links are lower layer LSPs. 388 o GMPLS signaling allows an LSP to be put into 'test' mode 389 [RFC3473]. 390 o The link Management Protocol [RFC4204] is a targeted protocol and 391 can be run end-to-end across lower-layer LSPs. 392 o Coordination of testing procedures in different layers is an 393 operational matter. 395 3.1.4. Scalability 397 As discussed in [MLN-REQ]), MRN/MLN routing mechanisms must be 398 designed to scale well with an increase of any of the following: 399 - Number of nodes 400 - Number of TE-links (including FA-LSPs) 401 - Number of LSPs 402 - Number of regions and layers 403 - Number of ISCDs per TE-link. 405 GMPLS routing provides the necessary advertisement functions and is 406 based on IETF-designed IGPs. These are known to scale relatively well 407 with the number of nodes and links. Where there are multiple regions 408 or layers there are two possibilities. 409 1. If a single routing instance distributes information about 410 multiple network layers, the effect is no more than to increase the 411 number of nodes and links in the network. 412 2. If the MLN is fully integrated (i.e., constructed from hybrid 413 nodes), there is an increase in the number of nodes and links 414 as just mentioned, and also a potential increase in the amount 415 of ISCD information advertised per link. This is a relatively 416 small amount of information (e.g., 36 bytes in OSPF [RFC4203]) 417 per switching type, and each interface is unlikely to have more 418 than two or three switching types. 420 The number of LSPs in a lower layer, advertised as TE-links may 421 impact the scaling of the routing protocol. A full mesh of FA-LSPs in 422 the lower layer would lead to n^2 TE-links where n is the number of 423 layer border LSRs. This must be taken into consideration in the VNT 424 management process. This is an operational matter beyond the scope of 425 GMPLS protocols. 427 As regards the scalability of GMPLS signaling, a full mesh of LSPs in 428 the lower layer may impact the salability since it requires the 429 maintenance of n^2 RSVP-TE sessions, which may be quite CPU and 430 memory consuming. The use of virtual TE-links may reduce the control 431 plane overload (see section 3.1.1.2). 433 3.1.5. Operations and Management of the MLN/MRN 435 [MLN-REQ] identifies various requirements for effective management 436 and operation of the MLN. Some features already exist within the 437 GMPLS protocol set, some more are under development, and some 438 requirements are not currently addressed and will need new 439 development work in order to support them. 441 3.1.5.1. MIB Modules 443 MIB modules have been developed to model and control GMPLS switches 444 [RFC4803] and to control and report on the operation of the signaling 445 protocol [RFC4802]. These may be successfully used to manage the 446 operation of a single instance of the control plane protocols that 447 operate across multiple layers. 449 [RFC4220] provides a MIB module for managing TE links, and this may 450 be particularly useful in the context of the MLN as LSPs in the lower 451 layers are made available as TE links in the higher layer. 453 The traffic engineering database provides a repository for all 454 information about the existence and current status of TE links within 455 a network. This information is typically flooded by the routing 456 protocol operating within the network, and is used when LSP routes 457 are computed. [TED-MIB] provides a way to inspect the TED to view the 458 TE links at the different layers of the MLN. 460 As observed in [MLN-REQ], although it would be possible to manage the 461 MLN using only the existing MIB modules, a further MIB module could 462 be produced to coordinate the management of separate network layers 463 in order to construct a single MLN entity. Such a MIB module would 464 effectively link together entries in the MIB modules already 465 referenced. 467 3.1.5.2. OAM 469 At the time of writing, the development of OAM tools for GMPLS 470 networks is at an early stage. GMPLS OAM requirements are addressed 471 in [GMPLS-OAM]. 473 In general, the lower layer network technologies contain their own 474 technology-specific OAM processes (for example, SDH/SONET, Ethernet, 475 and MPLS). In these cases, it is not necessary to develop additional 476 OAM processes, but GMPLS procedures may be desirable to coordinate 477 the operation and configuration of these OAM processes. 478 [ETH-OAM] describes some early ideas for this function, but more work 479 is required to generalize the technique to be applicable to all 480 technologies and to MLN. In particular OAM function operating within 481 a server layer must be controllable from the client layer, and client 482 layer control plane mechanisms must map and enable OAM in the server 483 layer. 485 Where a GMPLS-controlled technology does not contain its own OAM 486 procedures, this is usually because the technology cannot support 487 in-band OAM (for example, WDM networks). In these cases, there is 488 very little that a control plane can add to the OAM function since 489 the presence of a control plane cannot make any difference to the 490 physical characteristics of the data plane. However, the existing 491 GMPLS protocol suite does provide a set of tools that can help to 492 verify the data plane through control plane. These tools are equally 493 applicable to network technologies that do contain their own OAM. 495 - Route recording is available through the GMPLS signaling protocol 496 [RFC3473] making it possible to check the route reported by the 497 control plane against the expected route. This mechanism also 498 includes the ability to record and report the interfaces and labels 499 used for the LSP at each hop of its path. 501 - The status of TE links is flooded by the GMPLS routing protocols 502 [RFC4203] and [RFC4205] making it possible to detect changes in the 503 available resources in the network as an LSP is set up. 505 - The GMPLS signaling protocol [RFC3473] provides a technique to 506 place an LSP into a "test" mode so that end-to-end characteristics 507 (such as power levels) may be sampled and modified. 509 - The Link Management Protocol [RFC4204] provides a mechanism for 510 fault isolation on an LSP. 512 - GMPLS signaling [RFC3473] provides a Notify message that can be 513 used to report faults and issues across the network. The message 514 includes scaling features to allow one message to report the 515 failure of multiple LSPs. 517 - Extensions to GMPLS signaling [RFC4783] enable alarm information to 518 be collected and distributed along the path of an LSP for more easy 519 coordination and correlation. 521 3.2. Specific Aspects for Multi-Region Networks 523 3.2.1. Support for Multi-Region Signaling 525 There are actually several cases where a transit node could choose 526 between multiple SCs to be used for a lower region FA-LSP: 528 - Explicit Route Object (ERO) expansion with loose hops: The transit 529 node has to expand the path, and may have to select among a set of 530 lower region SCs. 532 - Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of 533 an upper region LSP, comprises a multi-SC TE-link, the region 534 border node has to select among these SCs. 536 Existing GMPLS signaling procedures do not allow solving this 537 ambiguous choice of SC that may be used along a given path. 539 Hence an extension to GMPLS signaling has to be defined to indicate 540 the SC(s) that can be used and the SC(s) that cannot be used along 541 the path. 543 3.2.2. Advertisement of Adjustment Capacities 545 In the MRN context, nodes supporting more than one switching 546 capability on at least one interface are called Hybrid nodes ([MLN- 547 REQ]). Conceptually, hybrid nodes can be viewed as containing at 548 least two distinct switching elements interconnected by internal 549 links which provide adjustment between the supported switching 550 capabilities. These internal links have finite capacities and must be 551 taken into account when computing the path of a multi-region TE-LSP. 552 The advertisement of the adjustment capacities is required as it 553 provides critical information when performing multi-region path 554 computation. 556 The term adjustment capacity refers to the property of a hybrid node 557 to interconnect different switching capabilities it provides through 558 its external interfaces [MLN-REQ]. This information allows path 559 computation to select an end-to-end multi-region path that includes 560 links of different switching capabilities that are joined by LSRs 561 that can adapt the signal between the links. 563 Figure 1a below shows an example of hybrid node. The hybrid node has 564 two switching elements (matrices), which support here TDM and PSC 565 switching respectively. The node has two PSC and TDM ports (port1 and 566 port2 respectively). It also has an internal link connecting the two 567 switching elements. 569 The two switching elements are internally interconnected in such a 570 way that it is possible to terminate some of the resources of the TDM 571 port 2 and provide through them adjustment for PSC traffic, 572 received/sent over the internal PSC interface (#b). Two ways are 573 possible to set up PSC LSPs (port 1 or port 2). Available resources 574 advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover 575 both ways. 577 Network element 578 ............................. 579 : -------- : 580 PSC : | PSC | : 581 Port1-------------<->---|#a | : 582 : +--<->---|#b | : 583 : | -------- : 584 : | ---------- : 585 TDM : +--<->--|#c TDM | : 586 Port2 ------------<->--|#d | : 587 : ---------- : 588 :............................ 590 Figure 1a. Hybrid node. 592 Port 1 and Port 2 can be grouped together thanks to internal DWDM, to 593 result in a single interface: Link 1. This is illustrated in figure 594 1b below. 596 Network element 597 ............................. 598 : -------- : 599 : | PSC | : 600 : | | : 601 : --|#a | : 602 : | | #b | : 603 : | -------- : 604 : | | : 605 : | ---------- : 606 : /| | | #c | : 607 : | |-- | | : 608 Link1 ========| | | TDM | : 609 : | |----|#d | : 610 : \| ---------- : 611 :............................ 613 Figure 1b. Hybrid node. 615 Let's assume that all interfaces are STM16 (with VC4-16c capable 616 as Max LSP bandwidth). After, setting up several PSC LSPs via port #a 617 and setting up and terminating several TDM LSPs via port #d and port 618 #b, there is only 155 Mb capacities still available on port #b. 619 However a 622 Mb capacity remains on port #a and VC4-5c capacity on 620 port #d. 622 When computing the path for a new VC4-4c TDM LSP, one must know, that 623 this node cannot terminate this LSP, as there is only 155Mb still 624 available for TDM-PSC adjustment. Hence the TDM-PSC adjustment 625 capacity must be advertised. 627 With current GMPLS routing [RFC4202] this advertisement is possible 628 if link bundling is not used and if two TE-links are advertised for 629 link1: 631 We would have the following TE-link advertisements: 633 TE-link 1 (port 1): 634 - ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb 635 - Unreserved bandwidth = 622Mb. 637 TE-Link 2 (port 2): 638 - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, 639 - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb, 640 - Unreserved bandwidth (equivalent): 777 Mb. 642 The ISCD 2 in TE-link 2 represents actually the TDM-PSC adjustment 643 capacity. 645 However if for obvious scalability reasons link bundling is done then 646 the adjustment capacity information is lost with current GMPLS 647 routing, as we have the following TE-link advertisement: 649 TE-link 1 (port 1 + port 2): 650 - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, 651 - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb, 652 - Unreserved bandwidth (equivalent): 1399 Mb. 654 With such TE-link advertisement an element computing the path of a 655 VC4-4c LSP cannot know that this LSP cannot be terminated on the 656 node. 658 Thus current GMPLS routing can support the advertisement of the 659 adjustment capacities but this precludes performing link bundling and 660 thus faces significant scalability limitations. 662 Hence, GMPLS routing must be extended to meet this requirement. This 663 could rely on the advertisement of the adjustment capacities as a new 664 TE link attribute (that would complement the Interface Switching 665 Capability Descriptor TE-link attribute). 667 Note: Multiple ISCDs MAY be associated to a single switching 668 capability. This can be performed to provide e.g. for TDM interfaces 669 the Min/Max LSP Bandwidth associated to each (set of) layer for that 670 switching capability. As an example, an interface associated to TDM 671 switching capability and supporting VC-12 and VC-4 switching, can be 672 associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case, 673 the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to 674 VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and 675 the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the 676 Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4, 677 in the second ISCD sub-TLV. Hence, in the first case, as long as the 678 Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second 679 case, as long as the first ISCD sub-TLV is advertised there is 680 sufficient capacity across that interface to setup a VC-12 LSP. 682 4. Evaluation Conclusion 684 Most of the required MLN/MRN functions will rely on mechanisms and 685 procedures that are out of the scope of the GMPLS protocols, and thus 686 do not require any GMPLS protocol extensions. They will rely on local 687 procedures and policies, and on specific TE mechanisms and 688 algorithms. 690 As regards Virtual Network Topology (VNT) computation and 691 reconfiguration, specific TE mechanisms need to be defined, but these 692 mechanisms are out of the scope of GMPLS protocols. 694 Six areas for extensions of GMPLS protocols and procedures have been 695 identified: 697 - GMPLS signaling extension for the setup/deletion of the virtual 698 TE-links; 700 - GMPLS signaling extension for graceful TE-link deletion; 702 - GMPLS signaling extension for constrained multi-region signaling 703 (SC inclusion/exclusion); 705 - GMPLS routing extension for the advertisement of the adjustment 706 capacities of hybrid nodes. 708 - A MIB module for coordination of other MIB modules being operated 709 in separate layers. 711 - GMPLS signaling extensions for the control and configuration of 712 technology-specific OAM processes. 714 4.1. Traceability of Requirements 716 This section provides a brief cross-reference to the requirements set 717 out in [MLN-REQ] so that it is possible to verify that all of the 718 requirements listed in that document have been examined in this 719 document. 721 - Path computation mechanism should be able to compute paths and 722 handle topologies consisting of any combination of (simplex) nodes 723 ([MLN-REQ], Section 5.1). 724 o Path computation mechanisms are beyond the scope of protocol 725 specifications, and out of scope for this document. 727 - A hybrid node should maintain resources on its internal links 728 ([MLN-REQ], Section 5.2). 729 o This is an implementation requirement and is beyond the scope of 730 protocol specifications, and out of scope for this document. 732 - Path computation mechanisms should be prepared to use the 733 availability of termination/adjustment resources as a constraint in 734 path computation ([MLN-REQ], Section 5.2). 735 o Path computation mechanisms are beyond the scope of protocol 736 specifications, and out of scope for this document. 738 - The advertisement of a node's ability to terminate lower-region 739 LSPs and to forward traffic in the upper-region (adjustment 740 capability) is required ([MLN-REQ], Section 5.2). 741 o See Section 3.2.2 of this document. 743 - The path computation mechanism should support the coexistence of 744 upper-layer links directly connected to upper-layer switching 745 elements, and upper-layer links connected through internal links 746 between upper-layer and lower-layer switching elements ([MLN-REQ], 747 Section 5.2). 748 o Path computation mechanisms are beyond the scope of protocol 749 specifications, and out of scope for this document. 751 - MRN/MLN routing mechanisms must be designed to scale well with an 752 increase of any of the following: 753 - Number of nodes 754 - Number of TE-links (including FA-LSPs) 755 - Number of LSPs 756 - Number of regions and layers 757 - Number of ISCDs per TE-link. 758 ([MLN-REQ], Section 5.3). 759 o See Section 3.1.4 of this document. 761 - Design of the routing protocols must not prevent TE information 762 filtering based on ISCDs, ([MLN-REQ], Section 5.3). 763 o All advertised information carries the ISCD and so a receiving 764 node may filter as required. 766 - The path computation mechanism and the signaling protocol should be 767 able to operate on partial TE information, ([MLN-REQ], Section 768 5.3). 769 o Path computation mechanisms are beyond the scope of protocol 770 specifications, and out of scope for this document. 772 - Protocol mechanisms must be provided to enable creation, deletion, 773 and modification of LSPs triggered through operational actions, 774 ([MLN-REQ], Section 5.4). 775 o Such mechanisms are standard in GMPLS signaling [RFC3473]. 777 - Protocol mechanisms should be provided to enable similar functions 778 triggered by adjacent layers, ([MLN-REQ], Section 5.4). 780 o Such mechanisms are standard in GMPLS signaling [RFC3473]. 782 - Protocol mechanisms may be provided to enable adaptation to changes 783 such as traffic demand, topology, and network failures. Routing 784 robustness should be traded with adaptability of those changes, 785 ([MLN-REQ], Section 5.4). 786 o See section 3.1.1 of this document. 788 - Reconfiguration of the VNT must be as non-disruptive as possible 789 and must be under the control of policy configured by the operator, 790 ([MLN-REQ], Section 5.5). 791 o See Section 3.1.1.3 of this document 793 - Parameters of a TE link in an upper should be inherited from the 794 parameters of the lower-layer LSP that provides the TE-link, based 795 on polices configured by the operator, ([MLN-REQ], Section 5.6). 796 o See Section 3.1.2 of this document. 798 - The upper-layer signaling request may contain an ERO that includes 799 only hops in the upper layer, ([MLN-REQ], Section 5.7). 800 o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1. 802 - The upper-layer signaling request may contain an ERO specifying the 803 lower layer FA-LSP route, ([MLN-REQ], Section 5.7). 804 o Standard for GMPLS signaling [RFC3473]. See also Section 3.2.1. 806 - As part of the re-optimization of the MLN, it must be possible to 807 reroute a lower-layer FA-LSP while keeping interface identifiers of 808 the corresponding TE links unchanged and causing only minimal 809 disruption to higher-layer traffic, ([MLN-REQ], Section 5.8.1). 810 o See Section 3.1.1.3. 812 - The solution must include measures to protect against network 813 destabilization caused by the rapid setup and teardown of lower- 814 layer LSPs as traffic demand varies near a threshold, ([MLN-REQ], 815 Sections 5.8.1 and 5.8.2). 816 o See Section 3.1.1.4. 818 - Signaling of lower-layer LSPs should include a mechanism to rapidly 819 advertise the LSP as a TE link in the upper layer, and to 820 coordinate into which routing instances the TE link should be 821 advertised, ([MLN-REQ], Section 5.8.1). 822 o This is provided by [RFC4206] and enhanced by [HIER-BIS]. See 823 also Section 3.1.1.2. 825 - If an upper-layer LSP is set up making use of a virtual TE-Link, 826 the underlying LSP must immediately be signaled in the lower layer, 827 ([MLN-REQ], Section 5.8.2). 828 o See Section 3.1.1.2. 830 - The solution should provide operations to facilitate the build-up 831 of virtual TE-links, taking into account the forecast upper-layer 832 traffic demand and available resource in the lower-layer, 833 ([MLN-REQ], Section 5.8.2). 834 o See Section 3.1.1.2 of this document. 836 - The GMPLS protocols should provide mechanisms for the coordination 837 of data link verification in the upper layer network where data 838 links are lower layer LSPs, ([MLN-REQ], Section 5.9). 839 o See Section 3.1.3 of this document. 841 - Multi-layer protocol solutions should be manageable through MIB 842 modules, ([MLN-REQ], Section 5.10). 843 o See section 3.1.5.1. 845 - Choices about how to coordinate errors and alarms, and how to 846 operate OAM across administrative and layer boundaries must be left 847 open for the operator, ([MLN-REQ], Section 5.10). 848 o This is an implementation matter, subject to operational 849 policies. 851 - It must be possible to enable end-to-end OAM on an upper-layer LSP. 852 This function appears to the ingress LSP as normal LSP-based OAM 853 [GMPLS-OAM], but at layer boundaries, depending on the technique 854 used to span the lower layers, client-layer OAM operations may need 855 to be mapped to server-layer OAM operations ([MLN-REQ], Section 856 5.10). 857 o See Section 3.1.5.2. 859 - Client layer control plane mechanisms must map and enable OAM in 860 the server layer, ([MLN-REQ], Section 5.10). 861 o See Section 3.1.5.2. 863 - OAM operation enabled for an LSP in a client layer must operate for 864 that LSP along its entire length, ([MLN-REQ], Section 5.10). 865 o See Section 3.1.5.2. 867 - OAM function operating within a server layer must be controllable 868 from the client layer. Such control should be subject to policy at 869 the layer boundary, ([MLN-REQ], Section 5.10). 870 o This is an implementation matter. 872 - The status of a server layer LSP must be available to the client 873 layer. This information should be configurable to be automatically 874 notified to the client layer at the layer boundary, and should be 875 subject to policy, ([MLN-REQ], Section 5.10). 876 o This is an implementation matter. 878 - Implementations may use standardized techniques (such as MIB 879 modules) to convey status information between layers. 880 o This is an implementation matter. 882 5. Security Considerations 884 [MLN-REQ] sets out the security requirements for operating a MLN or 885 MRN. These requirements are, in general, no different from the 886 security requirements for operating any GMPLS network. As such, the 887 GMPLS protocols already provide adequate security features. An 888 evaluation of the security features for GMPLS networks may be found 889 in [MPLS-SEC], and where issues or further work is identified by that 890 document, new security features or procedures for the GMPLS protocols 891 will need to be developed. 893 [MLN-REQ] also identifies that where the separate layers of a MLN/MRN 894 network are operated as different administrative domains, additional 895 security considerations may be given to the mechanisms for allowing 896 inter-layer LSP setup. However, this document is explicitly limited 897 to the case where all layers under GMPLS control are part of the same 898 administrative domain. 900 Lastly, as noted in [MLN-REQ], it is expected that solution documents 901 will include a full analysis of the security issues that any protocol 902 extensions introduce. 904 6. IANA Considerations 906 This informational document makes no requests for IANA action. 908 7. Acknowledgments 910 We would like to thank Julien Meuric, Igor Bryskin, and Adrian Farrel 911 for their useful comments. 913 Thanks also to Question 14 of Study Group 15 of the ITU-T for their 914 thoughtful review. 916 8. References 918 8.1. Normative References 920 [RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label 921 Switching (GMPLS) Signaling Functional Description", RFC 922 3471, January 2003. 924 [RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label 925 Switching Architecture", RFC 3945, October 2004 927 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing 928 Extensions in Support of Generalized Multi-Protocol 929 Label Switching", RFC4202, October 2005. 931 [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., 932 Vigoureux, M., Brungard, D., "Requirements for GMPLS- 933 based multi-region and multi-layer networks", draft- 934 ietf-ccamp-gmpls-mln-reqs, work in progess. 936 8.2. Informative References 938 [RFC3473] Berger, L., et al. "GMPLS Signaling RSVP-TE 939 extensions", RFC3473, January 2003. 941 [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in 942 Support of Generalized Multi-Protocol Label 943 Switching", RFC4203, Oct. 2005. 945 [RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC 946 4204, September 2005. 948 [RFC4205] K. Kompella, and Y. Rekhter, "Intermediate System to 949 Intermediate System (IS-IS) Extensions in Support of 950 Multi-Protocol Label Switching (GMPLS)", RFC 4205, 951 October 2005. 953 [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with 954 generalized MPLS TE", RFC4206, October 2005. 956 [RFC4220] Dubuc, M., Nadeau, T., and Lang, J., "Traffic 957 Engineering Link Management Information Base", RFC 4220, 958 November 2005. 960 [RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based 961 Architecture", RFC4655, August 2006. 963 [RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized 964 Multiprotocol Label Switching (GMPLS) Traffic 965 Engineering Management Information Base", RFC 4802, 966 February 2007. 968 [RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized 969 Multiprotocol Label Switching (GMPLS) Label Switching 970 Router (LSR) Management Information Base", RFC 4803, 971 February 2007. 973 [RFC4783] L. Berger, Ed., "GMPLS - Communication of Alarm 974 Information", RFC 4783, December 2006. 976 [RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in 977 support of End-to-End Generalized Multi-Protocol Label 978 Switching (GMPLS)-based Recovery", RFC4872, May 2007. 980 [RFC4974] Papadimitriou, D., Farrel, A., et. al., "Generalized 981 MPLS (GMPLS) RSVP-TE Signaling Extensions in support of 982 Calls", RFC 4974, August 2007. 984 [ETH-OAM] Takacs, A., Gero, B., "GMPLS RSVP-TE Extensions to 985 Control Ethernet OAM", draft-takacs-ccamp-rsvp-te-eth- 986 oam-ext, work in progress. 988 [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and Farrel, A., 989 "OAM Requirements for Generalized Multi-Protocol Label Switching 990 (GMPLS) Networks", draft-ietf-ccamp-gmpls-oam-requirements, work in 991 progress. 993 [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic 994 Engineering Network", draft-ietf-ccamp-mpls-graceful- 995 shutdown, work in progress. 997 [HIER-BIS] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A., and 998 Ali, Z., "Procedures for Dynamically Signaled 999 Hierarchical Label Switched Paths", draft-ietf-ccamp- 1000 lsp-hierarchy-bis, work in progress. 1002 [MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS 1003 Networks draft-fang-mpls-gmpls-security-framework, work 1004 in progress. 1006 [PCE-INTER] Oki, E., Le Roux , J-L., and Farrel, A., "Framework for 1007 PCE-Based Inter-Layer MPLS and GMPLS Traffic 1008 Engineering", draft-ietf-pce-inter-layer-frwk, work in 1009 progress. 1011 [TED-MIB] Miyazawa, M., Otani, T., Kunaki, K. and Nadeau, T., 1012 "Traffic Engineering Database Management Information 1013 Base in support of GMPLS", draft-ietf-ccamp-gmpls-ted- 1014 mib, work in progress. 1016 9. Editors' Addresses 1018 Jean-Louis Le Roux 1019 France Telecom 1020 2, avenue Pierre-Marzin 1021 22307 Lannion Cedex, France 1022 Email: jeanlouis.leroux@orange-ftgroup.com 1024 Dimitri Papadimitriou 1025 Alcatel-Lucent 1026 Francis Wellensplein 1, 1027 B-2018 Antwerpen, Belgium 1028 Email: dimitri.papadimitriou@alcatel-lucent.be 1030 10. Contributors' Addresses 1032 Deborah Brungard 1033 AT&T 1034 Rm. D1-3C22 - 200 S. Laurel Ave. 1035 Middletown, NJ, 07748 USA 1036 E-mail: dbrungard@att.com 1038 Eiji Oki 1039 NTT 1040 3-9-11 Midori-Cho 1041 Musashino, Tokyo 180-8585, Japan 1042 Email: oki.eiji@lab.ntt.co.jp 1044 Kohei Shiomoto 1045 NTT 1046 3-9-11 Midori-Cho 1047 Musashino, Tokyo 180-8585, Japan 1048 Email: shiomoto.kohei@lab.ntt.co.jp 1050 M. Vigoureux 1051 Alcatel-Lucent France 1052 Route de Villejust 1053 91620 Nozay 1054 FRANCE 1055 Email: martin.vigoureux@alcatel-lucent.fr 1057 11. Intellectual Property Statement 1059 The IETF takes no position regarding the validity or scope of any 1060 Intellectual Property Rights or other rights that might be claimed to 1061 pertain to the implementation or use of the technology described in 1062 this document or the extent to which any license under such rights 1063 might or might not be available; nor does it represent that it has 1064 made any independent effort to identify any such rights. Information 1065 on the procedures with respect to rights in RFC documents can be 1066 found in BCP 78 and BCP 79. 1068 Copies of IPR disclosures made to the IETF Secretariat and any 1069 assurances of licenses to be made available, or the result of an 1070 attempt made to obtain a general license or permission for the use of 1071 such proprietary rights by implementers or users of this 1072 specification can be obtained from the IETF on-line IPR repository at 1073 http://www.ietf.org/ipr. 1075 The IETF invites any interested party to bring to its attention any 1076 copyrights, patents or patent applications, or other proprietary 1077 rights that may cover technology that may be required to implement 1078 this standard. Please address the information to the IETF at ietf- 1079 ipr@ietf.org. 1081 Disclaimer of Validity 1083 This document and the information contained herein are provided 1084 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1085 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1086 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1087 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1088 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1089 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1090 FOR A PARTICULAR PURPOSE. 1092 Copyright Statement 1094 Copyright (C) The IETF Trust (2008). This document is subject to the 1095 rights, licenses and restrictions contained in BCP 78, and except as 1096 set forth therein, the authors retain all their rights.