idnits 2.17.1 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 745. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 343 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 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 (April 2006) is 6586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3209' is mentioned on line 679, but not defined == Missing Reference: 'RFC3630' is mentioned on line 136, but not defined == Missing Reference: 'INTER-DOM' is mentioned on line 429, but not defined == Missing Reference: 'MLN' is mentioned on line 445, but not defined == Missing Reference: 'MPLS-OVER-GMPLS' is mentioned on line 468, but not defined == Unused Reference: 'RFC4090' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'E2E-RECOVERY' is defined on line 829, but no explicit reference was found in the text == Unused Reference: 'TE-NODE-CAPS' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'STITCH' is defined on line 854, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kohei Shiomoto(NTT) 3 Internet Draft Dimitri Papadimitriou(Alcatel) 4 Proposed Category: Informational Jean-Louis Le Roux(France Telecom) 5 Expires: October 2006 Deborah Brungard (AT&T) 6 Kenji Kumaki (KDDI) 7 Zafar Ali (Cisco) 8 Eiji Oki(NTT) 9 Ichiro Inoue(NTT) 10 Tomohiro Otani (KDDI) 11 April 2006 13 Framework for MPLS-TE to GMPLS migration 14 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 The migration from Multiprotocol Label Switching (MPLS) Traffic 43 Engineering (TE) to Generalized MPLS (GMPLS) is the process of 44 evolving an MPLS-TE control plane to a GMPLS control plane. An 45 appropriate migration strategy can be selected based on various 46 factors including the service provider's network deployment plan, 47 customer demand, and operational policy. 49 This document presents several migration models and strategies for 50 migrating from MPLS-TE to GMPLS and notes that in the course of 51 migration MPLS-TE and GMPLS devices or networks may coexist which may 52 require interworking between MPLS-TE and GMPLS protocols. The 53 applicability? of the interworking that is required is discussed as 54 it appears to influence the choice of a migration strategy. 56 Table of Contents 58 1. Introduction...................................................3 59 2. Conventions Used in This Document..............................3 60 3. Motivations for Migration......................................4 61 4. MPLS to GMPLS Migration Models.................................5 62 4.1. Island model..............................................5 63 4.1.1. Balanced Islands.....................................6 64 4.1.2. Unbalanced Islands...................................6 65 4.2. Integrated model..........................................7 66 4.3. Phased model..............................................8 67 5. Migration Strategies and Solutions.............................9 68 5.1. Solutions Toolkit.........................................9 69 5.1.1. Layered Networks....................................10 70 - The overlay model preserves strict separation of routing 71 information between network layers. This is suitable for the 72 balanced island model and there is no requirement to handle 73 routing interworking. Signaling interworking is still required 74 as described for the peer model. The overlay model requires 75 the establishment of control plane connectivity for the higher 76 layer across the lower layer...............................10 77 5.1.2. Routing Interworking................................11 78 5.1.3. Signaling Interworking..............................12 79 6. Manageability Considerations..................................13 80 6.1. Control of Function and Policy...........................13 81 6.2. Information and Data Models..............................14 82 6.3. Liveness Detection and Monitoring........................14 83 6.4. Verifying Correct Operation..............................14 84 6.5. Requirements on Other Protocols and Functional Components14 85 6.6. Impact on Network Operation..............................15 86 6.7. Other Considerations.....................................15 87 7. Security Considerations.......................................15 88 8. Recommendations for Migration.................................16 89 9. IANA Considerations...........................................16 90 10. Full Copyright Statement.....................................16 91 11. Intellectual Property........................................16 92 12. Acknowledgements.............................................17 93 13. Authors' Addresses...........................................18 94 14. References...................................................19 95 14.1. Normative References....................................19 96 14.2. Informative References..................................20 98 1. Introduction 100 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to 101 Generalized MPLS (GMPLS) migration is the process of evolving an 102 MPLS-TE-based control plane to a GMPLS-based control plane. The 103 network under consideration is, therefore, a packet-switching network. 105 There are several motivations for such migration and they focus 106 mainly on the desire to take advantage of new features and functions 107 that have been added to the GMPLS protocols but which are not present 108 in MPLS-TE. 110 Although an appropriate migration strategy can be selected based on 111 various factors including the service provider's network deployment 112 plan, customer demand, deployed network equipments, operational 113 policy, etc., the transition mechanisms used should also provide 114 consistent operation of GMPLS networks while minimizing the impact on 115 the operation of existing MPLS-TE networks. 117 In the course of migration MPLS-TE and GMPLS devices or networks may 118 need to coexist. Such cases may occur as parts of the network are 119 migrated from MPLS-TE protocols to GMPLS protocols. Additionally, as 120 part of the preparation for migrating a packet-switching network from 121 MPLS-TE to GMPLS, it may be desirable to first migrate a lower-layer 122 network from having control plane to using a GMPLS control plane, and 123 this can also lead to the need for MPLS-TE/GMPLS interworking. 125 This document describes several migration strategies and shows the 126 interworking scenarios that arise during migration, and examines the 127 implications for network deployments and for protocol usage. Since 128 GMPLS signaling and routing protocols are different from the MPLS-TE 129 control protocols, interworking between MPLS-TE and GMPLS networks or 130 network elements needs mechanisms to compensate for the differences. 132 Note that MPLS-TE and GMPLS protocols can co-exist as "ships in the 133 night" without any interworking issue. 135 Also note that, in this document, the term "MPLS" is used to refer to 136 MPLS-TE protocols only ([RFC3209], [RFC3630], [RFC3473]) and excludes 137 other MPLS protocols such as the Label Distribution Protocol (LDP).TE 138 functionalities of MPLS could be migrated to GMPLS-TE, but non-TE 139 functionalities could not. 141 2. Conventions Used in This Document 143 This is not a requirements document, nevertheless the key words 144 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 145 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 146 are to be interpreted as described in RFC 2119 [RFC2119] in order to 147 clarify the recommendations that are made. 149 In the rest of this document, the term "GMPLS" includes both packet 150 switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" 151 or "non-PSC GMPLS" is explicitly used. 153 In general, the term "MPLS" is used to indicate MPLS traffic 154 engineering (MPLS-TE). If non-TE MPLS is intended, it is explicitly 155 indicated. 157 The reader is assumed to be familiar with the terminology introduced 158 in [RFC3945]. 160 3. Motivations for Migration 162 Motivations for migration will vary for different service providers. 163 This section is only presented to provide background so that the 164 migration discussions may be seen in the context. Sections 4 and 5 165 illustrate the migration models and processes with possible examples. 167 Migration of an MPLS-capable LSR to include GMPLS capabilities may be 168 performed for one or more reasons, including, no exhaustively: 170 o To add all GMPLS capabilities to an existing MPLS network. 172 o To add a GMPLS network without upgrading existing MPLS PSC LSRs. 174 o To pick up specific GMPLS features and operate them within an MPLS 175 PSC network. 177 o To allow existing MPLS-capable LSRs to interoperate with new LSRs 178 that only support GMPLS. 180 o To integrate multiple networks managed by separate administrative 181 organizations, which independently utilize MPLS or GMPLS. 183 o To build integrated PSC and non-PSC networks where the non-PSC 184 networks can only be controlled by GMPLS since MPLS does not 185 operate in non-PSC networks. 187 It must be understood that the ultimate objective of migration from 188 MPLS to GMPLS is that all LSRs and the entire network end up running 189 GMPLS protocols. During this process various interim situations may 190 exist giving rise to the interworking situations described in this 191 document. Those interim situations may persist for considerable 192 periods of time, but the ultimate objective is not to preserve these 193 situations, and for the purpose of this document, they should be 194 considered as temporary. 196 4. MPLS to GMPLS Migration Models 198 Three migration models are described below. Multiple migration models 199 may co-exists in the same network. 201 4.1. Island model 203 In the island model, "islands" of network nodes operating one 204 protocol exist within a "sea" of nodes using the other protocol. 206 The most obvious example is to consider an island of GMPLS-capable 207 nodes which is introduced into a legacy MPLS network. Such an island 208 might be composed of newly added GMPLS network nodes, or might arise 209 from the upgrade of existing nodes that previously operated MPLS 210 protocols. The opposite is also quite possible. That is, there is a 211 possibility that an island happens to be MPLS-capable within a GMPLS 212 sea. Such a situation might arise in the later stages of migration, 213 when all but a few islands of MPLS-capable nodes have been upgraded 214 to GMPLS. 216 It is also possible that a lower-layer, manually-provisioned network 217 (for example, a TDM network) supports an MPLS PSC network. During the 218 process of migrating both networks to GMPLS, the lower-layer network 219 might be migrated first. This would appear as a GMPLS island within 220 an MPLS sea. 222 Lastly, it is possible to consider individual nodes as islands. That 223 is, it would be possible to upgrade or insert an individual GMPLS- 224 capable node within an MPLS network, and to treat that GMPLS node as 225 an island. 227 Over time, collections of MPLS devices are replaced or upgraded to 228 create new GMPLS islands or to extend existing ones, and distinct 229 GMPLS islands may be joined together until the whole network is 230 GMPLS-capable. 232 From a migration/interworking point of view, we need to examine how 233 these islands are positioned and how LSPs run between the islands. 235 Four categories of interworking scenarios are considered: (1) MPLS- 236 GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS. 237 In case 1 the interworking behavior is examined based on whether the 238 GMPLS islands are PSC or non-PSC. 240 Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS 241 interworking. The model consists of a transit GMPLS island in an MPLS 242 sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and 243 G6) are referred to as "island border nodes". If the GMPLS island was 244 non-PSC, all nodes except the island border nodes in the GMPLS-based 245 transit island (G3 and G4) would be non-PSC devices, i.e., optical 246 equipment (TDM, LSC, and FSC). 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 MPLS-GMPLS-MPLS interworking. 265 4.1.1. Balanced Islands 267 In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end 268 using the same protocols. Available strategies include: 270 - tunneling the signaling across the island network using LSP 271 nesting or stitching (only with GMPLS-PSC) 273 - protocol interworking or mapping (only with GMPLS-PSC) 275 4.1.2. Unbalanced Islands 277 As just mentioned, there are two island interworking models 278 consisting of abutting islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) 279 islands cases are likely to arise where the migration strategy is not 280 based on a core infrastructure, but has edge nodes (ingress or 281 egress) located in islands of different capabilities. 283 In this case, an LSP starts or ends in a GMPLS (PSC) island and 284 correspondingly ends or starts in an MPLS island. This mode of 285 operation can only be addressed using protocol interworking or 286 mapping. Figure 2 shows the reference model for this migration 287 scenario. Head-end and tail-end LSR are in distinct control plane 288 clouds. 290 ............................ ............................. 291 : MPLS : : GMPLS (PSC) : 292 :+---+ +---+ +----+ +---+ +---+: 293 :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |: 294 :+---+ +---+ +----+ +-+-+ +---+: 295 : ______/ | _____/ : : ______/ | ______/ : 296 : / | / : : / | / : 297 :+---+ +---+ +----+ +-+-+ +---+: 298 :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |: 299 :+---+ +---+ +----+ +---+ +---+: 300 :..........................: :...........................: 302 |<-------------------------------------------------->| 303 e2e LSP 305 Figure 2 GMPLS-MPLS interworking model. 307 It is important to underline that this scenario is also impacted by 308 the directionality of the LSP, and the direction in which the LSP is 309 established. 311 4.2. Integrated model 313 The second migration model involves a more integrated migration 314 strategy. New devices that are capable of operating both MPLS and 315 GMPLS protocols are introduced into the MPLS network. 317 In the island model, a GMPLS-capable device does not support the MPLS 318 protocols except border nodes , while in the integrated model there 319 are two types of node present during migration: 321 - those that support MPLS only (legacy nodes) 323 - those that support MPLS and GMPLS. 325 In the island model only island border nodes may support both MPLS 326 and GMPLS while in the integrated model all GMPLS LSRs also support 327 MPLS. 329 That is, in integrated model, existing MPLS devices are upgraded to 330 support both MPLS and GMPLS. The network continues to provide MPLS 331 services, and also offers GMPLS services. So, where one end point of 332 a service is a legacy MPLS node, the service is supported using MPLS 333 protocols. Similarly, where the selected path between end points 334 traverses a legacy node that is not GMPLS-capable, MPLS protocols are 335 used. But where the service can be provided using only GMPLS-capable 336 nodes, it may be routed accordingly and can achieve a higher level of 337 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 elements. 343 In this model, the questions to be addressed concern the co-existence 344 of the two protocol sets within the network. Actual interworking is 345 not a concern. 347 4.3. Phased model 349 The phased model introduces GMPLS features and protocol elements into 350 an MPLS network one by one. For example, some object or sub-object 351 (such as the ERO label sub-object, [RFC3473]) might be introduced 352 into the signaling used by LSRs that are otherwise MPLS-capable. This 353 would produce a kind of hybrid LSR. 355 This approach may appear simpler to implement as one is able to 356 quickly and easily pick up key new functions without needing to 357 upgrade the whole protocol implementation. It is most likely to be 358 used where there is a desire to rapidly implement a particular 359 function within a network without the necessity to install and test 360 the full GMPLS function. 362 Interoperability concerns are exacerbated by this migration model, 363 unless all LSRs in the network are updated simultaneously and there 364 is a clear understanding of which subset of features are to be 365 included in the hybrid LSRs. Interworking between a hybrid LSR and an 366 unchanged MPLS LSR would put the hybrid in the role of a GMPLS LSR as 367 described in the previous sections and puts the hybrid in the role of 368 an MPLS LSR. The potential for different hybrids within the network 369 will complicate matters considerably. 371 5. Migration Strategies and Solutions 373 An appropriate migration strategy is selected by a network operator 374 based on factors including the service provider's network deployment 375 plan, customer demand, existing network equipment, operational policy, 376 support from its vendors, etc. 378 For PSC networks, the migration strategy involves the selection 379 between the models described in the previous section. The choice will 380 depend upon the final objective (full GMPLS capability, partial 381 upgrade to include specific GMPLS features, or no change to existing 382 IP/MPLS networks), and upon the immediate objectives (full, phased, 383 or staged upgrade). 385 For PSC networks serviced by non-PSC networks, two basic migration 386 strategies can be considered. In the first strategy, the non-PSC 387 network is made GMPLS-capable first and then the PSC network is 388 migrated to GMPLS. This might arise when, in order to expand the 389 network capacity, GMPLS-based non-PSC sub-networks are introduced 390 into or underneath the legacy MPLS-based networks. Subsequently, the 391 legacy MPLS-based PSC network is migrated to be GMPLS-capable as 392 described in the previous paragraph. Finally the entire network, 393 including both PSC and non-PSC nodes, may be controlled by GMPLS. 395 The second strategy for PSC and non-PSC networks is to migrate from 396 the PSC network to GMPLS first and then enable GMPLS within the non- 397 PSC network. The PSC network is migrated as described before, and 398 when the entire PSC network is completely converted to GMPLS, GMPLS- 399 based non-PSC devices and networks may be introduced without any 400 issues of interworking between MPLS and GMPLS. 402 These migration strategies and the migration models described in the 403 previous section are not necessarily mutually exclusive. Mixtures of 404 all strategies and models could be applied. The migration models and 405 strategies selected will give rise to one or more of the interworking 406 cases described in the following section. 408 5.1. Solutions Toolkit 410 As described in the previous sections, an essential part of a 411 migration and deployment strategy is how the MPLS and GMPLS or hybrid 412 LSRs interwork. This section sets out some of the alternatives for 413 achieving interworking between MPLS and GMPLS, and points out some of 414 the issues that need to be addressed if the alternatives are adopted. 415 This document does not describe solutions to these issues. 417 Note that it is possible to consider upgrading the routing and 418 signaling capabilities of LSRs from MPLS to GMPLS separately. 420 5.1.1. Layered Networks 422 In the balanced island model, LSP tunnels [RFC4206] is a solution to 423 carry the end-to-end LSPs across islands of incompatible nodes. 424 Network layering is often used to separate domains of different data 425 plane technology. It can also be used to separate domains of 426 different control plane technology (such as MPLS and GMPLS protocols), 427 and the solutions developed for multiple data plane technologies can 428 be usefully applied to this situation [RFC3945], [RFC4206], and 429 [INTER-DOM]. [MLN-REQ] gives a discussion of the requirements for 430 multi-layered networks. 432 The GMPLS architecture [RFC3945] identifies three architectural 433 models for supporting multi-layer GMPLS networks, and these models 434 may be applied to the separation of MPLS and GMPLS control plane 435 islands. 437 - In the peer model, both MPLS and GMPLS nodes run the same routing 438 instance, and routing advertisements from within islands of one 439 level of protocol support are distributed to the whole network. 440 This is achievable only as described in section 5.1.2 either by 441 direct distribution or by mapping of parameters. 443 Signaling in the peer model may result in contiguous LSPs, 444 stitched LSPs (only for GMPLS PSC), or nested LSPs. If the network 445 islands are non-PSC then the techniques of [MLN] may be applied, 446 and these techniques may be extrapolated to networks where all 447 nodes are PSC, but where there is a difference in signaling 448 protocols. 450 - The overlay model preserves strict separation of routing 451 information between network layers. This is suitable for the 452 balanced island model and there is no requirement to handle 453 routing interworking. Even though the overlay model preserves 454 separation of signaling information between network layers, there 455 may be some interaction in signaling between network layers. 457 The overlay model requires the establishment of control plane 458 connectivity for the higher layer across the lower layer. 460 - The augmented model allows limited routing exchange from the lower 461 layer network to the higher layer network. Generally speaking, 462 this assumes that the border nodes provide some form of filtering, 463 mapping or aggregation of routing information advertised from the 464 lower layer network. This architectural model can also be used for 465 balanced island model migrations. Signaling interworking is 466 required as described for the peer model. 468 - The border peer architecture model is defined in [MPLS-OVER-GMPLS]. 469 This is a modification of the augmented model where the layer 470 border routers have visibility into both layers, but no routing 471 information is otherwise exchanged between models. This 472 architectural model is particularly suited to the MPLS-GMPLS-MPLS 473 island model for PSC and non-PSC GMPLS islands. Signaling 474 interworking is required as described for the peer model. 476 5.1.2. Routing Interworking 478 Migration strategies may necessitate some interworking between MPLS 479 and GMPLS routing protocols. GMPLS extends the TE information 480 advertised by the IGPs to include non-PSC information and extended 481 PSC information. Because the GMPLS information is provided as 482 additional TLVs that are carried along with the MPLS information, 483 MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS 484 PSC LSRs. They will also see other GMPLS information, but will ignore 485 it, flooding it transparently across the MPLS network for use by 486 other GMPLS LSRs. 488 - Routing separation is achieved in the overlay, and border peer 489 models. This is convenient since only the border nodes need to be 490 aware of the different protocol variants, and no mapping is 491 required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS- 492 GMPLS island migration models. 494 - Direct distribution involves the flooding of MPLS routing 495 information into a GMPLS network, and GMPLS routing information 496 into an MPLS network. The border nodes make no attempt to filter 497 the information. This mode of operation relies on the fact that 498 MPLS routers will ignore, but continue to flood, GMPLS routing 499 information that they do not understand. The presence of 500 additional GMPLS routing information will not interfere with the 501 way that MPLS LSRs select routes, and although this is not a 502 problem in a PSC-only network, it could cause problems in a peer 503 architecture network that includes non-PSC nodes as the MPLS nodes 504 are not capable of determining the switching types of the other 505 LSRs and will attempt to signal end-to-end LSPs assuming all LSRs 506 to be PSC. This fact would require island border nodes to take 507 triggered action to set up tunnels across islands of different 508 switching capabilities. 510 GMPLS LSRs might be impacted by the absence of GMPLS-specific 511 information in advertisements initiated by MPLS LSRs. Specific 512 procedures might be required to ensure consistent behavior by 513 GMPLS nodes. If this issue is addressed, then direct distribution 514 can be used in all migration models (except the overlay and border 515 peer architectural models where the problem does not arise). 517 - Protocol mapping converts routing advertisements so that they can 518 be received in one protocol and transmitted in the other. For 519 example, a GMPLS routing advertisement could have all of its 520 GMPLS-specific information removed and could be flooded as an MPLS 521 advertisement. This mode of interworking would require careful 522 standardization of the correct behavior especially where an MPLS 523 advertisement requires default values of GMPLS-specific fields to 524 be generated before the advertisement can be flooded further. 525 There is also considerable risk of confusion in closely meshed 526 networks where many LSRs have MPLS and GMPLS capable interfaces. 527 This option for routing interworking during migration is NOT 528 RECOMMENDED for any migration model. 530 - Ships in the night refers to a mode of operation where both MPLS 531 and GMPLS routing protocol variants are operated in the same 532 network at the same time as separate routing protocol instances. 533 The two instances are independent and are used to create routing 534 adjacencies between LSRs of the same type. This mode of operation 535 may be appropriate to the integrated migration model. 537 5.1.3. Signaling Interworking 539 Signaling protocols are used to establish LSPs and are the principal 540 concern for interworking during migration. Issues of compatibility 541 arise because of simple changes in the encodings and codepoints used 542 by MPLS and GMPLS signaling, but also because of changes in function 543 levels provided by MPLS and GMPLS. 545 - Tunneling and stitching (GMPLS-PSC case) mechanisms are a good way 546 to avoid any requirement for direct protocol interworking during 547 migration in the island model because protocol elements are 548 transported transparently across migration islands without being 549 inspected. However, care may be needed to achieve functional 550 mapping in these modes of operation since one set of features must 551 be carried across a network designed to support a different set of 552 features. In general, this is easily achieved for the MPLS-GMPLS- 553 MPLS model, but may be hard to achieve in the GMPLS-MPLS-GMPLS 554 model for example, when end-to-end bidirectional LSPs are 555 requested since the MPLS island does not support bidirectional 556 LSPs. 558 Note that tunneling and stitching are not available in unbalanced 559 island models because in these cases the LSP end points use 560 different protocol variants. 562 - Protocol mapping is the conversion of signaling messages between 563 MPLS and GMPLS variants. This mechanism requires careful 564 documentation of the protocol fields and how they are mapped, but 565 is relatively simple in the MPLS-GMPLS unbalanced island model. 566 However, the MPLS-GMPLS island model may manifest as the GMPLS- 567 MPLS model for LSPs signaled in the opposite direction and this 568 will lead to considerable complications for providing GMPLS 569 services over the MPLS island and for terminating those services 570 at an egress LSR that is not GMPLS-capable. Further, in balanced 571 island models, and in particular where there are multiple small 572 (individual node) islands, the repeated conversion of signaling 573 parameters may lead to loss of information or mis-requests. 575 - Ships in the night could be used in the integrated migration model 576 to allow MPLS-capable LSRs to establish LSPs using MPLS signaling 577 protocols and GMPLS LSRs to establish LSPs using GMPLS signaling 578 protocols. LSRs that can handle both sets of protocols could play 579 a part in either case, but no conversion of protocols would be 580 applied. 582 6. Manageability Considerations 584 Attention should be given during migration planning to how the 585 network will be managed during and after migration. For example, will 586 the LSRs of different protocol capabilities be managed separately or 587 as a whole. This is most clear in the Island Model where it is 588 possible to consider managing islands of one capability separately 589 from the surrounding sea. In the case of islands that have different 590 switching capabilities, it is possible that the islands already had 591 different management in place before the migration: the resultant 592 migrated network may seek to merge the management or to preserve it. 594 6.1. Control of Function and Policy 596 The most important control to be applied is at the moment of 597 changeover between different levels of protocol support. Such a 598 change may be made dynamically or during a period of network 599 maintenance. 601 Where island boundaries exist, it must be possible to manage the 602 relationships between protocols and to indicate which interfaces 603 support which protocols on a border LSR. Further, island borders are 604 a natural place to apply policy, and management should allow 605 configuration of such policies. 607 6.2. Information and Data Models 609 No special information or data models are required to support 610 migration, but note that migration in the control plane implies 611 migration from MPLS management tools to GMPLS management tools. 612 During migration, therefore, it may be necessary for LSRs and 613 management applications to support both MPLS and GMPLS variants of 614 management data. 616 The GMPLS MIB modules are designed to allow support of the MPLS 617 protocols and build on the MPLS MIB modules through extensions and 618 augmentations. This may make it possible to migrate management 619 applications ahead of the LSRs that they manage. 621 6.3. Liveness Detection and Monitoring 623 Migration will not imposes additional issues for OAM above those that 624 already exist for inter-domain OAM and for OAM across multiple 625 switching capabilities. 627 Note, however, that if a flat PSC MPLS network is migrated using the 628 island model, and is treated as a layered network using tunnels to 629 connect across GMPLS islands, then requirements for a multi-layer OAM 630 technique may be introduced into what was previously defined in the 631 flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking 632 may be described in more detail in a later version. 634 6.4. Verifying Correct Operation 636 The concerns for verifying correct operation (and in particular 637 correct connectivity) are the same as for liveness detection and 638 monitoring. Principally, the process of migration may introduce 639 tunneling or stitching into what was previously a flat network. 641 6.5. Requirements on Other Protocols and Functional Components 643 No particular requirements are introduced on other protocols. As it 644 has been observed, the management components may need to migrate in 645 step with the control plane components, but this does not impact the 646 management protocols, just the data that they carry. 648 It should also be observed that providing signaling and routing 649 connectivity across a migration island in support of a layered 650 architecture may require the use of protocol tunnels (such as GRE) 651 between island border nodes. Such tunnels may impose additional 652 configuration requirements at the border nodes. 654 6.6. Impact on Network Operation 656 The process of migration is likely to have significant impact on 657 network operation while migration is in progress. The main objective 658 of migration planning should be to reduce the impact on network 659 operation and on the services perceived by the network users. 661 To this end, planners should consider reducing the number of 662 migration steps that they perform, and minimizing the number of 663 migration islands that are created. 665 A network manager may prefer the island model especially when 666 migration will extend over a significant operational period because 667 it allows the different network islands to be administered as 668 separate management domains. This is particularly the case in the 669 overlay and augmented network models where the details of the 670 protocol islands remain hidden from the surrounding LSRs. 672 6.7. Other Considerations 674 A migration strategy may also imply moving an MPLS state to a GMPLS 675 state for an in-service LSP. This may arise once all of the LSRs 676 along the path of the LSP have been updated to be both MPLS and 677 GMPLS-capable. Signaling mechanisms to achieve the replacement of an 678 MPLS LSP with a GMPLS LSP without disrupting traffic exist through 679 make-before-break procedures [RFC3209] and [RFC3473], and should be 680 carefully managed under operator control. 682 7. Security Considerations 684 Security and confidentiality is often applied (and attacked) at 685 administrative boundaries. Some of the models described in this 686 document introduce such boundaries, for example between MPLS and 687 GMPLS islands. These boundaries offer the possibility of applying or 688 modifying the security as one might when crossing an IGP area or AS 689 boundary, even though these island boundaries might lie within an IGP 690 area or AS. 692 No changes are proposed to the security procedures built into MPLS 693 and GMPLS signaling and routing. GMPLS signaling and routing inherit 694 their security mechanisms from MPLS signaling and routing without any 695 changes. Hence, there will be no issues with security in interworking 696 scenarios. Further, since the MPLS and GMPLS signaling and routing 697 security is provided on a hop-by-hop basis, and since all signaling 698 and routing exchanges described in this document for use between any 699 pair of LSRs are based on either MPLS or GMPLS, there are no changes 700 necessary to the security procedures. 702 8. IANA Considerations 704 This informational framework document makes no requests for IANA 705 action. 707 9. Full Copyright Statement 709 Copyright (C) The Internet Society (2006). 711 This document is subject to the rights, licenses and restrictions 712 contained in BCP 78, and except as set forth therein, the authors 713 retain all their rights. 715 This document and the information contained herein are provided on an 716 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 717 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 718 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 719 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 720 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 721 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 723 10. Intellectual Property 725 The IETF takes no position regarding the validity or scope of any 726 Intellectual Property Rights or other rights that might be claimed to 727 pertain to the implementation or use of the technology described in 728 this document or the extent to which any license under such rights 729 might or might not be available; nor does it represent that it has 730 made any independent effort to identify any such rights. Information 731 on the procedures with respect to rights in RFC documents can be 732 found in BCP 78 and BCP 79. 734 Copies of IPR disclosures made to the IETF Secretariat and any 735 assurances of licenses to be made available, or the result of an 736 attempt made to obtain a general license or permission for the use of 737 such proprietary rights by implementers or users of this 738 specification can be obtained from the IETF on-line IPR repository at 739 http://www.ietf.org/ipr. 741 The IETF invites any interested party to bring to its attention any 742 copyrights, patents or patent applications, or other proprietary 743 rights that may cover technology that may be required to implement 744 this standard. Please address the information to the IETF at ietf- 745 ipr@ietf.org. 747 11. Acknowledgements 749 The authors are grateful to Daisaku Shimazaki for discussion during 750 initial work on this document. The authors are grateful to Dean Cheng 751 for his valuable comments. 753 12. Authors' Addresses 755 Kohei Shiomoto, Editor 756 NTT 757 Midori 3-9-11 758 Musashino, Tokyo 180-8585, Japan 759 Phone: +81 422 59 4402 760 Email: shiomoto.kohei@lab.ntt.co.jp 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.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-ft.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 Kenji Kumaki 784 KDDI Corporation 785 Garden Air Tower 786 Iidabashi, Chiyoda-ku, 787 Tokyo 102-8460, JAPAN 788 Phone: +81-3-6678-3103 789 Email: ke-kumaki@kddi.com 791 Zafar Alli 792 Cisco Systems, Inc. 793 EMail: zali@cisco.com 795 Eiji Oki 796 NTT 797 Midori 3-9-11 798 Musashino, Tokyo 180-8585, Japan 799 Phone: +81 422 59 3441 800 Email: oki.eiji@lab.ntt.co.jp 802 Ichiro Inoue 803 NTT 804 Midori 3-9-11 805 Musashino, Tokyo 180-8585, Japan 806 Phone: +81 422 59 3441 807 Email: inoue.ichiro.lab.ntt.co.jp 809 Tomohiro Otani 810 KDDI Laboratories 811 Email: otani@kddilabs.jp 813 13. References 815 13.1. Normative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels," BCP 14, IETF RFC 2119, March 1997. 820 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions 821 to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 823 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 824 Architecture", RFC 3945, October 2004. 826 [SEGMENT-RECOVERY]Berger, L., "GMPLS Based Segment Recovery", draft- 827 ietf-ccamp-gmpls-segment-recovery, work in progress. 829 [E2E-RECOVERY] Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), 830 " RSVP-TE Extensions in support of End-to-End Generalized 831 Multi-Protocol Label Switching (GMPLS)-based Recovery", 832 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in 833 progress. 835 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 836 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 837 Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. 839 [TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol 840 Extensions for Discovery of Traffic Engineering Node Capabilities", 841 draft-ietf-ccamp-te-node-cap, work in progress. 843 13.2. Informative References 845 [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, 846 M., Brungard, D., "Requirements for GMPLS-based multi- 847 region and multi-layer networks (MRN/MLN)", draft-ietf- 848 ccamp-gmpls-mln-reqs, work in progress. 850 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) 851 Hierarchy with Generalized Multi-Protocol Label Switching 852 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 854 [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching 855 with Generalized MPLS Traffic Engineering", draft-ietf- 856 ccamp-lsp-stitching, work in progress.