idnits 2.17.1 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 912. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 925. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2008) is 5947 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Shiomoto(Editor) 2 Internet Draft (NTT) 3 Intended Status: Informational 4 Created: January 13, 2008 5 Expires: July 13, 2008 7 Framework for MPLS-TE to GMPLS migration 8 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The migration from Multiprotocol Label Switching (MPLS) Traffic 36 Engineering (TE) to Generalized MPLS (GMPLS) is the process of 37 evolving an MPLS-TE control plane to a GMPLS control plane. An 38 appropriate migration strategy will be selected based on various 39 factors including the service provider's network deployment plan, 40 customer demand, and operational policy. 42 This document presents several migration models and strategies for 43 migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE 44 and GMPLS devices, or networks, may coexist which may require 45 interworking between MPLS-TE and GMPLS protocols. Aspects of the 46 interworking required are discussed as it will influence the choice 47 of a migration strategy. This framework document provides a migration 48 toolkit to aid the operator in selection of an appropriate strategy. 50 This framework document also lists a set of solutions that may aid in 51 interworking, and highlights a set of potential issues. 53 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 55 Table of Contents 57 1. Introduction.................................................... 2 58 2. Conventions Used in This Document............................... 3 59 3. Motivations for Migration....................................... 4 60 4. MPLS to GMPLS Migration Models.................................. 4 61 4.1. Island Model............................................... 5 62 4.1.1. Balanced Islands...................................... 6 63 4.1.2. Unbalanced Islands.................................... 6 64 4.2. Integrated Model........................................... 7 65 4.3. Phased Model............................................... 8 66 5. Migration Strategies and Toolkit................................ 8 67 5.1. Migration Toolkit.......................................... 9 68 5.1.1. Layered Networks...................................... 9 69 5.1.2. Routing Interworking................................. 11 70 5.1.3. Signaling Interworking............................... 12 71 5.1.4. Path Computation Element............................. 13 72 6. Manageability Considerations................................... 13 73 6.1. Control of Function and Policy............................ 13 74 6.2. Information and Data Models............................... 14 75 6.3. Liveness Detection and Monitoring......................... 14 76 6.4. Verifying Correct Operation............................... 14 77 6.5. Requirements on Other Protocols and Functional Components. 14 78 6.6. Impact on Network Operation............................... 15 79 6.7. Other Considerations...................................... 15 80 7. Security Considerations........................................ 15 81 8. IANA Considerations............................................ 16 82 9. Acknowledgements............................................... 16 83 10. Editor's Addresses............................................ 16 84 11. Authors' Addresses............................................ 16 85 12. References.................................................... 17 86 12.1. Normative References..................................... 17 87 12.2. Informative References................................... 18 88 13. Full Copyright Statement...................................... 19 89 14. Intellectual Property......................................... 19 91 1. Introduction 93 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to 94 Generalized MPLS (GMPLS) migration is the process of evolving an 95 MPLS-TE-based control plane to a GMPLS-based control plane. The 96 network under consideration for migration is, therefore, a packet- 97 switching network. 99 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 101 There are several motivations for such migration, mainly the desire 102 to take advantage of new features and functions added to the GMPLS 103 protocols and which are not present in MPLS-TE for packet networks. 104 Additionally, before migrating a packet-switching network from MPLS- 105 TE to GMPLS, one may choose to first migrate a lower-layer network 106 with no control plane (e.g. controlled by a management plane) to 107 using a GMPLS control plane, and this may lead to the desire for 108 MPLS-TE/GMPLS (transport network) interworking to provide enhanced TE 109 support and facilitate the later migration of the packet-switching 110 network. 112 Although an appropriate migration strategy will be selected based on 113 various factors including the service provider's network deployment 114 plan, customer demand, deployed network equipments, operational 115 policy, etc., the transition mechanisms used should also provide 116 consistent operation of newly introduced GMPLS networks, while 117 minimizing the impact on the operation of existing MPLS-TE networks. 119 This document describes several migration strategies and the 120 interworking scenarios that arise during migration. It also examines 121 the implications for network deployments and for protocol usage. As 122 the GMPLS signaling and routing protocols are different from the 123 MPLS-TE control protocols, interworking mechanisms between MPLS-TE 124 and GMPLS networks, or network elements, may be needed to compensate 125 for the differences. 127 Note that MPLS-TE and GMPLS protocols can co-exist as "ships in the 128 night" without any interworking issue. 130 2. Conventions Used in This Document 132 This is not a requirements document, nevertheless the key words 133 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 134 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 135 are to be interpreted as described in RFC 2119 [RFC2119] in order to 136 clarify the recommendations that are made. 138 In the rest of this document, the term "GMPLS" includes both packet 139 switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" 140 or "non-PSC GMPLS" is explicitly used. 142 In general, the term "MPLS" is used to indicate MPLS traffic 143 engineering (MPLS-TE) only ([RFC3209], [RFC3630], [RFC3784]) and 144 excludes other MPLS protocols such as the Label Distribution Protocol 145 (LDP). TE functionalities of MPLS could be migrated to GMPLS, but 146 non-TE functionalities could not. If non-TE MPLS is intended, it is 147 explicitly indicated. 149 The reader is assumed to be familiar with the terminology introduced 150 in [RFC3945]. 152 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 154 3. Motivations for Migration 156 Motivations for migration will vary for different service providers. 157 This section is presented to provide background so that the migration 158 discussions may be seen in context. Sections 4 and 5 provide examples 159 to illustrate the migration models and processes. 161 Migration of an MPLS-capable LSR to include GMPLS capabilities may be 162 performed for one or more reasons, including, not exhaustively: 164 o To add all GMPLS PSC features to an existing MPLS network (upgrade 165 MPLS LSRs). 167 o To add specific GMPLS PSC features and operate them within an MPLS 168 network (ex. [RFC4872] [RFC4873]). 170 o To integrate a new GMPLS PSC network with an existing MPLS network 171 (without upgrading any of the MPLS LSRs). 173 o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs 174 supporting only GMPLS PSC and/or non-PSC features. 176 o To integrate multiple control networks, e.g. managed by separate 177 administrative organizations, and which independently utilize MPLS 178 or GMPLS. 180 o To build integrated PSC and non-PSC networks. The non-PSC networks 181 are controlled by GMPLS. 183 The objective of migration from MPLS to GMPLS is that all LSRs, and 184 the entire network, support GMPLS protocols. During this process, 185 various interim situations may exist, giving rise to the interworking 186 situations described in this document. The interim situations may 187 exist for considerable periods of time, but the ultimate objective is 188 not to preserve these situations. For the purposes of this document, 189 they should be considered as temporary and transitory. 191 4. MPLS to GMPLS Migration Models 193 Three reference migration models are described below. Multiple 194 migration models may co-exist in the same network. 196 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 198 4.1. Island Model 200 In the island model, "islands" of network nodes operating one 201 protocol exist within a "sea" of nodes using the other protocol. 203 For example, consider an island of GMPLS-capable nodes (PSC) which is 204 introduced into a legacy MPLS network. Such an island might be 205 composed of newly added GMPLS nodes, or might arise from the upgrade 206 of existing nodes that previously operated MPLS protocols. 208 The opposite is also quite possible. That is, there is a possibility 209 that an island happens to be MPLS-capable within a GMPLS sea. Such a 210 situation might arise in the later stages of migration, when all but 211 a few islands of MPLS-capable nodes have been upgraded to GMPLS. 213 It is also possible that a lower-layer, manually-provisioned network 214 (for example, a TDM network) is constructed under an MPLS PSC 215 network. During the process of migrating both networks to GMPLS, the 216 lower-layer network might be migrated first. This would appear as a 217 GMPLS island within an MPLS sea. 219 Lastly, it is possible to consider individual nodes as islands. That 220 is, it would be possible to upgrade or insert an individual GMPLS- 221 capable node within an MPLS network, and to treat that GMPLS node as 222 an island. 224 Over time, collections of MPLS devices are replaced or upgraded to 225 create new GMPLS islands or to extend existing ones, and distinct 226 GMPLS islands may be joined together until the whole network is 227 GMPLS-capable. 229 From a migration/interworking point of view, we need to examine how 230 these islands are positioned and how LSPs connect between the 231 islands. 233 Four categories of interworking scenarios are considered: (1) MPLS- 234 GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS. 235 In case 1, the interworking behavior is examined based on whether the 236 GMPLS islands are PSC or non-PSC. 238 Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS 239 interworking. The model consists of a transit GMPLS island in an MPLS 240 sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and 241 G6) are referred to as "island border nodes". If the GMPLS island was 242 non-PSC, all nodes except the island border nodes in the GMPLS-based 243 transit island (G3 and G4) would be non-PSC devices, i.e., optical 244 equipment (TDM, LSC, and FSC). 246 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 248 ................. .......................... .................. 249 : MPLS : : GMPLS : : MPLS : 250 :+---+ +---+ +----+ +---+ +----+ +---+ +---+: 251 :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |: 252 :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: 253 : ________/ : : _______/ | _____ / : : ________/ : 254 : / : : / | / : : / : 255 :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: 256 :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |: 257 :+---+ +---+ +----+ +---+ +----+ +---+ +---+: 258 :................: :........................: :................: 260 |<-------------------------------------------------------->| 261 e2e LSP 263 Figure 1 : Example of the island model for 264 MPLS-GMPLS-MPLS interworking. 266 4.1.1. Balanced Islands 268 In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end 269 using the same protocols. Possible strategies include: 271 - tunneling the signaling across the island network using LSP 272 nesting or stitching [STITCH] (the latter is for only with GMPLS- 273 PSC) 275 - protocol interworking or mapping (both are for only with GMPLS- 276 PSC) 278 4.1.2. Unbalanced Islands 280 As previously discussed, there are two island interworking models 281 which support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) 282 island cases are likely to arise where the migration strategy is not 283 based on a core infrastructure, but has edge nodes (ingress or 284 egress) located in islands of different capabilities. 286 In this case, an LSP starts or ends in a GMPLS (PSC) island and 287 correspondingly ends or starts in an MPLS island. This mode of 288 operation can only be addressed using protocol interworking or 289 mapping. Figure 2 shows the reference model for this migration 290 scenario. Head-end and tail-end LSR are in distinct control plane 291 clouds. 293 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 295 ............................ ............................. 296 : MPLS : : GMPLS (PSC) : 297 :+---+ +---+ +----+ +---+ +---+: 298 :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |: 299 :+---+ +---+ +----+ +-+-+ +---+: 300 : ______/ | _____/ : : ______/ | ______/ : 301 : / | / : : / | / : 302 :+---+ +---+ +----+ +-+-+ +---+: 303 :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |: 304 :+---+ +---+ +----+ +---+ +---+: 305 :..........................: :...........................: 307 |<-------------------------------------------------->| 308 e2e LSP 310 Figure 2 : GMPLS-MPLS interworking model. 312 It is important to underline that this scenario is also impacted by 313 the directionality of the LSP, and the direction in which the LSP is 314 established. 316 4.2. Integrated Model 318 The second migration model involves a more integrated migration 319 strategy. New devices that are capable of operating both MPLS and 320 GMPLS protocols are introduced into the MPLS network. 322 In the integrated model there are two types of nodes present during 323 migration: 325 - support MPLS only (legacy nodes) 327 - support MPLS and GMPLS. 329 In this model, as existing MPLS devices are upgraded to support both 330 MPLS and GMPLS, the network continues to operate with a MPLS control 331 plane, but some LSRs are also capable of operating with a GMPLS 332 control plane. So, LSPs are provisioned using MPLS protocols where 333 one end point of a service is a legacy MPLS node and/or where the 334 selected path between end points traverses a legacy node that is not 335 GMPLS-capable. But where the service can be provided using only 336 GMPLS-capable nodes [RFC5073], it may be routed accordingly and can 337 achieve a higher level of functionality by utilizing GMPLS features. 339 Once all devices in the network are GMPLS-capable, the MPLS specific 340 protocol elements may be turned off, and no new devices need to 341 support these protocol elements. 343 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 345 In this model, the questions to be addressed concern the co-existence 346 of the two protocol sets within the network. Actual interworking is 347 not a concern. 349 4.3. Phased Model 351 The phased model introduces GMPLS features and protocol elements into 352 an MPLS network one by one. For example, some objects or sub-objects 353 (such as the ERO label sub-object, [RFC3473]) might be introduced 354 into the signaling used by LSRs that are otherwise MPLS-capable. This 355 would produce a kind of hybrid LSR. 357 This approach may appear simpler to implement as one is able to 358 quickly and easily pick up key new functions without needing to 359 upgrade the whole protocol implementation. It is most likely to be 360 used where there is a desire to rapidly implement a particular 361 function within a network without the necessity to install and test 362 the full GMPLS function. 364 Interoperability concerns though are exacerbated by this migration 365 model, unless all LSRs in the network are updated simultaneously and 366 there is a clear understanding of which subset of features are to be 367 included in the hybrid LSRs. Interworking between a hybrid LSR and an 368 unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS 369 LSR as described in the previous sections and puts the unchanged LSR 370 in the role of an MPLS LSR. The potential for different hybrids 371 within the network will complicate matters considerably. This model 372 is, therefore, only appropriate for use when the set of new features 373 to be deployed is well known and limited, and where there is a clear 374 understanding of and agreement on this set of features by the network 375 operators of the ISP(s) involved as well as all vendors whose 376 equipment will be involved in the migration. 378 5. Migration Strategies and Toolkit 380 An appropriate migration strategy is selected by a network operator 381 based on factors including the service provider's network deployment 382 plan, customer demand, existing network equipment, operational 383 policy, support from its vendors, etc. 385 For PSC networks, the migration strategy involves the selection 386 between the models described in the previous section. The choice will 387 depend upon the final objective (full GMPLS capability, partial 388 upgrade to include specific GMPLS features, or no change to existing 389 IP/MPLS networks), and upon the immediate objectives (full, phased, 390 or staged upgrade). 392 For PSC networks serviced by non-PSC networks, two basic migration 393 strategies can be considered. In the first strategy, the non-PSC 394 network is made GMPLS-capable, first, and then the PSC network is 395 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 397 migrated to GMPLS. This might arise when, in order to expand the 398 network capacity, GMPLS-based non-PSC sub-networks are introduced 399 into the legacy MPLS-based networks. Subsequently, the legacy MPLS- 400 based PSC network is migrated to be GMPLS-capable as described in the 401 previous paragraph. Finally the entire network, including both PSC 402 and non-PSC nodes, may be controlled by GMPLS. 404 The second strategy is to migrate the PSC network to GMPLS first, and 405 then enable GMPLS within the non-PSC network. The PSC network is 406 migrated as described before, and when the entire PSC network is 407 completely converted to GMPLS, GMPLS-based non-PSC devices and 408 networks may be introduced without any issues of interworking between 409 MPLS and GMPLS. 411 These migration strategies and the migration models described in the 412 previous section are not necessarily mutually exclusive. Mixtures of 413 all strategies and models could be applied. The migration models and 414 strategies selected will give rise to one or more of the interworking 415 cases described in the following section. 417 5.1. Migration Toolkit 419 As described in the previous sections, an essential part of a 420 migration and deployment strategy is how the MPLS and GMPLS or hybrid 421 LSRs interwork. This section sets out some of the alternatives for 422 achieving interworking between MPLS and GMPLS, and identifies some of 423 the issues that need to be addressed. This document does not describe 424 solutions to these issues. 426 Note that it is possible to consider upgrading the routing and 427 signaling capabilities of LSRs from MPLS to GMPLS separately. 429 5.1.1. Layered Networks 431 In the balanced island model, LSP tunnels [RFC4206] are a solution to 432 carry the end-to-end LSPs across islands of incompatible nodes. 433 Network layering is often used to separate domains of different data 434 plane technology. It can also be used to separate domains of 435 different control plane technology (such as MPLS and GMPLS 436 protocols), and the solutions developed for multiple data plane 437 technologies can be usefully applied to this situation [RFC3945], 438 [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the 439 requirements for multi-layered networks. 441 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 443 The GMPLS architecture [RFC3945] identifies three architectural 444 models for supporting multi-layer GMPLS networks, and these models 445 may be applied to the separation of MPLS and GMPLS control plane 446 islands. 448 - In the peer model, both MPLS and GMPLS nodes run the same routing 449 instance, and routing advertisements from within islands of one 450 level of protocol support are distributed to the whole network. 451 This is achievable only as described in section 5.1.2 either by 452 direct distribution or by mapping of parameters. 454 Signaling in the peer model may result in contiguous LSPs, 455 stitched LSPs [STITCH] (only for GMPLS PSC), or nested LSPs. If 456 the network islands are non-PSC then the techniques of [MLN-REQ] 457 may be applied, and these techniques may be extrapolated to 458 networks where all nodes are PSC, but where there is a difference 459 in signaling protocols. 461 - The overlay model preserves strict separation of routing 462 information between network layers. This is suitable for the 463 balanced island model and there is no requirement to handle 464 routing interworking. Even though the overlay model preserves 465 separation of signaling information between network layers, there 466 may be some interaction in signaling between network layers. 468 The overlay model requires the establishment of control plane 469 connectivity for the higher layer across the lower layer. 471 - The augmented model allows limited routing exchange from the lower 472 layer network to the higher layer network. Generally speaking, 473 this assumes that the border nodes provide some form of filtering, 474 mapping or aggregation of routing information advertised from the 475 lower layer network. This architectural model can also be used for 476 balanced island model migrations. Signaling interworking is 477 required as described for the peer model. 479 - The border peer architecture model is defined in [MPLS-OVER-GMPLS]. 480 This is a modification of the augmented model where the layer 481 border routers have visibility into both layers, but no routing 482 information is otherwise exchanged between routing protocol 483 instances. This architectural model is particularly suited to the 484 MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands. 485 Signaling interworking is required as described for the peer model. 487 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 489 5.1.2. Routing Interworking 491 Migration strategies may necessitate some interworking between MPLS 492 and GMPLS routing protocols. GMPLS extends the TE information 493 advertised by the IGPs to include non-PSC information and extended 494 PSC information. Because the GMPLS information is provided as 495 additional TLVs that are carried along with the MPLS information, 496 MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS 497 PSC LSRs. They will also see other GMPLS information, but will ignore 498 it, flooding it transparently across the MPLS network for use by 499 other GMPLS LSRs. 501 - Routing separation is achieved in the overlay and border peer 502 models. This is convenient since only the border nodes need to be 503 aware of the different protocol variants, and no mapping is 504 required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS- 505 GMPLS island migration models. 507 - Direct distribution involves the flooding of MPLS routing 508 information into a GMPLS network, and GMPLS routing information 509 into an MPLS network. The border nodes make no attempt to filter 510 the information. This mode of operation relies on the fact that 511 MPLS routers will ignore, but continue to flood, GMPLS routing 512 information that they do not understand. The presence of 513 additional GMPLS routing information will not interfere with the 514 way that MPLS LSRs select routes, and although this is not a 515 problem in a PSC-only network, it could cause problems in a peer 516 architecture network that includes non-PSC nodes as the MPLS nodes 517 are not capable of determining the switching types of the other 518 LSRs and will attempt to signal end-to-end LSPs assuming all LSRs 519 to be PSC. This fact would require island border nodes to take 520 triggered action to set up tunnels across islands of different 521 switching capabilities. 523 GMPLS LSRs might be impacted by the absence of GMPLS-specific 524 information in advertisements initiated by MPLS LSRs. Specific 525 procedures might be required to ensure consistent behavior by 526 GMPLS nodes. If this issue is addressed, then direct distribution 527 can be used in all migration models (except the overlay and border 528 peer architectural models where the problem does not arise). 530 - Protocol mapping converts routing advertisements so that they can 531 be received in one protocol and transmitted in the other. For 532 example, a GMPLS routing advertisement could have all of its 533 GMPLS-specific information removed and could be flooded as an MPLS 534 advertisement. This mode of interworking would require careful 535 standardization of the correct behavior especially where an MPLS 536 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 538 advertisement requires default values of GMPLS-specific fields to 539 be generated before the advertisement can be flooded further. 540 There is also considerable risk of confusion in closely meshed 541 networks where many LSRs have MPLS and GMPLS capable interfaces. 542 This option for routing interworking during migration is NOT 543 RECOMMENDED for any migration model. Note that converting GMPLS- 544 specific sub-TLVs to MPLS-specific ones but not stripping the 545 GMPLS-specific ones is considered as a variant of the proposed 546 solution in the previous bullet (Unknown sub-TLVs should be 547 ignored [RFC3630] but must continue to be flooded). 549 - Ships in the night refers to a mode of operation where both MPLS 550 and GMPLS routing protocol variants are operated in the same 551 network at the same time as separate routing protocol instances. 552 The two instances are independent and are used to create routing 553 adjacencies between LSRs of the same type. This mode of operation 554 may be appropriate to the integrated migration model. 556 5.1.3. Signaling Interworking 558 Signaling protocols are used to establish LSPs and are the principal 559 concern for interworking during migration. Issues of compatibility 560 arise because of differences in the encodings and codepoints used by 561 MPLS and GMPLS signaling, but also because of differences in 562 functionality provided by MPLS and GMPLS. 564 - Tunneling and stitching [STITCH] (GMPLS-PSC case) mechanisms 565 provide the potential to avoid direct protocol interworking during 566 migration in the island model, because protocol elements are 567 transported transparently across migration islands without being 568 inspected. However, care may be needed to achieve functional 569 mapping in these modes of operation since one set of features may 570 need to be supported across a network designed to support a 571 different set of features. In general, this is easily achieved for 572 the MPLS-GMPLS-MPLS model, but may be hard to achieve in the 573 GMPLS-MPLS-GMPLS model. For example, when end-to-end bidirectional 574 LSPs are requested, since the MPLS island does not support 575 bidirectional LSPs. 577 Note that tunneling and stitching are not available in unbalanced 578 island models because in these cases the LSP end points use 579 different protocols. 581 - Protocol mapping is the conversion of signaling messages between 582 MPLS and GMPLS. This mechanism requires careful documentation of 583 the protocol fields and how they are mapped. This is relatively 584 straightforward in the MPLS-GMPLS unbalanced island model for LSPs 585 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 587 signaled in the MPLS-GMPLS direction. However, it may be more 588 complex for LSPs signaled in the opposite direction, and this will 589 lead to considerable complications for providing GMPLS services 590 over the MPLS island and for terminating those services at an 591 egress LSR that is not GMPLS-capable. Further, in balanced island 592 models, and in particular where there are multiple small 593 (individual node) islands, the repeated conversion of signaling 594 parameters may lead to loss of information (and functionality) or 595 mis-requests. 597 - Ships in the night could be used in the integrated migration model 598 to allow MPLS-capable LSRs to establish LSPs using MPLS signaling 599 protocols and GMPLS LSRs to establish LSPs using GMPLS signaling 600 protocols. LSRs that can handle both sets of protocols could work 601 with both types of LSRs, and no conversion of protocols would be 602 needed. 604 5.1.4. Path Computation Element 606 The Path Computation Element (PCE) [RFC4655] may provide an 607 additional tool to aid MPLS to GMPLS migration. If a layered network 608 approach (Section 5.1.1) is used, PCEs may be used to facilitate the 609 computation of paths for LSPs in the different layers 610 [PCE-INTER-LAYER]. 612 6. Manageability Considerations 614 Attention should be given during migration planning to how the 615 network will be managed during and after migration. For example, will 616 the LSRs of different protocol capabilities be managed separately or 617 as one management domain. For example, in the Island Model, it is 618 possible to consider managing islands of one capability separately 619 from the surrounding sea. In the case of islands that have different 620 switching capabilities, it is possible that the islands already have 621 separate management in place before the migration: the resultant 622 migrated network may seek to merge the management or to preserve the 623 separation. 625 6.1. Control of Function and Policy 627 The most critical control functionality to be applied is at the 628 moment of changeover between different levels of protocol support. 629 Such a change may be made without service halt or during a period of 630 network maintenance. 632 Where island boundaries exist, it must be possible to manage the 633 relationships between protocols and to indicate which interfaces 634 support which protocols on a border LSR. Further, island borders are 635 a natural place to apply policy, and management should allow 636 configuration of such policies. 638 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 640 6.2. Information and Data Models 642 No special information or data models are required to support 643 migration, but note that migration in the control plane implies 644 migration from MPLS management tools to GMPLS management tools. 645 During migration, therefore, it may be necessary for LSRs and 646 management applications to support both MPLS and GMPLS management 647 data. 649 The GMPLS MIB modules are designed to allow support of the MPLS 650 protocols and built on the MPLS MIB modules through extensions and 651 augmentations. This may make it possible to migrate management 652 applications ahead of the LSRs that they manage. 654 6.3. Liveness Detection and Monitoring 656 Migration will not impose additional issues for OAM above those that 657 already exist for inter-domain OAM and for OAM across multiple 658 switching capabilities. 660 Note, however, that if a flat PSC MPLS network is migrated using the 661 island model, and is treated as a layered network using tunnels to 662 connect across GMPLS islands, then requirements for a multi-layer OAM 663 technique may be introduced into what was previously defined in the 664 flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking 665 will need further consideration. 667 6.4. Verifying Correct Operation 669 The concerns for verifying correct operation (and in particular 670 correct connectivity) are the same as for liveness detection and 671 monitoring. Specifically, the process of migration may introduce 672 tunneling or stitching [STITCH] into what was previously a flat 673 network. 675 6.5. Requirements on Other Protocols and Functional Components 677 No particular requirements are introduced on other protocols. As it 678 has been observed, the management components may need to migrate in 679 step with the control plane components, but this does not impact the 680 management protocols, just the data that they carry. 682 It should also be observed that providing signaling and routing 683 connectivity across a migration island in support of a layered 684 architecture may require the use of protocol tunnels (such as GRE) 685 between island border nodes. Such tunnels may impose additional 686 configuration requirements at the border nodes. 688 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 690 6.6. Impact on Network Operation 692 The process of migration is likely to have significant impact on 693 network operation while migration is in progress. The main objective 694 of migration planning should be to reduce the impact on network 695 operation and on the services perceived by the network users. 697 To this end, planners should consider reducing the number of 698 migration steps that they perform, and minimizing the number of 699 migration islands that are created. 701 A network manager may prefer the island model especially when 702 migration will extend over a significant operational period because 703 it allows the different network islands to be administered as 704 separate management domains. This is particularly the case in the 705 overlay, augmented network and border peer models where the details 706 of the protocol islands remain hidden from the surrounding LSRs. 708 6.7. Other Considerations 710 A migration strategy may also imply moving an MPLS state to a GMPLS 711 state for an in-service LSP. This may arise once all of the LSRs 712 along the path of the LSP have been updated to be both MPLS and 713 GMPLS-capable. Signaling mechanisms to achieve the replacement of an 714 MPLS LSP with a GMPLS LSP without disrupting traffic exist through 715 make-before-break procedures [RFC3209] and [RFC3473], and should be 716 carefully managed under operator control. 718 7. Security Considerations 720 Security and confidentiality is often applied (and attacked) at 721 administrative boundaries. Some of the models described in this 722 document introduce such boundaries, for example between MPLS and 723 GMPLS islands. These boundaries offer the possibility of applying or 724 modifying the security as when crossing an IGP area or AS boundary, 725 even though these island boundaries might lie within an IGP area or 726 AS. 728 No changes are proposed to the security procedures built into MPLS 729 and GMPLS signaling and routing. GMPLS signaling and routing inherit 730 their security mechanisms from MPLS signaling and routing without any 731 changes. Hence, there will be no additional issues with security in 732 interworking scenarios. Further, since the MPLS and GMPLS signaling 733 and routing security is provided on a hop-by-hop basis, and since all 734 signaling and routing exchanges described in this document for use 735 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 737 between any pair of LSRs are based on either MPLS or GMPLS, there are 738 no changes necessary to the security procedures. 740 8. IANA Considerations 742 This informational framework document makes no requests for IANA 743 action. 745 9. Acknowledgements 747 The authors are grateful to Daisaku Shimazaki for discussion during 748 initial work on this document. The authors are grateful to Dean Cheng 749 and Adrian Farrel for their valuable comments. 751 10. Editor's Addresses 753 Kohei Shiomoto, Editor 754 NTT 755 Midori 3-9-11 756 Musashino, Tokyo 180-8585, Japan 757 Phone: +81 422 59 4402 758 Email: shiomoto.kohei@lab.ntt.co.jp 760 11. Authors' Addresses 762 Dimitri Papadimitriou 763 Alcatel 764 Francis Wellensplein 1, 765 B-2018 Antwerpen, Belgium 766 Phone: +32 3 240 8491 767 Email: dimitri.papadimitriou@alcatel-lucent.be 769 Jean-Louis Le Roux 770 France Telecom 771 av Pierre Marzin 22300 772 Lannion, France 773 Phone: +33 2 96 05 30 20 774 Email: jeanlouis.leroux@orange-ftgroup.com 776 Deborah Brungard 777 AT&T 778 Rm. D1-3C22 - 200 S. Laurel Ave. 779 Middletown, NJ 07748, USA 780 Phone: +1 732 420 1573 781 Email: dbrungard@att.com 783 Zafar Alli 784 Cisco Systems, Inc. 785 EMail: zali@cisco.com 786 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 788 Kenji Kumaki 789 KDDI Corporation 790 Garden Air Tower 791 Iidabashi, Chiyoda-ku, 792 Tokyo 102-8460, JAPAN 793 Phone: +81-3-6678-3103 794 Email: ke-kumaki@kddi.com 796 Eiji Oki 797 NTT 798 Midori 3-9-11 799 Musashino, Tokyo 180-8585, Japan 800 Phone: +81 422 59 3441 801 Email: oki.eiji@lab.ntt.co.jp 803 Ichiro Inoue 804 NTT 805 Midori 3-9-11 806 Musashino, Tokyo 180-8585, Japan 807 Phone: +81 422 59 3441 808 Email: inoue.ichiro@lab.ntt.co.jp 810 Tomohiro Otani 811 KDDI Laboratories 812 Email: otani@kddilabs.jp 814 12. References 816 12.1. Normative References 818 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 819 Requirement Levels," BCP 14, IETF RFC 2119, March 1997. 821 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 822 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 823 Tunnels", RFC 3209, December 2001. 825 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 826 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 827 Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. 829 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 830 (TE) Extensions to OSPF Version 2", RFC 3630, September 831 2003. 833 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 834 System (IS-IS) Extensions for Traffic Engineering (TE)", 835 RFC 3784, June 2004. 837 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 839 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 840 Architecture", RFC 3945, October 2004. 842 [RFC4872] Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), " 843 RSVP-TE Extensions in support of End-to-End Generalized 844 Multi-Protocol Label Switching (GMPLS)-based Recovery", 845 RFC4872, May 2007. 847 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., 848 "GMPLS Based Segment Recovery", RFC 4873, May 2007. 850 [RFC5073] Vasseur, Le Roux, editors, "IGP Routing Protocol 851 Extensions for Discovery of Traffic Engineering Node 852 Capabilities", RFC 5073, Decemer 2007. 854 12.2. Informative References 856 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) 857 Hierarchy with Generalized Multi-Protocol Label Switching 858 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 860 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 861 Element (PCE)-Based Architecture", RFC 4655, August 2006. 863 [RFC4726] Farrel, A., Vasseur, J.P., Ayyangar, A., " A Framework for 864 Inter-Domain Multiprotocol Label Switching Traffic 865 Engineering", RFC4726, November 2006. 867 [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, 868 M., Brungard, D., "Requirements for GMPLS-based multi- 869 region and multi-layer networks (MRN/MLN)", draft-ietf- 870 ccamp-gmpls-mln-reqs, work in progress. 872 [MPLS-OVER-GMPLS] Kumaki, K., et al., " Interworking Requirements to 873 Support operation of MPLS-TE over GMPLS networks", draft- 874 ietf-ccamp-mpls-gmpls-interwork-reqts, work in progress. 876 [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A., "Framework 877 for PCE-Based Inter-Layer MPLS and GMPLS Traffic 878 Engineering," draft-ietf-pce-inter-layer-frwk, work in 879 progress. 881 [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching 882 with Generalized MPLS Traffic Engineering", draft-ietf- 883 ccamp-lsp-stitching, work in progress. 885 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 887 13. Full Copyright Statement 889 Copyright (C) The IETF Trust (2008). 891 This document is subject to the rights, licenses and restrictions 892 contained in BCP 78, and except as set forth therein, the authors 893 retain all their rights. 895 This document and the information contained herein are provided on an 896 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 897 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 898 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 899 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 900 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 901 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 903 14. Intellectual Property 905 The IETF takes no position regarding the validity or scope of any 906 Intellectual Property Rights or other rights that might be claimed to 907 pertain to the implementation or use of the technology described in 908 this document or the extent to which any license under such rights 909 might or might not be available; nor does it represent that it has 910 made any independent effort to identify any such rights. Information 911 on the procedures with respect to rights in RFC documents can be 912 found in BCP 78 and BCP 79. 914 Copies of IPR disclosures made to the IETF Secretariat and any 915 assurances of licenses to be made available, or the result of an 916 attempt made to obtain a general license or permission for the use of 917 such proprietary rights by implementers or users of this 918 specification can be obtained from the IETF on-line IPR repository at 919 http://www.ietf.org/ipr. 921 The IETF invites any interested party to bring to its attention any 922 copyrights, patents or patent applications, or other proprietary 923 rights that may cover technology that may be required to implement 924 this standard. Please address the information to the IETF at ietf- 925 ipr@ietf.org.