idnits 2.17.1 draft-shiomoto-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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 973. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 680 instances of too long lines in the document, the longest one being 48 characters in excess of 72. ** The abstract seems to contain references ([RFC4206], [RFC3036], [RFC3630], [E2E-RECOVERY], [RFC3495], [RFC2119], [RFC3473], [STITCH], [RFC3945], [SEGMENT-RECOVERY], [E2E-RECOVERY,SEGMENT-RECOVERY], [MRN-REQ], [RFC3784], [RFC4090], [RFC3209], [E2E-recovery,SEGMENT-recovery]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (February 2006) is 6645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC3209' on line 319 looks like a reference -- Missing reference section? 'RFC3630' on line 150 looks like a reference -- Missing reference section? 'RFC3784' on line 150 looks like a reference -- Missing reference section? 'RFC3036' on line 151 looks like a reference -- Missing reference section? 'RFC2119' on line 1036 looks like a reference -- Missing reference section? 'RFC3495' on line 166 looks like a reference -- Missing reference section? 'E2E-recovery' on line 274 looks like a reference -- Missing reference section? 'SEGMENT-recovery' on line 274 looks like a reference -- Missing reference section? 'RFC4090' on line 1039 looks like a reference -- Missing reference section? 'RFC3473' on line 1056 looks like a reference -- Missing reference section? 'E2E-RECOVERY' on line 1050 looks like a reference -- Missing reference section? 'SEGMENT-RECOVERY' on line 1046 looks like a reference -- Missing reference section? 'RFC3945' on line 1043 looks like a reference -- Missing reference section? 'RFC4206' on line 1068 looks like a reference -- Missing reference section? 'MRN-REQ' on line 1063 looks like a reference -- Missing reference section? 'STITCH' on line 1073 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 23 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: August 2006 Deborah Brungard (AT&T) 6 Kenji Kumaki (KDDI) 7 Eiji Oki(NTT) 8 Ichiro Inoue(NTT) 9 Tomohiro Otani (KDDI) 10 February 2006 12 Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to 13 GMPLS migration 15 draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 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 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The migration from Multiprotocol Label Switching (MPLS) to 42 Generalized MPLS (GMPLS) is the process of evolving an MPLS traffic 43 engineered (TE) control plane to a GMPLS control plane. An 44 appropriate migration strategy can be selected based on various 45 factors including the service provider's network deployment plan, 46 customer demand, available network equipment implementation, 47 operational policy, etc. 48 In the course of migration, several interworking cases may exist 49 where MPLS and GMPLS devices or networks must coexist. During the 50 migration process, standard interworking functions are needed to 51 allow graceful deployment of GMPLS technologies while keeping 52 existing IP/MPLS networks unaffected. 53 Since GMPLS signaling and routing protocols are different from the 54 MPLS control protocols, in order for MPLS and GMPLS to interwork, we 55 need mechanisms to compensate for the differences between MPLS and 56 GMPLS. This document provides a landscape of techniques, practices 57 and an overview of interworking between MPLS and GMPLS in support of 58 IP/MPLS to GMPLS migration, which is also beneficial for graceful 59 deployment of GMPLS technologies into existing IP/MPLS networks. We 60 discuss issues, models, migration scenarios, operation, and 61 requirements. 63 Table of Contents 65 1. Introduction.....................................................3 66 2. Conventions Used in This Document................................4 67 3. Motivations for Migration........................................4 68 4. MPLS to GMPLS migration..........................................5 69 4.1. Migration models...............................................5 70 4.1.1. Island model.................................................5 71 4.1.2. Integrated model.............................................6 72 4.1.3. Phased model.................................................7 73 4.2. Migration strategies...........................................7 74 5. Island model interworking cases..................................8 75 5.1. MPLS-GMPLS(PSC)-MPLS Islands...................................8 76 5.2. MPLS-GMPLS(non-PSC)-MPLS Islands...............................9 77 5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands.............................9 78 5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands.....................9 79 5.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands....................9 80 6. Interworking issues between MPLS and GMPLS......................10 81 6.1. Signaling.....................................................10 82 6.1.1. GMPLS specific RSVP objects and Messages....................10 83 6.1.1.1 Direct interworking........................................11 84 6.1.2. Bidirectional LSP...........................................13 85 6.1.3. Failure recovery............................................13 86 6.2. Routing.......................................................13 87 6.2.1. Interworking of Routing Protocols...........................14 88 6.2.2. Mapping of Routing Protocols................................14 89 6.3. Layered Networks..............................................15 90 6.3.1. Peer Model..................................................16 91 6.3.2. Overlay Model...............................................17 92 6.3.3. Augmented Model.............................................17 93 7. Manageability Considerations....................................18 94 7.1. Control of Function and Policy................................18 95 7.2. Information and Data Models...................................18 96 7.3. Liveness Detection and Monitoring.............................19 97 7.4. Verifying Correct Operation...................................19 98 7.5. Requirements on Other Protocols and Functional Components.....19 99 7.6. Impact on Network Operation...................................19 100 7.7. Other Considerations..........................................20 101 8. Security Considerations.........................................20 102 9. IANA Considerations.............................................20 103 10. Full Copyright Statement.......................................21 104 11. Intellectual Property..........................................21 105 12. Acknowledgements...............................................21 106 13. Authors' Addresses.............................................22 107 14. References.....................................................23 108 14.1. Normative References.........................................23 109 14.2. Informative References.......................................23 111 1. Introduction 113 MPLS to GMPLS migration is the process of evolving an MPLS-TE-based 114 control plane to a GMPLS-based control plane. 116 There are several motivations for such migration and they focus 117 mainly on the desire to take advantage of new features and functions 118 that have been added to the GMPLS protocols but which are not present 119 in MPLS. 121 Although an appropriate migration strategy can be selected based on 122 various factors including the service provider's network deployment 123 plan, customer demand, available network equipment implementation, 124 operational policy, etc, the smooth transition mechanism should be 125 investigated from the consistent operation of GMPLS networks, while 126 less impacting the operation of existing MPLS networks. 128 In the course of migration, several interworking cases may arise 129 where MPLS and GMPLS devices or networks must coexist. Such cases may 130 occur as parts of the network are converted from MPLS protocols to 131 GMPLS protocols, or may arise if a lower layer network is made GMPLS- 132 capable (from having no MPLS or GMPLS control plane) in advance of 133 the migration of the higher layer network. 135 This document examines the interworking scenarios that arise during 136 migration, and examines the implications for network deployments and 137 for protocol usage. Since GMPLS signaling and routing protocols are 138 different from the MPLS control protocols, interworking between MPLS 139 and GMPLS networks or network elements needs mechanisms to compensate 140 for the differences. This document provides a framework for MPLS and 141 GMPLS interworking in support of migration from IP/MPLS to GMPLS by 142 discussing issues, models, migration scenarios, operation and 143 requirements. Solutions for interworking MPLS and GMPLS will be 144 developed in companion documents. 146 Note that both MPLS and GMPLS protocols can co-exist as "ships in the 147 night" without any interworking issue. This document addresses 148 interworking to allow migration from MPLS to GMPLS. We should also 149 note that, in this document, a MPLS control plane means a MPLS-TE 150 control plane (RSVP-TE [RFC3209], IGP-TE [RFC3630] [RFC3784]), and 151 not a LDP-based control plane [RFC3036]. This document does not 152 address the migration from LDP controlled MPLS networks to G/MPLS 153 RSVP-TE at this moment, but may consider it in the future version. 155 2. Conventions Used in This Document 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 In the rest of this document, the term GMPLS includes both packet 162 switch capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" or 163 "non-PSC GMPLS" is explicitly used. 165 The reader is assumed to be familiar with the terminology introduced 166 in [RFC3495]. 168 3. Motivations for Migration 170 Motivations for migration will vary for different service providers. 171 This section is only presented to provide background so that the 172 migration discussions may be seen in the context. Sections 4 and 5 173 illustrate the migration models and processes with possible examples. 175 Migration of an MPLS capable LSR to include GMPLS capabilities may be 176 performed for one or more reasons: 178 - To add all GMPLS capabilities to an existing MPLS PSC network. 179 - To add a GMPLS network without sacrificing the existing MPLS PSC 180 LSR implementation. 181 - To pick up specific GMPLS features and operate them within an MPLS 182 PSC network. 183 - To allow MPLS capable LSRs to interoperate with new LSRs that only 184 support GMPLS. 185 - To integrate multiple networks managed by separate administrative 186 organizations, which independently utilize MPLS or GMPLS. 187 - To build integrated PSC and non-PSC networks where the non-PSC 188 networks can only be controlled by GMPLS since MPLS does not 189 operate in non-PSC networks. 191 4. MPLS to GMPLS migration 193 4.1. Migration models 195 MPLS to GMPLS migration is a process of evolving an MPLS-TE-based 196 control plane to a GMPLS-based control plane. Three migration models 197 are considered as described below. Practically speaking, multiple 198 migration models may be deployed at the same time. 200 4.1.1. Island model 202 In the island model, "islands" of network nodes operating one 203 protocol exist within a "sea" of nodes using the other protocol. 205 The most obvious example is to consider an island of GMPLS-capable 206 nodes which is introduced into a legacy MPLS network. Such an island 207 might be composed of newly added GMPLS network nodes, or might arise 208 from the upgrade of existing nodes that previously operated MPLS 209 protocols. 211 The opposite is also quite possible. That is, there is a possibility 212 that an island happens to be MPLS-capable within a GMPLS sea. Such a 213 situation might arise in the later stages of migration, when all but 214 a few islands of MPLS-capable nodes have been upgraded 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 from both networks to GMPLS, the situation might 219 arise where the lower-layer network has been migrated and operates 220 GMPLS, but the packet network still operates MPLS. This would appear 221 as a GMPLS island within an MPLS sea. 223 Lastly, it is possible to consider individual nodes as islands. That 224 is, it would be possible to upgrade or insert an individual GMPLS- 225 capable node within an MPLS network, and to treat that GMPLS node as 226 an island. 228 Over time, collections of MPLS devices are replaced or upgraded to 229 create new GMPLS islands or to extend existing ones, and distinct 230 GMPLS islands may be joined together until the whole network is 231 GMPLS-capable. 233 From a migration/interworking point of view, we need to examine how 234 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 each case, the interworking behavior is examined based on whether 238 the GMPLS islands are PSC or non-PSC. These scenarios are considered 239 further in section 5. 241 Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS 242 interworking. The model consists of a transit GMPLS island in an MPLS 243 sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and 244 G6) are referred to as "island border nodes". If the GMPLS island was 245 non-PSC, all nodes except the island border nodes in the GMPLS-based 246 transit island (G3 and G4) would be non-PSC devices, i.e., optical 247 equipment (TDM, LSC, and FSC). 249 ................. .............................. .................. 250 : MPLS : : GMPLS : : MPLS : 251 :+---+ +---+ +---+ +---+ +---+ +---+ +---+: 252 :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |: 253 :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: 254 : ________/ : : ________/ | ________/ : : ________/ : 255 : / : : / | / : : / : 256 :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: 257 :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |: 258 :+---+ +---+ +---+ +---+ +---+ +---+ +---+: 259 :................: :...........................: :................: 261 |<-------------------------------------------------------->| 262 e2e LSP 264 Figure 1: Example of the island model for MPLS-GMPLS-MPLS 265 interworking. 267 4.1.2. Integrated model 269 The second model involves a more integrated migration strategy. New 270 devices that are capable of operating both MPLS and GMPLS protocols 271 are introduced into the MPLS network. We should note that the GMPLS- 272 capable device may not support a full set of MPLS functionalities. 273 For example, a GMPLS-capable device may support protection and 274 restoration mechanisms in [E2E-recovery, SEGMENT-recovery] but may 275 not support the fast reroute mechanism defined in [RFC4090]. This 276 fact highlights the difference between the island and the integrated 277 models. That is to say, in the island model, a GMPLS node does not 278 support MPLS features (signaling code points, FRR, etc), while in the 279 integrated model, the new device supports both MPLS and GMPLS 280 features. 282 Further, existing MPLS devices will be upgraded to support both MPLS 283 and GMPLS. The network continues to operate providing MPLS services, 284 but where the service can be provided using only GMPLS functionality, 285 it may be routed accordingly over only such MPLS-GMPLS-capable 286 devices and achieve a higher level of functionality by utilizing 287 GMPLS features. Once all devices in the network are GMPLS-capable, 288 the MPLS specific protocol elements (signaling code points, FRR, etc) 289 may be turned off, and no new devices need to support these elements. 291 In this second model, the questions to be addressed concern the co- 292 existence of the two protocol sets within the network. Actual 293 interworking is not a concern. 295 The integrated migration model results in a single network in which 296 both MPLS-capable and MPLS-GMPLS-capable LSRs co-exist. Some LSRs 297 will be capable of only MPLS, and some of both MPLS and GMPLS. The 298 migration strategy here involves introducing MPLS-GMPLS-capable LSRs 299 into an existing MPLS-capable network (i.e. upgrading MPLS LSRS) 300 until all LSRs are MPLS-GMPLS-capable at which time all MPLS 301 functionalities can be disabled, and there are no interworking issues 302 in the data plane. In the control plane, the migration issues concern 303 the separation of MPLS and GMPLS protocols, and the choice of routes 304 that may be signaled with only one protocol. 306 4.1.3. Phased model 308 The phased model introduces GMPLS features and protocol elements into 309 an MPLS network one by one. For example, some object or sub-object 310 (such as the ERO label sub-object, [RFC3473]) might be introduced 311 into the signaling used by LSRs that are otherwise MPLS-capable. This 312 would produce a kind of hybrid LSR. 314 This approach may appear simpler to implement as one is able to 315 quickly and easily pick up key new functions without needing to 316 upgrade the whole protocol implementation. 318 The interoperability concerns (e.g. LABEL REQUEST object [RFC3473] 319 and LABEL object [RFC3209], for RSVP-TE signaling) though are 320 exacerbated by this migration model, unless all LSRs in the network 321 are updated simultaneously. 323 Interworking between a hybrid LSR and an unchanged MPLS LSR would put 324 the hybrid in the role of a GMPLS LSR as described in the previous 325 sections, while interworking between a hybrid LSR and a GMPLS LSR 326 puts the hybrid in the role of an MPLS LSR. The potential for 327 different hybrids within the network will complicate matters 328 considerably. Thus, this piecemeal migration from MPLS to GMPLS is 329 NOT RECOMMENDED. 331 4.2. Migration strategies 332 An appropriate migration strategy is selected based on various 333 factors including the service provider's network deployment plan, 334 customer demand, available network equipment, operational policy, etc. 336 For PSC networks, the migration strategy involves the selection 337 between the models described in the previous section. The choice will 338 depend upon the final objective (full GMPLS capability or partial 339 upgrade to include specific GMPLS features or no change of existing 340 IP/MPLS networks), and upon the immediate objectives (full, phased, 341 or staged upgrade). 343 For PSC networks supported by non-PSC networks, two basic migration 344 strategies can be considered. In the first strategy, the non-PSC 345 network is made GMPLS-capable first and then the PSC network is 346 migrated to GMPLS. This might arise when, in order to expand the 347 network capacity, GMPLS-based non-PSC sub-networks are introduced 348 into or underneath the legacy MPLS-based networks. Subsequently, the 349 legacy MPLS-based PSC network is migrated to be GMPLS-capable as 350 described in the previous paragraph. Finally the entire network, 351 including both PSC and non-PSC nodes, may be controlled by GMPLS. 353 The second strategy for PSC and non-PSC networks is to migrate from 354 the PSC network to GMPLS first and then enable GMPLS within the non- 355 PSC network. The PSC network is migrated as described before, and 356 when the entire PSC network is completely converted to GMPLS, GMPLS- 357 based non-PSC devices and networks may be introduced without any 358 issues of interworking between MPLS and GMPLS. 360 These migration strategies and the migration models described in the 361 previous section are not necessarily mutually exclusive. Mixtures of 362 all strategies and models could be applied. The migration models and 363 strategies selected will give rise to one or more of the interworking 364 cases described in the following section. 366 5. Island model interworking cases 368 5.1. MPLS-GMPLS(PSC)-MPLS Islands 370 The migration of an MPLS-based packet network to become a GMPLS 371 (PSC)-based network may be performed to provide GMPLS-based advanced 372 features in the network, or to facilitate interworking with a GMPLS- 373 based optical core network. 375 The migration may give rise to islands of GMPLS support within a sea 376 of MPLS nodes such that an end-to-end LSP begins and ends on MPLS- 377 capable LSRs. The GMPLS PSC island may be used to "hide" islands of 378 GMPLS non-PSC functionality that are completely contained within the 379 GMPLS PSC islands. This would protect the MPLS LSRs from having to be 380 aware of non-PSC technologies. 382 5.2. MPLS-GMPLS(non-PSC)-MPLS Islands 384 The introduction of a GMPLS-based controlled optical core network to 385 increase the capacity of a MPLS packet network is an example that may 386 give rise to this scenario. Until the MPLS network is upgraded to be 387 GMPLS-capable, the MPLS and GMPLS networks must interwork. The 388 interworking challenges may be reduced by wrapping the non-PSC GMPLS 389 island entirely within a GMPLS PSC island as described in the 390 previous section. 392 5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands 394 This case might arise as the result of installing new GMPLS-capable 395 islands around a legacy MPLS network, or as the result of controlled 396 migration of some islands to become GMPLS-capable. 398 5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands 400 This case is out of scope for this document. Since the MPLS island is 401 necessarily packet capable (i.e. PSC), this scenario requires that 402 non-PSC LSPs are carried across a PSC network. Such a situation does 403 not arise through simple control plane migration, although the 404 interworking scenario might occur for other reasons, and be supported, 405 for example, by pseudo wires. 407 5.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands 409 These cases are likely to arise where the migration strategy is not 410 based on a core infrastructure, but has edge nodes (ingress or 411 egress) located in islands of different capabilities. 413 In this case, an LSP starts or ends in a GMPLS (PSC) island and 414 correspondingly ends or starts in an MPLS island. Some signaling and 415 routing conversion is required on island border LSRs. Figure 2 shows 416 the reference model for this migration scenario. Head-end and tail- 417 end LSR are in distinct control plane clouds. 419 Since both islands are PSC there is no data plane conversion at the 420 island boundaries. However, from a control plane point of view this 421 model may prove challenging because the protocols must share or 422 convert information between the islands rather than tunnel it across 423 an island. 425 ............................. ............................. 426 : MPLS : : GMPLS (PSC) : 428 :+---+ +---+ +---+ +---+ +---+: 429 :|R1 |__ |R11|___ |G1 |________|G3 |________|G5 |: 430 :+---+ +---+ +---+ +-+-+ +---+: 431 : _ _____ _ / : :________/ | _______/ : 432 : / : : / | / : 433 :+---+ +---+ +---+ +-+-+ +---+: 434 :|R2 |__ |R21|___ |G2 |________|G4 |________|G6 |: 435 :+---+ +---+ +---+ +---+ +---+: 436 :...........................: :...........................: 438 |<-------------------------------------------------->| 439 e2e LSP 441 Figure 2: GMPLS-MPLS interworking model. 443 It is also important to underline that this scenario is also impacted 444 by the directionality of the LSP, and the direction in which the LSP 445 is established. Indeed, a unidirectional packet LSP from R1 to G5 is 446 more easily accommodated at G1 than a bidirectional PSC LSP from G5 447 to R1. 449 6. Interworking issues between MPLS and GMPLS 451 As described in the previous sections, interworking between MPLS and 452 GMPLS may form an essential part of a migration and deployment 453 strategy. This section sets out some of the alternatives for 454 achieving interworking between MPLS and GMPLS, and points out some of 455 the issues that need to be addressed if the alternatives are adopted. 456 This document does not describe solutions to these issues. 458 Note that it is possible to consider upgrading the routing and 459 signaling capabilities of LSRs from MPLS to GMPLS separately. 461 6.1. Signaling 463 Signaling protocols are used to establish LSPs and are the principal 464 concern for interworking. This section outlines some of the issues 465 that may arise when MPLS and GMPLS signaling interworking is 466 attempted. Solutions to these issues will be described in separate 467 documents, but possibly rely on tunneling techniques (as described 468 above) or message mapping. 470 6.1.1. GMPLS specific RSVP objects and Messages 472 GMPLS RSVP-TE signaling ([RFC3473]) introduces new RSVP-TE objects, 473 and their associated procedures, that are not processed/generated by 474 MPLS LSRs. Clearly an MPLS LSR cannot be expected to originate LSPs 475 that use these objects and will, therefore, not have access to the 476 additional GMPLS functions. However, the new RSVP-TE objects listed 477 below need to be handled in interworking scenarios where the LSP 478 ingress and/or egress is GMPLS-capable, and MPLS LSRs are required to 479 process the signaling messages: 480 o The (Generalized) Label Request object (new C-Type), used to 481 identify the LSP encoding type, the switching type and the 482 generalized protocol ID (G-PID) associated with the LSP. 483 o The (Generalized) Label object (new C-Type) 484 o The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID 485 ERO/RRO subobjects that handle the Control plane/Data plane 486 separation in GMPLS network. 487 o The Suggested Label Object, used to reduce LSP setup delays. 488 o The Label Set Object, used to restrict label allocation to a set 489 of labels, (particularly useful for wavelength conversion 490 incapable nodes) 491 o The Upstream Label Object, used for bidirectional LSP setup 492 o The Restart Cap object, used for graceful restart. 493 o The Admin Status object, used for LSP administration, and 494 particularly for graceful LSP teardown. 495 o The Recovery Label object used for Graceful Restart 496 o The Notify Request object used to solicit notification of errors 497 and events. 498 o The Protection and Association objects used for LSP recovery 500 Future GMPLS extensions are likely to add further new objects. 502 Some of these objects can be passed transparently by MPLS LSRs to 503 carry them across MPLS islands because their C-Nums are of the form 504 11bbbbbb, but others would cause an MPLS LSR to reject the message 505 that carries them because their C-Nums are of the form 0bbbbbbb. 507 Even when objects are inherited from MPLS by GMPLS they can be 508 expected to cause problems. For example, the Label object in GMPLS 509 uses a new C-Type to indicate 'Generalized Label'. This C-Type is 510 unknown to MPLS LSRs that will reject any message carrying it. 512 GMPLS also introduces new message flags and fields (including new 513 sub-objects and TLVs) that will have no meaning to MPLS LSRs. This 514 data will normally be forwarded untouched by transit MPLS LSRs, but 515 they cannot be expected to act on it. 517 Also GMPLS introduces two new messages, the Notify message, and the 518 RecoveryPath message that are not supported by MPLS nodes. 520 6.1.1.1 Direct interworking 521 A possible solution is to allow direct signaling between MPLS and 522 GMPLS LSRs. However, a fundamental issue is that MPLS and GMPLS use 523 incompatible code points (C-Types) to request labels (LABEL_REQUEST 524 and GENERALIZED_LABEL_REQUEST) and to signal labels (LABEL and 525 GENERALIZED LABEL). 527 Note, however, that the Phased Model may offer a solution that 528 resembles signaling interworking. In this approach LSRs are upgraded 529 to support some GMPLS features but continue to use MPLS code points. 531 MPLS LSPs may be established across an island of enhanced signaling 532 capabilities, where some GMPLS features have been added to MPLS LSRs. 533 This may be relatively simple, and indeed may also be compatible with 534 the Integrated Model. 536 On the other hand, enhanced MPLS LSPs (i.e. LSPs signaled using some 537 GMPLS features) may be carried across an MPLS island. Success in this 538 case will depend on the particular GMPLS features in use (some 539 features, such as bi-directionality, cannot be achieved by a native 540 MPLS network without additional assistance) and the code points that 541 are used to signal the features (some objects can be carried 542 transparently across an MPLS network by virtue of their Class Number 543 encoding, but others will be silently dropped or will cause the 544 message to be rejected). 546 6.1.1.2 Mapping 548 An alternative to interworking signaling protocols is to map each 549 other between MPLS and GMPLS. That is, to convert the objects carried 550 in one message to different objects carried in the message that is 551 actually sent. This mapping would be performed in an upgraded LSR at 552 island borders since existing LSRs would not be aware of the required 553 mappings. This mapping is local decision and should be pre-configured 554 or dynamically done at border nodes. 556 It would be relatively simple to map signaling messages for LSPs 557 initiated on MPLS LSRs (MPLS-GMPLS-MPLS and MPLS-GMPLS) since the 558 LSPs will not need to implement advanced GMPLS features. On the other 559 hand, however, mapping signaling messages for LSPs initiated by a 560 GMPLS LSR (GMPLS-MPLS-GMPLS and GMPLS-MPLS) may be considerably 561 harder depending on the GMPLS features demanded by the LSP. For 562 example, if the GMPLS LSP is bidirectional, additional function will 563 be needed at the border LSR that maps the signaling messages in order 564 to create a pair of unidirectional MPLS LSPs to carry the 565 bidirectional service across the MPLS network that does not have 566 native support for bidirectionality. Indeed, in the GMPLS-MPLS case, 567 a bidirectional service would not be possible unless the egress MPLS 568 LSR was also upgraded to provide this function. 570 6.1.1.3 Transfer 572 A migration strategy may also imply moving an MPLS state to a GMPLS 573 state. For instance, a LSR hosting MPLS states is upgraded such that 574 its controller can run both MPLS and GMPLS. In this case, a signaling 575 mechanism is needed to migrate from the MPLS LSP state to the GMPLS 576 state. 578 6.1.2. Bidirectional LSP 580 GMPLS provides bidirectional LSP setup - a single signaling message 581 exchange manages the bidirectional LSP, and forward and reverse data 582 paths follow the same route in the GMPLS network. There is no 583 equivalent in MPLS networks: forward and backward LSPs must be 584 created in different signaling sessions - the route taken by those 585 LSPs may be different from each other, and their sessions are treated 586 separately. Common routes and fate sharing require additional, 587 higher-level coordination in MPLS. 589 If MPLS and GMPLS networks are inter-connected, bidirectional LSPs 590 from the GMPLS network need to be carried in the MPLS network. 592 Note that this issue arises only in the cases where an LSP is 593 originated by GMPLS-capable LSRs. In other words, it applies only to 594 the GMPLS-MPLS-GMPLS and GMPLS-MPLS island model. 596 Note that the island border LSRs will bear the responsibility for 597 achieving the bidirectional service across the central MPLS island. 599 In the MPLS-GMPLS-MPLS and MPLS-GMPLS models, the ingress LSR is 600 unaware of the concept of a bidirectional LSP and cannot attempt the 601 service even if it could find some way to request it through the 602 network. In the case of GMPLS-MPLS, a similar issue exists because 603 the egress MPLS-capable LSR is unaware of the concept of 604 bidirectional LSPs. 606 6.1.3.Failure recovery 608 Failure recovery mechanism is provided using different mechanisms in 609 MPLS (see [RFC4090]) and GMPLS (see [E2E-RECOVERY, SEGMENT-RECOVERY]). 610 Local protection of island border nodes may be a particular problem. 612 6.2. Routing 614 Some attention should also be given to the use of routing protocols 615 in interworking scenarios since this may allow routing information 616 from islands to be visible within the surrounding seas. 618 GMPLS extends the TE information advertised by the IGPs to include 619 non-PSC information and extended PSC information. Because the GMPLS 620 information is provided as additional TLVs that are carried along 621 with the MPLS information, MPLS LSRs are able to "see" GMPLS LSRs as 622 though they were PSC LSRs. They will also see other GMPLS information, 623 but will ignore it, passing it transparently across the MPLS network 624 for use by other GMPLS LSRs. 626 This means that MPLS LSRs may use the MPLS information advertised by 627 MPLS LSRs and GMPLS LSRs to compute a traffic-engineered explicit 628 route across a mixed network. However, it is likely that a path 629 computation component in an MPLS network will only be aware of MPLS 630 TE information and will not understand concepts such as switching 631 capability type. This may result in that an incorrect path will be 632 computed for an e2e LSP from one MPLS island to another across a 633 GMPLS island if different switching capabilities exist. 635 6.2.1.Interworking of Routing Protocols 637 GMPLS TE advertisements are based on MPLS TE advertisements with the 638 addition of extra sub-TLVs. The processing rules for unknown TLVs 639 mean that they can be ignored by a router, but must be forwarded when 640 the Link State Advertisement (OSPF LSA or IS-IS LSP) is flooded. 642 This means that MPLS and GMPLS LSRs may operate as routing peers, and 643 will redistribute each other's TE information. MPLS LSRs will be 644 granted full TE visibility at an MPLS level into GMPLS islands, while 645 GMPLS LSRs will have limited (i.e. MPLS-level) TE visibility into 646 MPLS islands. 648 This type of routing exchange may be very useful in particular for 649 MPLS-GMPLS-MPLS PSC networks. GMPLS LSRs, however, must either modify 650 their computation algorithms or must generate appropriate defaults 651 for GMPLS TE parameters that are not advertised by MPLS LSRs. 653 6.2.2. Mapping of Routing Protocols 655 The alternatives to interworking routing protocols are to impose 656 protocol boundaries (such as routing area, AS boundaries) or to 657 attempt to map the protocol advertisements as they cross island 658 borders. This latter option is simple for advertisements coming from 659 GMPLS islands since the GMPLS sub-TLVs may be discarded, but is 660 pointless because those sub-TLVs are benign within the MPLS network 661 and are impossible to accurately recreate on re-entry into a GMPLS 662 network. On the other hand, advertisements initiated by MPLS LSRs 663 could have default GMPLS sub-TLVs added when they are flooded into a 664 GMPLS network. These defaults would be similar to those described in 665 the previous section, and would have the advantage that GMPLS LSRs 666 within the network (i.e. not border nodes) would not need to apply 667 the defaults. Care is needed to ensure that the mechanism for 668 applying defaults is identical on all border nodes. 670 Note that any alternative using routing protocol mapping relies on 671 each border LSR knowing which neighbors are MPLS or GMPLS capable. 673 6.3. Layered Networks 675 In addition to the difference between MPLS and GMPLS protocols, 676 control and data plane separation needs to be considered at the 677 boundary of PSC and non-PSC domains. 679 Note that the boundary of PSC and non-PSC domains may or may not be 680 coincident with the boundary of MPLS and GMPLS domains. In the case 681 where the boundaries are not coincident, the boundary between the PSC 682 and non-PSC domains must exist in the GMPLS domain because the MPLS 683 domain cannot support a non-PSC data plane. Here we distinguish two 684 cases: interworking between PSC and non-PSC networks, and 685 interworking between MPLS and GMPLS networks. 687 Figure 3 shows the network model, where the ingress PSC domain and 688 the egress PSC domains are interconnected via the transit non-PSC 689 domain. 691 ................. .............................. .................. 692 : Ingress PSC : : Transit non-PSC : : Egress PSC : 693 :+---+ +---+ +---+ +---+ +---+ +---+ +---+: 694 :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |: 695 :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: 696 : ________/ : : ________/ | ________/ : : ________/ : 697 : / : : / | / : : / : 698 :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: 699 :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |: 700 :+---+ +---+ +---+ +---+ +---+ +---+ +---+: 701 :................: :...........................: :................: 703 Figure 3: Interworking of PSC and non-PSC domains. 705 In the PSC domain, the control plane traffic (signaling and routing) 706 is carried in-band with data. This means that there is fate sharing 707 between a data link and the control traffic on the link. On the other 708 hand, in the non-PSC domain (TDM, LSC, and FSC domains), where packet 709 delineation is not recognized, and in-band control channels cannot be 710 terminated, dedicated control channels (separated from the data 711 channels) are used. In the non-PSC domain, the control channel can be 712 logically or physically separated (i.e., in-fiber out-of-band or out- 713 of-fiber out-of-bound) from the data channel depending on the 714 capabilities of the network devices and the operational requirements. 716 A dedicated control channel must not be used to carry user data 717 traffic. This is particularly important when the control channels are 718 of low capacity and are not designed to carry user traffic. 720 A possible method to protect the control plane channel of a non-PSC 721 domain is that packets coming from PSC domains are not allowed to use 722 the control plane channel. The method, however, causes another 723 problem: lack of signaling and routing adjacencies across the non-PSC 724 domain. 726 This problem is explained using Fig. 3. LSAs in the egress PSC domain 727 are not advertised in the ingress PSC domain unless routing 728 adjacencies are established between the PSC domain and non-PSC domain 729 or unless routing adjacencies are established directly between PSC 730 domains. Therefore the ingress LSR in the ingress PSC domain is not 731 able to find the egress LSR in the egress PSC domain unless these 732 adjacencies are formed. The signaling messages are not passed across 733 the non-PSC domain between the ingress and the egress PSC domains 734 unless the signaling adjacencies are established between the PSC 735 domain and the non-PSC domain or directly between PSC domains. 737 Interworking between PSC and non-PSC networks can be regarded as a 738 layered network. Layered networks are described in many places 739 including [RFC3945] and [RFC4206]. [MRN-REQ] gives a good background 740 and discusses some of the requirements for multi-layered networks. 742 Network layering is often used to separate domains of different data 743 plane technology. It can also be used to separate domains of 744 different control plane technology (such as MPLS and GMPLS protocols), 745 and the solutions developed for multiple data plane technologies can 746 be usefully applied to this situation. 748 The GMPLS architecture [RFC3945] identifies three architectural 749 models for supporting multi-layer GMPLS networks, and these models 750 may be applied to the separation of MPLS and GMPLS control plane 751 islands. The applicability of the different migration models to the 752 three architectural models may provide additional input to the choice 753 of an architectural model. 755 6.3.1. Peer Model 757 In the peer model, both MPLS and GMPLS nodes run the same routing 758 instance and routing advertisements, from within islands of one level 759 of protocol support are distributed to the whole network. This is 760 achievable as described in section 6.2 either by direct distribution 761 or by mapping of parameters. 763 If the entire network (MPLS and GMPLS capable LSRs) is PSC, signaling 764 may establish end-to-end LSPs using the techniques described in 765 section 6.1. On the other hand, if the GMPLS network is of some other 766 switching type, or if the protocol islands are managed as separate 767 network layers, the signaling request can give rise to the creation 768 of a hierarchical LSP [RFC4206] or stitching segment [STITCH] that 769 spans an island and is triggered when the LSP request reaches the 770 island border. The end-to-end LSP from the higher layer network (the 771 protocol sea) is carried across the lower layer network (the protocol 772 island) by the tunnel or stitching segment. 774 Note that an MPLS sea is not capable of determining whether the 775 entire network is of the same switching type and will consequently 776 attempt to signal end-to-end LSPs assuming them to be PSC all the way. 777 This requires that the island border take the appropriate action to 778 set up tunnels across islands of different switching capabilities. 780 6.3.2. Overlay Model 782 The overlay model preserves strict separation of routing information 783 between network layers. Thus, in the interworking case, there is no 784 requirement to handle routing interworking. Signaling interworking is 785 still required as described in section 6.1. 787 Note, however, that there is a requirement to create signaling higher 788 layer adjacencies between island border nodes, and that it is highly 789 desirable to create routing adjacencies in the same way. Such 790 adjacencies may use the control plane of the lower layer network and 791 be independent of the existence of data plane connectivity across the 792 lower layer network. Care may be required to prevent the swamping of 793 the lower layer control plane when it has limited capacity. 794 Alternatively, such adjacencies may rely on the existence of data 795 plane connectivity across the lower layer network. 797 6.3.3. Augmented Model 799 The augmented model allows limited routing exchange from the lower 800 layer network to the higher layer network. Generally speaking, this 801 assumes that the border nodes provide some form of filtering, mapping 802 or aggregation of routing information advertised from the lower layer 803 network, and this is compatible with the mechanisms described in 804 section 6.2.2. 806 Note however, that part of this assumption allows the border nodes to 807 have full visibility into both the higher and lower layer networks 808 without further advertising the information from the lower layer 809 network to the higher layer network meaning that no mapping or 810 interworking of routing protocols is required. Particularly, this 811 includes the case where MPLS and GMPLS clouds run distinct routing 812 instances, and the border nodes run both routing instances. 814 Note that the same observations about routing and signaling 815 adjacencies apply as for the overlay model. 817 7.Manageability Considerations 819 Some attention should be given during migration planning to how the 820 network will be managed during and after migration. For example, will 821 the LSRs of different protocol capabilities be managed separately or 822 as a whole. This is most clear in the Island Model where it is 823 possible to consider managing islands of one capability separately 824 from the surrounding sea. In the case of islands that have different 825 switching capabilities, it is possible that the islands already had 826 different management in place before the migration: the resultant 827 migrated network may seek to merge the management or to preserve it. 829 7.1. Control of Function and Policy 831 The most important control to be applied is at the moment of 832 changeover between different levels of protocol support. Such a 833 change may be made dynamically or during a period of network 834 maintenance. 836 Where island boundaries exist, it must be possible to manage the 837 relationships between protocols and to indicate which interfaces 838 support which protocols on a border LSR. Further, island borders are 839 a natural place to apply policy, and management should allow 840 configuration of such policies. 842 7.2. Information and Data Models 844 No special information or data models are required to support 845 migration, but note that migration in the control plane implies 846 migration from MPLS management tools to GMPLS management tools. 847 During migration, therefore, it may be necessary for LSRs and 848 management applications to support both MPLS and GMPLS variants of 849 management data. 851 The GMPLS MIB modules are designed to allow support of the MPLS 852 protocols and build on the MPLS MIB modules through extensions and 853 augmentations. This may make it possible to migrate management 854 applications ahead of the LSRs that they manage. 856 7.3. Liveness Detection and Monitoring 858 Migration will not imposes additional issues for OAM above those that 859 already exist for inter-domain OAM and for OAM across multiple 860 switching capabilities. 862 Note, however, that if a flat PSC MPLS network is migrated using the 863 island model, and is treated as a layered network using tunnels to 864 connect across GMPLS islands, then requirements for a multi-layer OAM 865 technique may be introduced into what was previously defined in the 866 flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking 867 may be described in more detail in a later version. 869 7.4. Verifying Correct Operation 871 The concerns for verifying correct operation (and in particular 872 correct connectivity) are the same as for liveness detection and 873 monitoring. Principally, the process of migration may introduce 874 tunneling or stitching into what was previously a flat network. 876 7.5.Requirements on Other Protocols and Functional Components 878 No particular requirements are introduced on other protocols. As it 879 has been observed, the management components may need to migrate in 880 step with the control plane components, but this does not impact the 881 management protocols, just the data that they carry. 883 It should also be observed that providing signaling and routing 884 connectivity across a migration island in support of a layered 885 architecture may require the use of protocol tunnels (such as GRE) 886 between island border nodes. Such tunnels may impose additional 887 configuration requirements at the border nodes. 889 7.6. Impact on Network Operation 891 The process of migration is likely to have significant impact on 892 network operation while migration is in progress. The main objective 893 of migration planning should be to reduce the impact on network 894 operation and on the services perceived by the network users. 896 To this end, planners should consider reducing the number of 897 migration steps that they perform, and minimizing the number of 898 migration islands that are created. 900 A network manager may prefer the island model especially when 901 migration will extend over a significant operational period because 902 it allows the different network islands to be administered as 903 separate management domains. This is particularly the case in the 904 overlay and augmented network models where the details of the 905 protocol islands remain hidden from the surrounding LSRs. 907 7.7. Other Considerations 909 No other management considerations arise. 911 8. Security Considerations 913 Security and confidentiality is often applied (and attacked) at 914 administrative boundaries. Some of the models described in this 915 document introduce such boundaries, for example between MPLS and 916 GMPLS islands. These boundaries offer the possibility of applying or 917 modifying the security as one might when crossing an IGP area or AS 918 boundary, even though these island boundaries might lie within an IGP 919 area or AS. 921 No changes are proposed to the security procedures built into MPLS 922 and GMPLS signaling and routing. GMPLS signaling and routing inherit 923 their security mechanisms from MPLS signaling and routing without any 924 changes. Hence, there will be no issues with security in interworking 925 scenarios. Further, since the MPLS and GMPLS signaling and routing 926 security is provided on a hop-by-hop basis, and since all signaling 927 and routing exchanges described in this document for use between any 928 pair of LSRs are based on either MPLS or GMPLS, there are no changes 929 necessary to the security procedures. 931 9. IANA Considerations 933 This information framework document makes no requests for IANA action. 935 10. Full Copyright Statement 937 Copyright (C) The Internet Society (2006). 939 This document is subject to the rights, licenses and restrictions 940 contained in BCP 78, and except as set forth therein, the authors 941 retain all their rights. 943 This document and the information contained herein are provided on an 944 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 945 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 946 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 947 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 948 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 949 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 951 11. Intellectual Property 953 The IETF takes no position regarding the validity or scope of any 954 Intellectual Property Rights or other rights that might be claimed to 955 pertain to the implementation or use of the technology described in 956 this document or the extent to which any license under such rights 957 might or might not be available; nor does it represent that it has 958 made any independent effort to identify any such rights. Information 959 on the procedures with respect to rights in RFC documents can be 960 found in BCP 78 and BCP 79. 962 Copies of IPR disclosures made to the IETF Secretariat and any 963 assurances of licenses to be made available, or the result of an 964 attempt made to obtain a general license or permission for the use of 965 such proprietary rights by implementers or users of this 966 specification can be obtained from the IETF on-line IPR repository at 967 http://www.ietf.org/ipr. 969 The IETF invites any interested party to bring to its attention any 970 copyrights, patents or patent applications, or other proprietary 971 rights that may cover technology that may be required to implement 972 this standard. Please address the information to the IETF at ietf- 973 ipr@ietf.org. 975 12. Acknowledgements 977 The authors are grateful to Daisaku Shimazaki for discussion during 978 initial work on this document. 980 13. Authors' Addresses 982 Kohei Shiomoto 983 NTT 984 Midori 3-9-11 985 Musashino, Tokyo 180-8585, Japan 986 Phone: +81 422 59 4402 987 Email: shiomoto.kohei@lab.ntt.co.jp 989 Eiji Oki 990 NTT 991 Midori 3-9-11 992 Musashino, Tokyo 180-8585, Japan 993 Phone: +81 422 59 3441 994 Email: oki.eiji@lab.ntt.co.jp 996 Ichiro Inoue 997 NTT 998 Midori 3-9-11 999 Musashino, Tokyo 180-8585, Japan 1000 Phone: +81 422 59 3441 1001 Email: inoue.ichiro.lab.ntt.co.jp 1003 Dimitri Papadimitriou 1004 Alcatel 1005 Francis Wellensplein 1, 1006 B-2018 Antwerpen, Belgium 1007 Phone: +32 3 240 8491 1008 Email: dimitri.papadimitriou@alcatel.be 1010 Jean-Louis Le Roux 1011 France Telecom R&D 1012 av Pierre Marzin 22300 1013 Lannion, France 1014 Phone: +33 2 96 05 30 20 1015 Email: jeanlouis.leroux@francetelecom.com 1017 Deborah Brungard 1018 AT&T 1019 Rm. D1-3C22 - 200 S. Laurel Ave. 1020 Middletown, NJ 07748, USA 1021 Phone: +1 732 420 1573 1022 Email: dbrungard@att.com 1024 Kenji Kumaki 1025 KDDI Corporation 1026 Garden Air Tower 1027 Iidabashi, Chiyoda-ku, 1028 Tokyo 102-8460, JAPAN 1029 Phone: +81-3-6678-3103 1030 Email: ke-kumaki@kddi.com 1032 14. References 1034 14.1. Normative References 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels," BCP 14, IETF RFC 2119, March 1997. 1039 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 1040 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 1041 2005. 1043 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label 1044 Switching Architecture", RFC 3945, October 2004. 1046 [SEGMENT-RECOVERY] Berger, L., "GMPLS Based Segment Recovery", 1047 draft-ietf-ccamp-gmpls-segment-recovery, work in 1048 progress. 1050 [E2E-RECOVERY] Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), 1051 " RSVP-TE Extensions in support of End-to-End 1052 Generalized Multi-Protocol Label Switching (GMPLS)- 1053 based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e- 1054 signaling, work in progress. 1056 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 1057 Switching (GMPLS) Signaling Resource ReserVation 1058 Protocol-Traffic Engineering (RSVP-TE) Extensions ", 1059 RFC 3473, January 2003. 1061 14.2. Informative References 1063 [MRN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., 1064 Vigoureux, M., Brungard, D., "Requirements for GMPLS- 1065 based multi-region and multi-layer networks", draft- 1066 shiomoto-ccamp-gmpls-mrn-reqs, work in progress. 1068 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths 1069 (LSP) Hierarchy with Generalized Multi-Protocol Label 1070 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, 1071 October 2005. 1073 [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path 1074 Stitching with Generalized MPLS Traffic Engineering", 1075 draft-ietf-ccamp-lsp-stitching, work in progress.