idnits 2.17.1 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 860. 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 338 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 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 2007) is 6304 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3209' is mentioned on line 672, but not defined == Missing Reference: 'RFC3630' is mentioned on line 519, but not defined == Missing Reference: 'RFC3784' is mentioned on line 141, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'MLN' is mentioned on line 432, but not defined == Unused Reference: 'RFC4090' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'TE-NODE-CAPS' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'STITCH' is defined on line 810, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kohei Shiomoto(Editor) 3 Internet Draft (NTT) 4 Proposed Category: Informational 5 Expires: July 2007 6 January 2007 8 Framework for MPLS-TE to GMPLS migration 9 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet-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 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The migration from Multiprotocol Label Switching (MPLS) Traffic 38 Engineering (TE) to Generalized MPLS (GMPLS) is the process of 39 evolving an MPLS-TE control plane to a GMPLS control plane. An 40 appropriate migration strategy will be selected based on various 41 factors including the service provider's network deployment plan, 42 customer demand, and operational policy. 44 This document presents several migration models and strategies for 45 migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE 46 and GMPLS devices, or networks, may coexist which may require 47 interworking between MPLS-TE and GMPLS protocols. Aspects of the 48 interworking required are discussed as it will influence the choice 49 of a migration strategy. This framework document provides a migration 50 toolkit to aid the operator in selection of an appropriate strategy. 52 This framework document also lists a set of solutions that may aid in 53 interworking, and highlights a set of potential issues. 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 Solutions.............................8 67 5.1. Solutions Toolkit.........! ................. 68 Layered Networks...........................................9 69 5.1.1.......................................................9 70 5.1.2. Routing Interworking................................11 71 5.1.3. Signaling Interworking..............................12 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 Components14 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...........................................17 84 11. Authors' Addresses...........................................17 85 12. References...................................................18 86 12.1. Normative References....................................18 87 12.2. Informative References..................................19 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 There are several motivations for such migration, mainly the desire 100 to take advantage of new features and functions added to the GMPLS 101 protocols and which are not present in MPLS-TE for packet networks. 102 Additionally, before migrating a packet-switching network from MPLS- 103 TE to GMPLS, one may choose to first migrate a lower-layer network 104 with no control plane (e.g. controlled by a management plane) to 105 using a GMPLS control plane, and this may lead to the desire for 106 MPLS-TE/GMPLS (transport network) interworking to provide enhanced TE 107 support and facilitate the later migration of the packet-switching 108 network. 110 Although an appropriate migration strategy will 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 newly introduced GMPLS networks, while 115 minimizing the impact on the operation of existing MPLS-TE networks. 117 This document describes several migration strategies and the 118 interworking scenarios that arise during migration. It also examines 119 the implications for network deployments and for protocol usage. As 120 the GMPLS signaling and routing protocols are different from the 121 MPLS-TE control protocols, interworking mechanisms between MPLS-TE 122 and GMPLS networks, or network elements, may be needed to compensate 123 for the differences. 125 Note that MPLS-TE and GMPLS protocols can co-exist as "ships in the 126 night" without any interworking issue. 128 2. Conventions Used in This Document 130 This is not a requirements document, nevertheless the key words 131 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 132 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 133 are to be interpreted as described in RFC 2119 [RFC2119] in order to 134 clarify the recommendations that are made. 136 In the rest of this document, the term "GMPLS" includes both packet 137 switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" 138 or "non-PSC GMPLS" is explicitly used. 140 In general, the term "MPLS" is used to indicate MPLS traffic 141 engineering (MPLS-TE) only ([RFC3209], [RFC3630], [RFC3784]) and 142 excludes other MPLS protocols such as the Label Distribution Protocol 143 (LDP). TE functionalities of MPLS could be migrated to GMPLS, but 144 non-TE functionalities could not. If non-TE MPLS is intended, it is 145 explicitly indicated. 147 The reader is assumed to be familiar with the terminology introduced 148 in [RFC3945]. 150 3. Motivations for Migration 152 Motivations for migration will vary for different service providers. 153 This section is presented to provide background so that the migration 154 discussions may be seen in context. Sections 4 and 5 provide examples 155 to illustrate the migration models and processes. 157 Migration of an MPLS-capable LSR to include GMPLS capabilities may be 158 performed for one or more reasons, including, not exhaustively: 160 o To add all GMPLS PSC features to an existing MPLS network (upgrade 161 MPLS LSRs). 163 o To add specific GMPLS PSC features and operate them within an MPLS 164 network. 166 o To integrate a new GMPLS PSC network with an existing MPLS network 167 (without upgrading any of the MPLS LSRs). 169 o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs 170 supporting only GMPLS PSC and/or non-PSC features. 172 o To integrate multiple control networks, e.g. managed by separate 173 administrative organizations, and which independently utilize MPLS 174 or GMPLS. 176 o To build integrated PSC and non-PSC networks. The non-PSC networks 177 are controlled by GMPLS. 179 The objective of migration from MPLS to GMPLS is that all LSRs, and 180 the entire network, support GMPLS protocols. During this process, 181 various interim situations may exist, giving rise to the interworking 182 situations described in this document. The interim situations may 183 exist for considerable periods of time, but the ultimate objective is 184 not to preserve these situations. For the purposes of this document, 185 they should be considered as temporary and transitory. 187 4. MPLS to GMPLS Migration Models 189 Three reference migration models are described below. Multiple 190 migration models may co-exist in the same network. 192 4.1. Island model 194 In the island model, "islands" of network nodes operating one 195 protocol exist within a "sea" of nodes using the other protocol. 197 For example, consider an island of GMPLS-capable nodes (PSC) which is 198 introduced into a legacy MPLS network. Such an island might be 199 composed of newly added GMPLS nodes, or might arise from the upgrade 200 of existing nodes that previously operated MPLS protocols. 202 The opposite is also quite possible. That is, there is a possibility 203 that an island happens to be MPLS-capable within a GMPLS sea. Such a 204 situation might arise in the later stages of migration, when all but 205 a few islands of MPLS-capable nodes have been upgraded to GMPLS. 207 It is also possible that a lower-layer, manually-provisioned network 208 (for example, a TDM network) is constructed under an MPLS PSC network. 209 During the process of migrating both networks to GMPLS, the lower- 210 layer network might be migrated first. This would appear as a GMPLS 211 island within an MPLS sea. 213 Lastly, it is possible to consider individual nodes as islands. That 214 is, it would be possible to upgrade or insert an individual GMPLS- 215 capable node within an MPLS network, and to treat that GMPLS node as 216 an island. 218 Over time, collections of MPLS devices are replaced or upgraded to 219 create new GMPLS islands or to extend existing ones, and distinct 220 GMPLS islands may be joined together until the whole network is 221 GMPLS-capable. 223 From a migration/interworking point of view, we need to examine how 224 these islands are positioned and how LSPs connect between the islands. 226 Four categories of interworking scenarios are considered: (1) MPLS- 227 GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS. 228 In case 1, the interworking behavior is examined based on whether the 229 GMPLS islands are PSC or non-PSC. 231 Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS 232 interworking. The model consists of a transit GMPLS island in an MPLS 233 sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and 234 G6) are referred to as "island border nodes". If the GMPLS island was 235 non-PSC, all nodes except the island border nodes in the GMPLS-based 236 transit island (G3 and G4) would be non-PSC devices, i.e., optical 237 equipment (TDM, LSC, and FSC). 239 ................. .......................... .................. 240 : MPLS : : GMPLS : : MPLS : 241 :+---+ +---+ +----+ +---+ +----+ +---+ +---+: 242 :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |: 243 :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: 244 : ________/ : : _______/ | _____ / : : ________/ : 245 : / : : / | / : : / : 246 :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: 247 :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |: 248 :+---+ +---+ +----+ +---+ +----+ +---+ +---+: 249 :................: :........................: :................: 251 |<-------------------------------------------------------->| 252 e2e LSP 254 Figure 1 Example of the island model for MPLS-GMPLS-MPLS interworking. 256 4.1.1. Balanced Islands 258 In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end 259 using the same protocols. Possible strategies include: 261 - tunneling the signaling across the island network using LSP 262 nesting or stitching (the latter is for only with GMPLS-PSC) 264 - protocol interworking or mapping (both are for only with GMPLS- 265 PSC) 267 4.1.2. Unbalanced Islands 269 As previously discussed, there are two island interworking models 270 which support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) 271 island cases are likely to arise where the migration strategy is not 272 based on a core infrastructure, but has edge nodes (ingress or 273 egress) located in islands of different capabilities. 275 In this case, an LSP starts or ends in a GMPLS (PSC) island and 276 correspondingly ends or starts in an MPLS island. This mode of 277 operation can only be addressed using protocol interworking or 278 mapping. Figure 2 shows the reference model for this migration 279 scenario. Head-end and tail-end LSR are in distinct control plane 280 clouds. 282 ............................ ............................. 283 : MPLS : : GMPLS (PSC) : 284 :+---+ +---+ +----+ +---+ +---+: 285 :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |: 286 :+---+ +---+ +----+ +-+-+ +---+: 287 : ______/ | _____/ : : ______/ | ______/ : 288 : / | / : : / | / : 289 :+---+ +---+ +----+ +-+-+ +---+: 290 :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |: 291 :+---+ +---+ +----+ +---+ +---+: 292 :..........................: :...........................: 294 |<-------------------------------------------------->| 295 e2e LSP 297 Figure 2 GMPLS-MPLS interworking model. 299 It is important to underline that this scenario is also impacted by 300 the directionality of the LSP, and the direction in which the LSP is 301 established. 303 4.2. Integrated model 305 The second migration model involves a more integrated migration 306 strategy. New devices that are capable of operating both MPLS and 307 GMPLS protocols are introduced into the MPLS network. 309 In the integrated model there are two types of nodes present during 310 migration: 312 - support MPLS only (legacy nodes) 314 - support MPLS and GMPLS. 316 In this model, as existing MPLS devices are upgraded to support both 317 MPLS and GMPLS, the network continues to operate with a MPLS control 318 plane, but some LSRs are also capable of operating with a GMPLS 319 control plane. So, LSPs are provisioned using MPLS protocols where 320 one end point of a service is a legacy MPLS node and/or where the 321 selected path between end points traverses a legacy node that is not 322 GMPLS-capable. But where the service can be provided using only 323 GMPLS-capable nodes, it may be routed accordingly and can achieve a 324 higher level of functionality by utilizing GMPLS features. 326 Once all devices in the network are GMPLS-capable, the MPLS specific 327 protocol elements may be turned off, and no new devices need to 328 support these protocol elements. 330 In this model, the questions to be addressed concern the co-existence 331 of the two protocol sets within the network. Actual interworking is 332 not a concern. 334 4.3. Phased model 336 The phased model introduces GMPLS features and protocol elements into 337 an MPLS network one by one. For example, some objects or sub-objects 338 (such as the ERO label sub-object, [RFC3473]) might be introduced 339 into the signaling used by LSRs that are otherwise MPLS-capable. This 340 would produce a kind of hybrid LSR. 342 This approach may appear simpler to implement as one is able to 343 quickly and easily pick up key new functions without needing to 344 upgrade the whole protocol implementation. It is most likely to be 345 used where there is a desire to rapidly implement a particular 346 function within a network without the necessity to install and test 347 the full GMPLS function. 349 Interoperability concerns though are exacerbated by this migration 350 model, unless all LSRs in the network are updated simultaneously and 351 there is a clear understanding of which subset of features are to be 352 included in the hybrid LSRs. Interworking between a hybrid LSR and an 353 unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS 354 LSR as described in the previous sections and puts the unchanged LSR 355 in the role of an MPLS LSR. The potential for different hybrids 356 within the network will complicate matters considerably. 358 5. Migration Strategies and Toolkit 360 An appropriate migration strategy is selected by a network operator 361 based on factors including the service provider's network deployment 362 plan, customer demand, existing network equipment, operational policy, 363 support from its vendors, etc. 365 For PSC networks, the migration strategy involves the selection 366 between the models described in the previous section. The choice will 367 depend upon the final objective (full GMPLS capability, partial 368 upgrade to include specific GMPLS features, or no change to existing 369 IP/MPLS networks), and upon the immediate objectives (full, phased, 370 or staged upgrade). 372 For PSC networks serviced by non-PSC networks, two basic migration 373 strategies can be considered. In the first strategy, the non-PSC 374 network is made GMPLS-capable, first, and then the PSC network is 375 migrated to GMPLS. This might arise when, in order to expand the 376 network capacity, GMPLS-based non-PSC sub-networks are introduced 377 into the legacy MPLS-based networks. Subsequently, the legacy MPLS- 378 based PSC network is migrated to be GMPLS-capable as described in the 379 previous paragraph. Finally the entire network, including both PSC 380 and non-PSC nodes, may be controlled by GMPLS. 382 The second strategy for PSC and non-PSC networks is to migrate from 383 the PSC network to GMPLS, first, and then enable GMPLS within the 384 non-PSC network. The PSC network is migrated as described before, and 385 when the entire PSC network is completely converted to GMPLS, GMPLS- 386 based non-PSC devices and networks may be introduced without any 387 issues of interworking between MPLS and GMPLS. 389 These migration strategies and the migration models described in the 390 previous section are not necessarily mutually exclusive. Mixtures of 391 all strategies and models could be applied. The migration models and 392 strategies selected will give rise to one or more of the interworking 393 cases described in the following section. 395 5.1. Migration Toolkit 397 As described in the previous sections, an essential part of a 398 migration and deployment strategy is how the MPLS and GMPLS or hybrid 399 LSRs interwork. This section sets out some of the alternatives for 400 achieving interworking between MPLS and GMPLS, and identifies some of 401 the issues that need to be addressed. This document does not describe 402 solutions to these issues. 404 Note that it is possible to consider upgrading the routing and 405 signaling capabilities of LSRs from MPLS to GMPLS separately. 407 5.1.1. Layered Networks 409 In the balanced island model, LSP tunnels [RFC4206] are a solution to 410 carry the end-to-end LSPs across islands of incompatible nodes. 411 Network layering is often used to separate domains of different data 412 plane technology. It can also be used to separate domains of 413 different control plane technology (such as MPLS and GMPLS protocols), 414 and the solutions developed for multiple data plane technologies can 415 be usefully applied to this situation [RFC3945], [RFC4206], and 416 [RFC4726]. [MLN-REQ] gives a discussion of the requirements for 417 multi-layered networks. 419 The GMPLS architecture [RFC3945] identifies three architectural 420 models for supporting multi-layer GMPLS networks, and these models 421 may be applied to the separation of MPLS and GMPLS control plane 422 islands. 424 - In the peer model, both MPLS and GMPLS nodes run the same routing 425 instance, and routing advertisements from within islands of one 426 level of protocol support are distributed to the whole network. 427 This is achievable only as described in section 5.1.2 either by 428 direct distribution or by mapping of parameters. 430 Signaling in the peer model may result in contiguous LSPs, 431 stitched LSPs (only for GMPLS PSC), or nested LSPs. If the network 432 islands are non-PSC then the techniques of [MLN] may be applied, 433 and these techniques may be extrapolated to networks where all 434 nodes are PSC, but where there is a difference in signaling 435 protocols. 437 - The overlay model preserves strict separation of routing 438 information between network layers. This is suitable for the 439 balanced island model and there is no requirement to handle 440 routing interworking. Even though the overlay model preserves 441 separation of signaling information between network layers, there 442 may be some interaction in signaling between network layers. 444 The overlay model requires the establishment of control plane 445 connectivity for the higher layer across the lower layer. 447 - The augmented model allows limited routing exchange from the lower 448 layer network to the higher layer network. Generally speaking, 449 this assumes that the border nodes provide some form of filtering, 450 mapping or aggregation of routing information advertised from the 451 lower layer network. This architectural model can also be used for 452 balanced island model migrations. Signaling interworking is 453 required as described for the peer model. 455 - The border peer architecture model is defined in [MPLS-OVER-GMPLS]. 456 This is a modification of the augmented model where the layer 457 border routers have visibility into both layers, but no routing 458 information is otherwise exchanged between routing protocol 459 instances. This architectural model is particularly suited to the 460 MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands. 461 Signaling interworking is required as described for the peer model. 463 5.1.2. Routing Interworking 465 Migration strategies may necessitate some interworking between MPLS 466 and GMPLS routing protocols. GMPLS extends the TE information 467 advertised by the IGPs to include non-PSC information and extended 468 PSC information. Because the GMPLS information is provided as 469 additional TLVs that are carried along with the MPLS information, 470 MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS 471 PSC LSRs. They will also see other GMPLS information, but will ignore 472 it, flooding it transparently across the MPLS network for use by 473 other GMPLS LSRs. 475 - Routing separation is achieved in the overlay and border peer 476 models. This is convenient since only the border nodes need to be 477 aware of the different protocol variants, and no mapping is 478 required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS- 479 GMPLS island migration models. 481 - Direct distribution involves the flooding of MPLS routing 482 information into a GMPLS network, and GMPLS routing information 483 into an MPLS network. The border nodes make no attempt to filter 484 the information. This mode of operation relies on the fact that 485 MPLS routers will ignore, but continue to flood, GMPLS routing 486 information that they do not understand. The presence of 487 additional GMPLS routing information will not interfere with the 488 way that MPLS LSRs select routes, and although this is not a 489 problem in a PSC-only network, it could cause problems in a peer 490 architecture network that includes non-PSC nodes as the MPLS nodes 491 are not capable of determining the switching types of the other 492 LSRs and will attempt to signal end-to-end LSPs assuming all LSRs 493 to be PSC. This fact would require island border nodes to take 494 triggered action to set up tunnels across islands of different 495 switching capabilities. 497 GMPLS LSRs might be impacted by the absence of GMPLS-specific 498 information in advertisements initiated by MPLS LSRs. Specific 499 procedures might be required to ensure consistent behavior by 500 GMPLS nodes. If this issue is addressed, then direct distribution 501 can be used in all migration models (except the overlay and border 502 peer architectural models where the problem does not arise). 504 - Protocol mapping converts routing advertisements so that they can 505 be received in one protocol and transmitted in the other. For 506 example, a GMPLS routing advertisement could have all of its 507 GMPLS-specific information removed and could be flooded as an MPLS 508 advertisement. This mode of interworking would require careful 509 standardization of the correct behavior especially where an MPLS 510 advertisement requires default values of GMPLS-specific fields to 511 be generated before the advertisement can be flooded further. 512 There is also considerable risk of confusion in closely meshed 513 networks where many LSRs have MPLS and GMPLS capable interfaces. 514 This option for routing interworking during migration is NOT 515 RECOMMENDED for any migration model. Note that converting GMPLS- 516 specific sub-TLVs to MPLS-specific ones but not stripping the 517 GMPLS-specific ones is considered as a variant of the proposed 518 solution in the previous bullet (Unknown sub-TLVs should be 519 ignored [RFC3630] but must continue to be flooded). 521 - Ships in the night refers to a mode of operation where both MPLS 522 and GMPLS routing protocol variants are operated in the same 523 network at the same time as separate routing protocol instances. 524 The two instances are independent and are used to create routing 525 adjacencies between LSRs of the same type. This mode of operation 526 may be appropriate to the integrated migration model. 528 5.1.3. Signaling Interworking 530 Signaling protocols are used to establish LSPs and are the principal 531 concern for interworking during migration. Issues of compatibility 532 arise because of differences in the encodings and codepoints used by 533 MPLS and GMPLS signaling, but also because of differences in 534 functionality provided by MPLS and GMPLS. 536 - Tunneling and stitching (GMPLS-PSC case) mechanisms provide the 537 potential to avoid direct protocol interworking during migration 538 in the island model, because protocol elements are transported 539 transparently across migration islands without being inspected. 540 However, care may be needed to achieve functional mapping in these 541 modes of operation since one set of features may need to be 542 supported across a network designed to support a different set of 543 features. In general, this is easily achieved for the MPLS-GMPLS- 544 MPLS model, but may be hard to achieve in the GMPLS-MPLS-GMPLS 545 model. For example, when end-to-end bidirectional LSPs are 546 requested, since the MPLS island does not support bidirectional 547 LSPs. 549 Note that tunneling and stitching are not available in unbalanced 550 island models because in these cases the LSP end points use 551 different protocols. 553 - Protocol mapping is the conversion of signaling messages between 554 MPLS and GMPLS. This mechanism requires careful documentation of 555 the protocol fields and how they are mapped. This is relatively 556 straightforward in the MPLS-GMPLS unbalanced island model for LSPs 557 signaled in the MPLS-GMPLS direction. However, it may be more 558 complex for LSPs signaled in the opposite direction, and this will 559 lead to considerable complications for providing GMPLS services 560 over the MPLS island and for terminating those services at an 561 egress LSR that is not GMPLS-capable. Further, in balanced island 562 models, and in particular where there are multiple small 563 (individual node) islands, the repeated conversion of signaling 564 parameters may lead to loss of information (and functionality) or 565 mis-requests. 567 - Ships in the night could be used in the integrated migration model 568 to allow MPLS-capable LSRs to establish LSPs using MPLS signaling 569 protocols and GMPLS LSRs to establish LSPs using GMPLS signaling 570 protocols. LSRs that can handle both sets of protocols could work 571 with both types of LSRs, and no conversion of protocols would be 572 needed. 574 6. Manageability Considerations 576 Attention should be given during migration planning to how the 577 network will be managed during and after migration. For example, will 578 the LSRs of different protocol capabilities be managed separately or 579 as one management domain. For example, in the Island Model, it is 580 possible to consider managing islands of one capability separately 581 from the surrounding sea. In the case of islands that have different 582 switching capabilities, it is possible that the islands already have 583 separate management in place before the migration: the resultant 584 migrated network may seek to merge the management or to preserve the 585 separation. 587 6.1. Control of Function and Policy 589 The most critical control functionality to be applied is at the 590 moment of changeover between different levels of protocol support. 591 Such a change may be made without service halt or during a period of 592 network maintenance. 594 Where island boundaries exist, it must be possible to manage the 595 relationships between protocols and to indicate which interfaces 596 support which protocols on a border LSR. Further, island borders are 597 a natural place to apply policy, and management should allow 598 configuration of such policies. 600 6.2. Information and Data Models 602 No special information or data models are required to support 603 migration, but note that migration in the control plane implies 604 migration from MPLS management tools to GMPLS management tools. 605 During migration, therefore, it may be necessary for LSRs and 606 management applications to support both MPLS and GMPLS management 607 data. 609 The GMPLS MIB modules are designed to allow support of the MPLS 610 protocols and built on the MPLS MIB modules through extensions and 611 augmentations. This may make it possible to migrate management 612 applications ahead of the LSRs that they manage. 614 6.3. Liveness Detection and Monitoring 616 Migration will not impose additional issues for OAM above those that 617 already exist for inter-domain OAM and for OAM across multiple 618 switching capabilities. 620 Note, however, that if a flat PSC MPLS network is migrated using the 621 island model, and is treated as a layered network using tunnels to 622 connect across GMPLS islands, then requirements for a multi-layer OAM 623 technique may be introduced into what was previously defined in the 624 flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking 625 will need further consideration. 627 6.4. Verifying Correct Operation 629 The concerns for verifying correct operation (and in particular 630 correct connectivity) are the same as for liveness detection and 631 monitoring. Specifically, the process of migration may introduce 632 tunneling or stitching into what was previously a flat network. 634 6.5. Requirements on Other Protocols and Functional Components 636 No particular requirements are introduced on other protocols. As it 637 has been observed, the management components may need to migrate in 638 step with the control plane components, but this does not impact the 639 management protocols, just the data that they carry. 641 It should also be observed that providing signaling and routing 642 connectivity across a migration island in support of a layered 643 architecture may require the use of protocol tunnels (such as GRE) 644 between island border nodes. Such tunnels may impose additional 645 configuration requirements at the border nodes. 647 6.6. Impact on Network Operation 649 The process of migration is likely to have significant impact on 650 network operation while migration is in progress. The main objective 651 of migration planning should be to reduce the impact on network 652 operation and on the services perceived by the network users. 654 To this end, planners should consider reducing the number of 655 migration steps that they perform, and minimizing the number of 656 migration islands that are created. 658 A network manager may prefer the island model especially when 659 migration will extend over a significant operational period because 660 it allows the different network islands to be administered as 661 separate management domains. This is particularly the case in the 662 overlay, augmented network and border peer models where the details 663 of the protocol islands remain hidden from the surrounding LSRs. 665 6.7. Other Considerations 667 A migration strategy may also imply moving an MPLS state to a GMPLS 668 state for an in-service LSP. This may arise once all of the LSRs 669 along the path of the LSP have been updated to be both MPLS and 670 GMPLS-capable. Signaling mechanisms to achieve the replacement of an 671 MPLS LSP with a GMPLS LSP without disrupting traffic exist through 672 make-before-break procedures [RFC3209] and [RFC3473], and should be 673 carefully managed under operator control. 675 7. Security Considerations 677 Security and confidentiality is often applied (and attacked) at 678 administrative boundaries. Some of the models described in this 679 document introduce such boundaries, for example between MPLS and 680 GMPLS islands. These boundaries offer the possibility of applying or 681 modifying the security as when crossing an IGP area or AS boundary, 682 even though these island boundaries might lie within an IGP area or 683 AS. 685 No changes are proposed to the security procedures built into MPLS 686 and GMPLS signaling and routing. GMPLS signaling and routing inherit 687 their security mechanisms from MPLS signaling and routing without any 688 changes. Hence, there will be no additional issues with security in 689 interworking scenarios. Further, since the MPLS and GMPLS signaling 690 and routing security is provided on a hop-by-hop basis, and since all 691 signaling and routing exchanges described in this document for use 692 between any pair of LSRs are based on either MPLS or GMPLS, there are 693 no changes necessary to the security procedures. 695 8. IANA Considerations 697 This informational framework document makes no requests for IANA 698 action. 700 9. Acknowledgements 702 The authors are grateful to Daisaku Shimazaki for discussion during 703 initial work on this document. The authors are grateful to Dean Cheng 704 and Adrian Farrel for their valuable comments. 706 10. Editor's Addresses 708 Kohei Shiomoto, Editor 709 NTT 710 Midori 3-9-11 711 Musashino, Tokyo 180-8585, Japan 712 Phone: +81 422 59 4402 713 Email: shiomoto.kohei@lab.ntt.co.jp 715 11. Authors' Addresses 717 Dimitri Papadimitriou 718 Alcatel 719 Francis Wellensplein 1, 720 B-2018 Antwerpen, Belgium 721 Phone: +32 3 240 8491 722 Email: dimitri.papadimitriou@alcatel.be 724 Jean-Louis Le Roux 725 France Telecom 726 av Pierre Marzin 22300 727 Lannion, France 728 Phone: +33 2 96 05 30 20 729 Email: jeanlouis.leroux@orange-ftgroup.com 731 Deborah Brungard 732 AT&T 733 Rm. D1-3C22 - 200 S. Laurel Ave. 734 Middletown, NJ 07748, USA 735 Phone: +1 732 420 1573 736 Email: dbrungard@att.com 738 Kenji Kumaki 739 KDDI Corporation 740 Garden Air Tower 741 Iidabashi, Chiyoda-ku, 742 Tokyo 102-8460, JAPAN 743 Phone: +81-3-6678-3103 744 Email: ke-kumaki@kddi.com 746 Zafar Alli 747 Cisco Systems, Inc. 748 EMail: zali@cisco.com 750 Eiji Oki 751 NTT 752 Midori 3-9-11 753 Musashino, Tokyo 180-8585, Japan 754 Phone: +81 422 59 3441 755 Email: oki.eiji@lab.ntt.co.jp 757 Ichiro Inoue 758 NTT 759 Midori 3-9-11 760 Musashino, Tokyo 180-8585, Japan 761 Phone: +81 422 59 3441 762 Email: inoue.ichiro.lab.ntt.co.jp 764 Tomohiro Otani 765 KDDI Laboratories 766 Email: otani@kddilabs.jp 768 12. References 770 12.1. Normative References 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels," BCP 14, IETF RFC 2119, March 1997. 775 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 776 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 777 Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. 779 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 780 Architecture", RFC 3945, October 2004. 782 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions 783 to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 785 [E2E-RECOVERY]Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), 786 " RSVP-TE Extensions in support of End-to-End Generalized 787 Multi-Protocol Label Switching (GMPLS)-based Recovery", 788 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in 789 progress. 791 [SEGMENT-RECOVERY]Berger, L., "GMPLS Based Segment Recovery", draft- 792 ietf-ccamp-gmpls-segment-recovery, work in progress. 794 [TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol 795 Extensions for Discovery of Traffic Engineering Node 796 Capabilities", draft-ietf-ccamp-te-node-cap, work in 797 progress. 799 12.2. Informative References 801 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) 802 Hierarchy with Generalized Multi-Protocol Label Switching 803 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 805 [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, 806 M., Brungard, D., "Requirements for GMPLS-based multi- 807 region and multi-layer networks (MRN/MLN)", draft-ietf- 808 ccamp-gmpls-mln-reqs, work in progress. 810 [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching 811 with Generalized MPLS Traffic Engineering", draft-ietf- 812 ccamp-lsp-stitching, work in progress. 814 [RFC4726] Farrel, A., Vasseur, J.P., Ayyangar, A., " A Framework for 815 Inter-Domain Multiprotocol Label Switching Traffic Engineering", 816 RFC4726, November 2006. 818 [MPLS-OVER-GMPLS] Kumaki, K., et al., " Interworking Requirements to 819 Support operation of MPLS-TE over GMPLS networks", draft-ietf-ccamp- 820 mpls-gmpls-interwork-reqts, work in progress. 822 13. Full Copyright Statement 824 Copyright (C) The IETF Trust (2007). 826 This document is subject to the rights, licenses and restrictions 827 contained in BCP 78, and except as set forth therein, the authors 828 retain all their rights. 830 This document and the information contained herein are provided on an 831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 832 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 833 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 834 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 835 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 838 14. Intellectual Property 840 The IETF takes no position regarding the validity or scope of any 841 Intellectual Property Rights or other rights that might be claimed to 842 pertain to the implementation or use of the technology described in 843 this document or the extent to which any license under such rights 844 might or might not be available; nor does it represent that it has 845 made any independent effort to identify any such rights. Information 846 on the procedures with respect to rights in RFC documents can be 847 found in BCP 78 and BCP 79. 849 Copies of IPR disclosures made to the IETF Secretariat and any 850 assurances of licenses to be made available, or the result of an 851 attempt made to obtain a general license or permission for the use of 852 such proprietary rights by implementers or users of this 853 specification can be obtained from the IETF on-line IPR repository at 854 http://www.ietf.org/ipr. 856 The IETF invites any interested party to bring to its attention any 857 copyrights, patents or patent applications, or other proprietary 858 rights that may cover technology that may be required to implement 859 this standard. Please address the information to the IETF at ietf- 860 ipr@ietf.org.