idnits 2.17.1 draft-kumaki-ccamp-mpls-gmpls-interworking-02.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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 608. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 693), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == It seems as if not all pages are separated by form feeds - found 16 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Introduction of GMPLS technology in existing IP/MPLS networks and' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 431 instances of too long lines in the document, the longest one being 27 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], [RFC3630], [RFC3471], [GMPLS-ospf-routing], [RFC2119], [RFC3473], [RFC3945], [RFC3784], [GMPLS-routing], [RFC4090], [RFC3209], [GMPLS-mig]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2006) is 6675 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC3945' on line 632 looks like a reference -- Missing reference section? 'GMPLS-mig' on line 628 looks like a reference -- Missing reference section? 'RFC2119' on line 625 looks like a reference -- Missing reference section? 'RFC4090' on line 656 looks like a reference -- Missing reference section? 'RFC3471' on line 648 looks like a reference -- Missing reference section? 'RFC3473' on line 652 looks like a reference -- Missing reference section? 'GMPLS-routing' on line 637 looks like a reference -- Missing reference section? 'RFC3209' on line 619 looks like a reference -- Missing reference section? 'RFC3630' on line 622 looks like a reference -- Missing reference section? 'GMPLS-ospf-routing' on line 641 looks like a reference -- Missing reference section? 'RFC3784' on line 580 looks like a reference -- Missing reference section? 'RFC2205' on line 645 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt January 2006 3 CCAMP Working Group Kenji Kumaki 4 KDDI Corporation 5 Zafar Ali 6 Cisco Systems 7 Tomohiro Otani 8 KDDI R&D Laboratories, Inc. 9 George Swallow 10 Mallik Tatipamula 11 Cisco Systems 12 Internet Draft 13 Category: BCP 14 Expires: July 2006 January 2006 16 Operational, Deployment and Interworking Considerations for GMPLS 17 draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). All Rights Reserved. 45 Abstract 47 In order to deploy GMPLS technology in the existing IP/MPLS networks, 48 various operation, deployment and interworking aspect of MPLS/GMPLS 49 needs to be addressed. 51 From the deployment perspective, GMPLS architecture document lists 52 [RFC3945] three different scenarios in which GMPLS technology can be 53 deployed: overlay, augmented and integrated. Reference [GMPLS-mig] 54 addresses the problem of migration from MPLS to GMPLS networks using 55 the integrated model. This draft addresses the same problem space for 56 augmented model and illustrates the applicability of augmented model 57 in deploying GMPLS technology in existing IP/MPLS networks. 59 Another very important aspect of MPLS/GMPLS interworking is ability 60 to effectively use GMPLS services in IP/MPLS networks. This includes 61 ability to specify GMPLS LSPs in signaling requests based on the type 62 of the setup desired, as well as considerations for the operation 63 aspects of using GMPLS LSPs. 65 In this draft, we highlight some deployment and MPLS/GMPLS 66 interworking requirements and propose solutions to address them. We 67 also highlight some operation aspects and the possible solution and 68 provide applicability statement for the available options. 70 Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 Routing Area ID Summary 78 (This section to be removed before publication.) 80 SUMMARY 82 This document addresses some MPLS/ GMPLS deployment, operational and 83 interworking aspects. 85 WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? 87 This work fits in the context of MPLS/GMPLS deployment, operational 88 and interworking. 90 WHY IS IT TARGETED AT THIS WG? 92 This document is targeted at ccamp as it addresses some MPLS/GMPLS 93 deployment, operational and interworking aspects. 95 RELATED REFERENCES 97 Please refer to the reference section. 99 Table of Contents 101 1. Introduction..................................................4 102 2. Terminology...................................................5 103 3. MPLS/GMPLS Deployment,Operational and interworking requirements5 104 3.1 Software Upgrade Requirement.................................5 105 3.2 Use of GMPLS network resources in IP/MPLS networks...........6 106 3.3 Interworking of MPLS and GMPLS protection....................6 107 3.4 Separation of IP/MPLS domain and GMPLS domain................6 108 3.5 Failure recovery.............................................6 109 4. Augmented model...............................................6 110 4.1 Routing in Augmented Model...................................7 111 4.2 Failure Recovery in Augmented Model..........................7 112 4.3 Management in Augmented model................................8 113 4.4 GMPLS Deployment Considerations..............................8 114 4.5 Applicability of real/virtual FA-LSP.........................8 115 4.6 Applicability of FA Utilization..............................9 116 4.7 Bundling FA-LSP..............................................9 117 5. MPLS/GMPLS Interworking aspects...............................9 118 5.1 Static vs. signaling triggered dynamic FA-LSPs...............9 119 5.2 MPLS/GMPLS LSP Resource Affinity Mapping....................10 120 5.3 MPLS/GMPLS LSP Priority Mapping.............................10 121 5.4 Signaling Protected MPLS LSPs...............................11 122 6. Operational Considerations...................................12 123 6.1 Applicability of the Priority Management Options............12 124 6.2 Applicability of the Signaling Triggered Dynamic FA-LSP.....13 125 7. Backward Compatibility Note..................................13 126 8. Security Considerations......................................13 127 9. Intellectual Property Considerations.........................13 128 10.Acknowledgement..............................................14 129 11.Reference....................................................14 130 11.1 Normative Reference........................................14 131 11.2 Informative Reference......................................14 132 12.Author's Addresses...........................................15 133 13.Full Copyright Statement.....................................16 135 1. Introduction 137 Introduction of GMPLS technology in existing IP/MPLS networks and 138 migration of IP/MPLS services to GMPLS core poses some new 139 requirements that do not exist while using point to point physical 140 links in the core network. One of the biggest challenges in today's 141 network is "how to deploy GMPLS technology" in a manner least impact 142 on the existing IP/MPLS networks. It is neither feasible nor desired 143 to upgrade all existing nodes to GMPLS technology. In fact, it is 144 required to minimize the impact of migration to GMPLS on the existing 145 IP/MPLS network. It is also desired to respect the administrative 146 boundaries between IP/MPLS and Optical domains. 148 There are several architectural alternatives including overlay, 149 integrated and augmented models proposed in GMPLS architecture 150 document [RFC3945]. The key difference among these models is how much 151 and what kind of network information can be shared between packet and 152 Optical domains. Peer model is suitable, where optical transport and 153 Internet/Intranet Service networks are operated by a single entity. 154 Currently, many service providers have traditionally built their 155 networks, where Optical transport and IP/MPLS service networks belong 156 to different operation, management, ownership. Most important thing 157 is that service providers wants to operate and manage their networks 158 independently, and deploy them without changing existing IP/MPLS 159 network topologies, protocols and scalability. Overlay model is 160 suitable for such scenario, however does not offer the benefits of 161 peer model approach for efficient resource utilization, optimal 162 routing and protection and restoration between IP/MPLS and Optical 163 networks. Augmented model is suitable in this scenario, where Optical 164 transport and IP/MPLS service networks administrated by different 165 entities and would like to maintain a separation between IP/MPLS and 166 Optical layers, at the same time, get the benefits of integrated 167 model approach. 169 Reference [GMPLS-mig] addresses the problem of migration from MPLS to 170 GMPLS networks using the integrated model. This draft addresses the 171 GMPLS deployment considerations using augmented model and illustrates 172 how it can be used in existing IP, MPLS and non-IP/MPLS networks. In 173 this regard, there are three different considerations taken into 174 account while comparing these approaches. They are: Deployment 175 considerations, routing aspects, and failure recovery considerations. 177 MPLS/GMPLS interworking is also an important aspect that needs to be 178 considered in deploying GMPLS technology in existing IP/MPLS networks. 179 MPLS/GMPLS interworking function refers to methods deployed for 180 mapping between MPLS LSPs and GMPLS LSPs. From a Packet Switching 181 Capable (PSC) network point of view, a router in the PSC network sees 182 GMPLS LSP (signaled in non-PSC network) as a point-to-point link. How 183 effectively IP/MPLS networks can utilize these TE links (FA-LPSs) 184 created in GMPLS networks is an important aspect that needs to be 185 considered. 187 Resource affinity and Priority management are operational aspect that 188 must be considered in deploying GMPLS technology. Specifically, GMPLS 189 technology is equipped with features like resource affinity and 190 priority management, protection and restoration. These features have 191 some implications on how IP/MPLS networks can utilize forwarding 192 and/or routing adjacencies established on top of GMPLS networks. 193 Especially, these management can be a local decision. 194 In this draft, we highlight these implications/requirements and 195 propose solutions to address them. In this fashion this draft 196 complements [GMPLS-mig] draft, which formalizes the MPLS/GMPLS 197 interworking problem. However, [GMPLS-mig] draft does not address 198 MPLS/GMPLS interworking problems such as a mapping between protected 199 MPLS LSPs and protected GMPLS LSPs. 201 Feature richness of MPLS and GMPLS technology allows service 202 providers to use a set of options on how GMPLS services can be used 203 by IP/MPLS networks. However, there are some operational 204 considerations and pros and cons associated with the individual 205 options. This draft also highlights some operations considerations 206 associated with use of GMPLS services by IP/MPLS networks. 208 2. Terminology 210 SP: Service provider 211 MPLS LSP setup request: MPLS rsvp path message 212 MPLS signaling request: MPLS rsvp path message 213 MPLS TE topology: MPLS TE database (TED) 215 3. MPLS/GMPLS Deployment,Operational and interworking requirements 217 In this section, we highlight requirements that service providers 218 have in order to deploy GMPLS technology in existing IP/MPLS networks. 220 3.1 Software Upgrade Requirement 222 Generally speaking, it is not practical to upgrade all IP/MPLS 223 routers to GMPLS capable routers in real SP networks due to a number 224 of reasons. Especially, in case of accommodating enterprise customer, 225 we do not allow IP/MPLS routers to upgrade GMPLS capable routers. 226 This means in the real IP/MPLS networks some routers would not be 227 upgraded to support GMPLS and some routers support would it. 229 3.2 Use of GMPLS network resources in IP/MPLS networks 231 Most SPs have different networks for various services; their GMPLS 232 deployment plans are to have these service networks use a common 233 GMPLS controlled optical core. We need a way to make effective use 234 of GMPLS network resources (e.g. bandwidth) by the IP/MPLS service 235 networks. 237 3.3 Interworking of MPLS and GMPLS protection 239 If MPLS LSPs are protected using MPLS FRR [RFC4090], when an FRR 240 protected packet LSP is signaled, we should be able to select 241 protected FA-LSPs from GMPLS network. In terms of MPLS protection, 242 MPLS path message can be included some flags in FAST REROUTE object 243 and SESSION_ATTRIBUTE object. 244 In terms of GMPLS protection, there are both signaling aspects 245 [RFC3471] [RFC3473] and routing aspects [GMPLS-routing]. 246 Protected MPLS LSPs should be able to select GMPLS protection type 247 with the option. 249 3.4 Separation of IP/MPLS domain and GMPLS domain 251 Most SPs have had different networks for every service, where 252 optical networks and IP/MPLS networks belong to different operation, 253 management, ownership. Most important thing is that SPs want to 254 operate and manage their networks independently, and deploy them 255 without changing existing IP/MPLS network topologies, protocols and 256 affecting scalability. 258 3.5 Failure recovery 260 Failure in optical routing domain should not affect services in 261 IP/MPLS routing domain, and failure can be restored/repaired in 262 optical domain without impacting IP/MPLS domain and vice versa. 264 4. Augmented model 266 Augmented Model is introduced in GMPLS Architecture document 267 [RFC3945]. It is a hybrid model between the full peer and overlay 268 models as shown in figure1. Border nodes at the edge of IP/MPLS 269 domain and optical domain receive routing information from the 270 optical devices (in optical domain) and nodes (in IP/MPLS domain). 271 Based on this information, border node keeps the optical and IP/MPLS 272 routing domain topology information in separate topology database. No 273 routing information from the router region is carried into the 274 optical region and vice versa. These are quite useful aspects from 275 MPLS/GMPLS deployment, operations as well as interworking 276 requirements. 278 | Optical Transport | 279 | Network | 280 +--------+ +--------+ +-------+ +-------+ +--------+ +---------+ 281 | | | | | | | | | | | | 282 | IP/MPLS+--+ Border +--+--+ OXC1 +--+ OXC2 +-+--+ Border +---+ IP/MPLS | 283 | Service| | Node | | | | | | Node | | Service | 284 | Network| | | | | | | | | | Network | 285 +-----+--+ +---+----+ +-----+-+ +---+---+ +--------+ +---------+ 287 Figure 1. Augmented Model 289 4.1 Routing in Augmented Model 291 Augmented model maintains a separation between optical and routing 292 topologies; unlike integrated model approach, where topology 293 information is shared between IP/MPLS and Optical domains. 294 Nonetheless, as the border node has full knowledge of the optical 295 network, it can compute routes for GMPLS LSPs within the optical 296 domain. This allows augmented model to be more efficient in resource 297 utilization than overlay model, such that router and optical domain 298 resource can be optimized. At the same time, it can yield more 299 efficient use of resources, similar to the full peer model. In the 300 full peer model, however, since all the devices in optical and 301 routing domains share the same topology and routing information with 302 same IGP instance, it requires all the devices within peer model to 303 be MPLS/GMPLS aware. 305 4.2 Failure Recovery in Augmented Model 307 Both integrated model and augmented model offer a tighter 308 coordination between IP/MPLS and optical layers, which helps to 309 resolve uncorrelated failures. This is unlike overlay model, which 310 offers no coordination between optical and IP/MPLS layers; 311 consequently a single failure in one layer may trigger uncorrelated 312 failures in the other domain, which may complicate the fault handling. 314 Another important aspect in augmented model is failure transparency, 315 i.e., a failure in an optical network does not affect operations at a 316 router network and vice versa. Specifically, failure in the optical 317 domain does not affect services in routing (IP/MPLS) domain, and 318 failure can be restored/repaired in optical domain without impacting 319 IP/MPLS domain and vice versa. Where as in peer model, since optical 320 and IP/MPLS domains share the same topology and routing information, 321 failure in optical domain is visible to IP/MPLS domain and vice versa. 323 4.3 Management in Augmented model 325 Currently, many SPs have traditionally built their networks, where 326 Optical transport and IP/MPLS service networks belong to different 327 operation, management, ownership. In augmented model, each network 328 administrator can operate and manage his network independently 329 because this model maintains a complete separation between these 330 networks. 332 4.4 GMPLS Deployment Considerations 334 In the integrated model, since all the devices in optical and routing 335 domains share the same topology and routing information with same IGP 336 instance, it requires all the devices within peer model to be 337 MPLS/GMPLS aware. Reference [GMPLS-mig] discusses various aspects of 338 migration from MPLS to GMPLS technology using integrated model. 340 In augmented model, as shown in figure 1, devices within optical and 341 its routing domains have no visibility into others topology and/or 342 routing information, except the border nodes. This will help 343 augmented model to accommodate both MPLS based or non-MPLS based 344 service networks connected to border nodes, as long as Border node in 345 augmented model can support GMPLS control plane. 347 One of the main advantages of the augmented model in the context of 348 GMPLS deployment is that it does not require existing IP/MPLS 349 networks to be GMPLS aware. Only border nodes need to be upgraded 350 with the GMPLS functionality. In this fashion, augmented model 351 renders itself for incremental deployment of the optical regions, 352 without requiring reconfiguration of existing areas/ASes, changing 353 operation of IGP and EGP or software upgrade of the existing IP/MPLS 354 service networks. 356 4.5 Applicability of real/virtual FA-LSP 358 Real/Virtual FA-LSPs discussed in [GMPLS-mig] are equally applicable 359 to the integrated and augmented models. Specifically, in augmented 360 model, the border node can advertise virtual GMPLS FA-LSPs into 361 IP/MPLS networks and can establish the LSP statically or dynamically 362 on as needed basis. The only additional requirement posed by the 363 augmented model is to have at least one full routing adjacency over 364 the GMPLS LSP, such that TE topology exchange for the individual 365 service network can happen. 367 4.6 Applicability of FA Utilization 369 There are several possible schemes for determining how many FAs to 370 provision, when to enable the FAs, and whether to choose FAs of 371 virtual FAs as discussed in [GMPLS-mig] for integrated model. These 372 aspects of FA Utilization are equally applicable to augmented model, 373 with intelligence of FA Utilization implemented at the border node. 375 4.7 Bundling FA-LSP 377 In augmented model, it is also possible to bundle GMPLS FA-LSPs at 378 the border nodes. Since IP/MPLS network will only see a bundled link 379 with TE or IGP attributes, operations on the bundled link, e.g., 380 adding a new component link, failure of a component link, etc., are 381 completely transparent to the rest of the network. 383 5. MPLS/GMPLS Interworking aspects 385 This section outlines some MPLS/GMPLS interworking aspects. 387 5.1 Static vs. signaling triggered dynamic FA-LSPs 389 From signaling perspective, clearly there are two alternatives in 390 which setup for GMPLS tunnel can be triggered: Static (pre- 391 configured) and Dynamic (on-demand based on signaling setup request). 393 Decision to establish new Static GMPLS LSPs are made either by the 394 operator or automatically (e.g., using features like TE auto-mesh). 395 In either case, Static FA-LSP are established and advertised prior to 396 setup of MPLS LSPs using them in the ERO. In case of static FA-LSP, 397 if MPLS LSP setup request cannot be satisfied by existing Static FA- 398 LSPs, it is rejected. 400 Dynamic FA-LSP is triggered by MPLS LSP setup request for an MPLS LSP. 401 Please note that dynamic FA-LSPs can be virtual FAs from routing 402 perspective. In either case, LSP creation from signaling perspective 403 is triggered by the MPLS RSVP Path message received at a MPLS/GMPLS 404 border router. 406 In the case of Static or Virtual FA-LSPs, the FA may be specified in 407 an ERO encoded as strict ERO. In the case where FA-LSPs are dynamic 408 and are not advertised as virtual links in the MPLS TE topology, MPLS 409 signaling request contains a loose ERO, and GMPLS LSP selection is a 410 local decision at the border router. In the case of Static or Virtual 411 FA-LSPs, a signaling request may also be encoded as loose ERO. 413 When the border router receives the signaling setup request and 414 determines that in order for it to expand the loose ERO content, it 415 needs to create GMPLS FA-LSP. Consequently, it signals a GMPLS LSP 416 respecting MPLS/GMPLS signaling interworking aspects discussed in 417 this sections. Once the GMPLS FA-LSP is fully established, the ERO 418 contents for the MPLS signaling setup request are expanded to use the 419 GMPLS LSP and signaling setup for the FA-LSP are carried in-band of 420 the GMPLS LSP. The GMPLS LSP can then also be advertised as an FA-LSP 421 in MPLS TE topology or an IGP adjacency can be brought up on the 422 GMPLS LSP. 424 5.2 MPLS/GMPLS LSP Resource Affinity Mapping 426 In terms of signaling aspects, both MPLS and GMPLS LSPs are signaled 427 for specific resource class affinities [RFC3209], [RFC3473]. This can 428 be viewed as "colors". In terms of routing aspects, resource classes 429 are associated with links and advertised by routing protocol in 430 IP/MPLS domain [RFC3630] and GMPLS domain, respectively. 432 A real or virtual GMPLS FA-LSP or a full Routing Adjacency (RA) over 433 GMPLS LSP can be advertised as TE-links with resource class. 434 In this case, MPLS routers can select a GMPLS FA/RA that has a 435 specific color. 437 If MPLS signaling request contains a loose ERO, and GMPLS LSP 438 selection is a local decision at the border router. This is possible 439 for the cases when GMPLS LSP is not advertised into IP/MPLS networks. 440 In this case, any mapping combination may be defined manually and 441 dynamically based on some policies at the border router. 443 5.3 MPLS/GMPLS LSP Priority Mapping 445 In terms of signaling aspects, both MPLS and GMPLS LSPs are signaled 446 for specific setup and hold priority [RFC3209], [RFC3473], based on 447 the importance of traffic carried over them. For proper operation of 448 the network, it is desirable to create/use GMPLS LSPs of specified 449 setup and hold priority, based on the setup and hold priority of the 450 MPLS LSPs using them. In terms of routing aspects, unreserved 451 bandwidth sub-TLV is used for the amount of bandwidth not yet 452 reserved at each of the eight priority levels in MPLS domain 453 [RFC3630] and max lsp bandwidth at priority 0-7 in interface 454 switching capability descriptor sub-TLV is used for the amount of 455 bandwidth that can be reserved at each of the eight priority levels 456 in GMPLS domain [GMPLS-ospf-routing]. 458 In an MPLS/GMPLS interworking, if a GMPLS LSP is advertised into 459 IP/MPLS networks as an FA/RA, an LSR in the packet network can see it 460 a TE-link with unreserved bandwidth as advertised by the border 461 router. In this case, MPLS routers can select links that meet a 462 bandwidth depending on a priority level. 464 If MPLS signaling request contains a loose ERO, the GMPLS LSP 465 selection is a local decision at the border router. This is possible 466 in the case where GMPLS LSP is not advertised as an FA into IP/MPLS 467 networks. 468 In this case, following approaches are possible for mapping setup and 469 hold priority of MPLS LSPs to GMPLS FA-LSPs. These mapping functions 470 can be applied, either manually or dynamically, depending on some 471 policies at the border router. 473 1) Exact Match: In this case setup and hold priority of the GMPLS 474 FA-LSP is same as setup and hold priority of MPLS LSP using it. 475 In other words, GMPLS LSP Priority set = MPLS LSP Priority set. 477 2) Better Priority: In this case GMPLS FA-LSP can be of setup and 478 hold priority equal better than the MPLS LSP using it. In other 479 words, GMPLS LSP Priority set <= MPLS LSP Priority set. 481 3) Dynamic Priority for GMPLS LSP: In this case priority of GMPLS 482 LSP is dynamically changed based on priority of the MPLS LSPs 483 using it. In other words, GMPLS LSP Priority set = min (MPLS LSP 484 Priority set). 486 4) Any to Any Mapping Matrix: Based on some policies, it is possible 487 to have an any-to-any mapping for MPLS/GMPLS priority mapping at 488 the MPLS/GMPLS border router. 490 5) No Priority Management in GMPLS core: In this simple minded 491 approach all GMPLS LSPs can be establish with setup and hold 492 priority of "0", i.e., the GMPLS LSPs are already set as better 493 match. In this case, priority management is handled purely at 494 MPLS layer, with GMPLS network providing L1 connectivity without 495 priority management. 497 5.4 Signaling Protected MPLS LSPs 499 When MPLS LSPs are protected using MPLS-FRR mechanism [RFC4090] and 500 it may be desired to signal MPLS LSP such that it uses protected 501 GMPLS tunnel FA-LSPs. In this section we discuss MPLS/GMPLS 502 interworking aspect for protected MPLS LSPs. 504 In the case of loose ERO, where selection of GMPLS FA-LSP is a left 505 for the border nodes and "One-to-One backup desired" or "facility 506 backup desired" flag of the FAST REROUTE object, "Local protection 507 desired" and/or "bandwidth protection desired" and/or "node 508 protection desired" flag of the SESSION_ATTRIBUTE object is set, the 509 border router SHOULD try to map the signaling setup request to a 510 GMPLS LSP which is protected within GMPLS domain. However, in the 511 case of strict ERO, the selection of GMPLS FA-LSP is based on the 512 contents of the ERO and these flags are ignored. 514 When a GMPLS LSP is advertised as FA or RA in MPLS network, 515 Protection Capabilities attribute of the Link Protection Type is a 516 sub-TLV of the Link TLV can be used for selecting GMPLS LSP of 517 desired protection capability. 519 6. Operational Considerations 521 In this section, we discuss some operational considerations and pros 522 and cons associated with the individual options listed in Section 5.3. 524 6.1 Applicability of the Priority Management Options 526 In section 5.3, various options from exact match to no priority 527 management in GMPLS network are discussed. This section provides an 528 applicability of these options. 530 The benefit of Priority Management in GMPLS Core comes at the cost of 531 bandwidth fragmentation. E.g., in simplest approach of exact match, 532 we need at least as many GMPLS LSPs, as there are priority 533 combination in the network, while the other extreme of no priority 534 management in GMPLS network does allow full aggregation of MPLS 535 traffic on GMPLS FAs, i.e. avoids bandwidth fragmentation. If IGP 536 adjacency is to be established over the GMPLS LSPs, having more GMPLS 537 LSP leads to more links in the IGP/IP topology. The same is true of 538 MPLS TE topology with the exception that FA-LSPs can be bundled to 539 avoid flooding of multiple TE links. 541 With priority management within GMPLS network, there is a danger of 542 creating oscillations in the IP/MPLS network using GMPLS. This is 543 because when a new FA-LSP is established based on a local routing 544 decision made at the border router; we can have undesirable 545 preemption affecting MPLS LSPs carried over the GMPLS LSP that is 546 being preempted. This can have cascading affect leading to 547 oscillations on the operation of MPLS traffic. 549 6.2 Applicability of the Signaling Triggered Dynamic FA-LSP 551 In this section, we discussed applicability of static vs. dynamic FA- 552 LSPs. It is important to realize that we can have FA-LSPs that are 553 created dynamically based on triggers like configuration, link 554 utilization level, etc. However, in the context of this document, 555 such FA-LSPs are considered as static FAs. In this document, the term 556 dynamic FA-LSPs are used for FA-LSPs that are triggered by RSVP Path 557 message for MPLS LSP. 559 Signaling triggered dynamic FA-LSPs are addressing a problem space 560 where traffic pattern cannot be predicted or objective is to optimize 561 operations of the network based on actually signaled request rather 562 than predicted use of the network resource (i.e., off-line traffic 563 engineering). 565 The problem with the use of signaling triggered dynamic FA-LSPs is 566 that we loose ability to better aggregate the traffic request at the 567 border routers. This leads to potential cases of bandwidth 568 fragmentation inside GMPLS core, which has disadvantages discussed in 569 Section 6.1. Furthermore, signaling triggered dynamic FA-LSPs coupled 570 with preemption can lead to oscillations in the operation of the 571 network. This is because when a new FA-LSP is dynamically established 572 based on a local routing decision made at the border router; we can 573 have undesirable preemption affecting MPLS LSPs carried over the 574 GMPLS LSP that is being preempted. This can have cascading affect 575 leading to oscillations on the operation of MPLS traffic. 577 7. Backward Compatibility Note 579 The procedure presented in this document is backward compatible with 580 [RFC3630], [RFC3784], [RFC3209] and [RFC3473]. 582 8. Security Considerations 584 This document does not introduce new security issues. 586 9. Intellectual Property Considerations 588 The IETF takes no position regarding the validity or scope of any 589 Intellectual Property Rights or other rights that might be claimed to 590 pertain to the implementation or use of the technology described in 591 this document or the extent to which any license under such rights 592 might or might not be available; nor does it represent that it has 593 made any independent effort to identify any such rights. Information 594 on the procedures with respect to rights in RFC documents can be 595 found in BCP 78 and BCP 79. 597 Copies of IPR disclosures made to the IETF Secretariat and any 598 assurances of licenses to be made available, or the result of an 599 attempt made to obtain a general license or permission for the use of 600 such proprietary rights by implementers or users of this 601 specification can be obtained from the IETF on-line IPR repository at 602 http://www.ietf.org/ipr. 604 The IETF invites any interested party to bring to its attention any 605 copyrights, patents or patent applications, or other proprietary 606 rights that may cover technology that may be required to implement 607 this standard. Please address the information to the IETF at ietf- 608 ipr@ietf.org. 610 10.Acknowledgement 612 The author would like to express the thanks to Arthi Ayyangar for 613 helpful comments and feedback. 615 11.Reference 617 11.1 Normative Reference 619 [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, 620 RFC 3209, December 2001. 622 [RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering 623 (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. 625 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 626 RFC 2119, S. Bradner, March 1997. 628 [GMPLS-mig] "IP/MPLS - GMPLS interworking in support of IP/MPLS to 629 GMPLS migration", draft-oki-ccamp-gmpls-ip-interworking-05.txt, D. 630 Brungard, et al, February 2005. 632 [RFC3945] "Generalized Multi-Protocol Label Switching (GMPLS) 633 Architecture",RFC 3945, E. Mannie,October 2004. 635 11.2 Informative Reference 637 [GMPLS-routing] "Routing Extensions in Support of Generalized Multi- 638 Protocol Label Switching", draft-ietf-ccamp-gmpls-routing-09.txt 639 (work in progress), October 2003. 641 [GMPLS-ospf-routing] "OSPF Extensions in Support of Generalized 642 Multi-Protocol Label Switching", draft-ietf-ccamp-ospf-gmpls- 643 extensions-12.txt (work in progress), October 2003. 645 [RFC2205] "Resource Reservation Protocol (RSVP) - Version 1, 646 Functional Specification", RFC 2205, Braden, et al, September 1997. 648 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 649 Signaling Functional Description", RFC 3471, L. Berger, et al, 650 January 2003. 652 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 653 Signaling Resource Reservation Protocol-Traffic Engineering (RSVP- 654 TE) Extensions", RFC 3473, L. Berger, et al, January 2003. 656 [RFC4090] "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 657 4090, Pan, et al, May 2005. 659 12.Author's Addresses 661 Kenji Kumaki 662 KDDI Corporation 663 Garden Air Tower 664 Iidabashi, Chiyoda-ku, 665 Tokyo 102-8460, JAPAN 666 E-mail : ke-kumaki@kddi.com 668 Zafar Ali 669 Cisco systems, Inc., 670 2000 Innovation Drive Phone: 613 254 3498 671 Kanata, Ontario Email: zali@cisco.com 672 Canada K2K 3E8 674 Tomohiro Otani 675 KDDI R&D Laboratories, Inc. 676 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 677 Saitama, 356-8502. Japan Email: otani@kddilabs.jp 679 George Swallow 680 Cisco Systems, Inc. 681 1414 Massachusetts Ave, 682 Boxborough, MA 01719 683 Phone: +1 978 936 1398 684 Email: swallow@cisco.com 685 Mallik Tatipamula 686 Cisco systems, Inc., 687 170 W. Tasman Drive 688 San Jose, CA 95134 Phone: 408 525 4568 689 USA. Email: mallikt@cisco.com 691 13.Full Copyright Statement 693 Copyright (C) The Internet Society (2006). 695 This document is subject to the rights, licenses 696 and restrictions contained in BCP 78, and except as set forth 697 therein, the authors retain all their rights. 699 This document and the information contained herein are provided on an 700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 701 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 702 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 703 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 704 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.