idnits 2.17.1 draft-takeda-l1vpn-applicability-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1311. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1317), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2005) is 6858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LSR-MIB' is mentioned on line 295, but not defined == Missing Reference: 'EGRESS-CONTROL' is mentioned on line 300, but not defined == Missing Reference: 'TE-MIB' is mentioned on line 358, but not defined == Unused Reference: 'RFC3668' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: 'EGRESS CONTROL' is defined on line 1166, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Possible downref: Normative reference to a draft: ref. 'L1VPN-FW' Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tomonori Takeda (Editor) 3 Internet Draft NTT 4 Proposed Status: Informational 5 Expires: January 2006 July 2005 7 Applicability analysis of GMPLS protocols 8 to Layer 1 Virtual Private Networks 10 draft-takeda-l1vpn-applicability-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet 20 Engineering Task Force (IETF), its areas, and its working 21 groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by 26 other documents at any time. It is inappropriate to use 27 Internet-Drafts as reference material or to cite them other 28 than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be 34 accessed at http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 This document provides an applicability analysis on the use of 43 Generalized Multiprotocol Label Switching (GMPLS) protocols and 44 mechanisms to satisfy the requirements of Layer 1 Virtual Private 45 Networks (L1VPNs). 47 In addition, this document identifies areas where additional 48 protocol extensions or procedures are needed to satisfy the 49 requirements of L1VPNs, and provides guidelines for potential 50 extensions. 52 Contents 54 1. Contributors ............................................. 3 55 2. Terminology .............................................. 3 56 3. Introduction ............................................. 3 57 3.1. Work Items ............................................... 4 58 3.2. Existing Solution Drafts ................................. 4 59 4. General Guidelines ....................................... 5 60 5. Applicability to Management-based Service Model .......... 6 61 5.1. Overview of the Service Model ............................ 6 62 5.2. Applicability of Existing Solutions ...................... 6 63 5.3. Additional Work Area(s) .................................. 6 64 6. Applicability to Signaling-based Service Model (Basic 65 Mode) ................................................... 8 66 6.1. Overlay Service Model .................................... 8 67 6.1.1. Overview of the Service Model ............................ 8 68 6.1.2. Applicability of Existing Solutions ...................... 9 69 6.1.3. Additional Work Area(s) .................................. 10 70 7. Applicability to Signaling and Routing Service Model 71 (Enhanced Mode) .......................................... 13 72 7.1. Overlay Extension Service Model .......................... 13 73 7.1.1. Overview of the Service Model ............................ 13 74 7.1.2. Applicability of Existing Solutions ...................... 13 75 7.1.3. Additional Work Area(s) .................................. 13 76 7.2. Virtual Node Service Model ............................... 14 77 7.2.1. Overview of the Service Model ............................ 14 78 7.2.2. Applicability of Existing Solutions ...................... 15 79 7.2.3. Additional Work Area(s) .................................. 15 80 7.3. Virtual Link Service Model ............................... 16 81 7.3.1. Overview of the Service Model ............................ 16 82 7.3.2. Applicability of Existing Solutions ...................... 16 83 7.3.3. Additional Work Area(s) .................................. 16 84 7.4. Per-VPN Peer Service Model ............................... 17 85 7.4.1. Overview of the Service Model ............................ 17 86 7.4.2. Applicability of Existing Solutions ...................... 17 87 7.4.3. Additional Work Area(s) .................................. 17 88 8. Management Aspects ....................................... 19 89 8.1. Fault Management ......................................... 19 90 8.2. Configuration Management ................................. 19 91 8.3. Security Management ...................................... 20 92 9. Discussion ............................................... 20 93 10. Security Considerations .................................. 22 94 11. IANA Considerations ...................................... 22 95 12. Acknowledgement .......................................... 22 96 13. Normative References ..................................... 23 97 14. Informative References ................................... 23 98 15. Authors' Addresses ....................................... 25 99 Appendix I: Network Usage of L1VPN Service Models ............... 26 100 Intellectual Property Considerations ............................ 27 101 Full Copyright Statement ........................................ 27 103 1. Contributors 105 The details of this document are the result of contributions from 106 several authors who are listed here in alphabetic order. Contact 107 details for these authors can be found in a separate section near 108 the end of this document. 110 Deborah Brungard (AT&T) 111 Adrian Farrel (Old Dog Consulting) 112 Hamid Ould-Brahim (Nortel Networks) 113 Dimitri Papadimitriou (Alcatel) 114 Tomonori Takeda (NTT) 116 2. Terminology 118 The reader is assumed to be familiar with the terminology in 119 [RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-RTG], [RFC4026] 120 and [L1VPN-FW]. 122 3. Introduction 124 This document shows the applicability of existing Generalized 125 Multiprotocol Label Switching (GMPLS) protocols and mechanisms to 126 Layer 1 Virtual Private Networks (L1VPNs). In addition, this document 127 identifies several areas where additional protocol extensions or 128 modifications are needed to meet the L1VPN service requirements set 129 out in [L1VPN-FW]. 131 In particular, this document shows section by section (from section 5 132 to 7) the applicability of GMPLS protocols and mechanisms to each 133 L1VPN service model mentioned in [L1VPN-FW], along with additional 134 work areas needed to fully support the requirements for each service 135 model. Note that management aspects, some of which are common over 136 various service models, are described separately in section 8. 138 Additional, non-normative information regarding network usage of 139 L1VPN service models is provided in the appendix. 141 Note that discussion in this document is limited to areas where GMPLS 142 protocols and mechanisms are relevant. 144 As will be described in this document, support of the 145 Management-based service model, the Signaling-based service model, 146 the Overlay Extension service model and the Virtual Node service 147 model are well covered by existing documents, with only minor 148 protocol extensions required. The Virtual Link service model and the 149 Per-VPN Peer service model are not explicitly covered by existing 150 documents, but can be realized by extending current GMPLS protocols 151 and mechanisms as described in this document. 153 Also, as will be described, the following are possible work areas 154 where additional work may be required to fully support the 155 requirements for each L1VPN service model. Some of the requirements 156 are optional therefore the additional work is also optional. Also, 157 some items below may have more than one existing mechanism (with 158 possible extensions). For those items, the required work is to choose 159 the minimum set of mechanisms. 161 Commonalities of mechanisms over various service models need to be 162 considered. Also, various mechanisms should be coordinated in such a 163 way that services are provided in a fully functional manner. 165 3.1. Work Items 167 This list of additional work areas is a summary derived from the main 168 body of this document. The list will be updated in later versions of 169 this document along with the development of the additional or 170 enhanced requirements and increased understanding of the issues. As 171 work progresses on protocol extensions, it is expected that this list 172 will be updated to remove completed items, and the body of this 173 document will be updated to describe the analysis of protocol 174 extensions. 176 o MIB module for SPC 177 o Resource management per VPN 178 o Signaling mechanisms 179 o VPN membership information exchange within the provider network 180 o CE-PE TE link information exchange within the provider network 181 o VPN membership information exchange between a CE and a PE 182 o CE-PE TE link information exchange between a CE and a PE 183 o Routing representation (how a VPN should be represented in routing, 184 e.g., single area, multi area, multi AS) 185 o Control plane routing (routing information exchange related to 186 control plane topology, per-VPN control packet routing) 187 o Signaling and routing for support of the Per-VPN Peer service model 188 o Management aspects (fault management, configuration management, 189 security management) 190 o MIB modules for protocol extensions 192 3.2. Existing Solutions Drafts 194 This section lists existing solutions documents that describe how 195 L1VPNs may be constructed using the mechanisms of GMPLS. This 196 document draws on those solutions and explains their applicability 197 and suggests further extensions to make the solutions more closely 198 match the framework described in [L1VPN-FW]. Further solutions 199 documents may be listed in a future version of this document. 201 o [GVPN] describes a suite of port-based Provider-provisioned VPN 202 services called Generalized VPNs (GVPNs) that use BGP for VPN 203 auto-discovery and GMPLS as a signaling mechanism. 205 o [GMPLS-UNI] addresses the application of GMPLS to the overlay 206 model. The document provides a description of how the overlay model 207 may be used to support VPN connections across a core GMPLS network. 209 4. General Guidelines 211 This section provides general guidelines for L1VPN solutions. Note 212 that applicability to specific service models will be separately 213 described in following sections. 215 One important general guideline is that protocol mechanisms should be 216 re-used where possible. This means that solutions should be 217 incremental, building on existing protocol mechanisms rather than 218 developing wholly new protocols. Further, as service models are 219 extended or developed resulting in the requirement for additional 220 functionalities, deltas should be added to the protocol mechanisms 221 rather than developing new techniques. [L1VPN-FW] describes how the 222 service models can be seen to provide "cascaded" functionality, and 223 this should be leveraged to achieve re-use of protocol extensions so 224 that, for example, it is highly desirable that the same signaling 225 protocols and extensions are used in both the Signaling-based service 226 model and the Signaling and Routing service model. 228 In addition, the following are general guidelines. 230 - The support of L1VPNs should not necessitate any change to core (P) 231 devices. Therefore, any protocol extensions made to facilitate 232 L1VPNs need to be made in a backward compatible way allowing GMPLS 233 aware P devices to continue to function. 234 - Customer (C) devices not directly involved in providing L1VPN 235 services should also be protected from protocol extensions made to 236 support L1VPNs. Again, such protocol extensions need to be backward 237 compatible. Note however, that some L1VPN service models allow for 238 VPN connectivity between C devices rather than between CE devices: 239 in this case, the C devices may need to be aware of protocol 240 extensions. 241 - It should be considered to minimize the protocol extensions on CE 242 devices. 243 - Solutions should be scalable and manageable. Solutions should not 244 require L1VPN state to be maintained on the P devices. 245 - Solutions should be secure. Providers should be able to screen and 246 protect information based on their operational policies. 248 - Solutions should provide an operational view of the L1VPN for the 249 customer and provider. There should be a common operational and 250 management perspective in regard to other (L2 and L3) VPN services. 252 Note that some deployments may wish to support multiple L1 connection 253 types (such as VC3, VC4, etc.) at the same time. Specific 254 functionalities may need to be considered for these scenarios. This 255 is for further study. 257 5. Applicability to Management-based Service Model 259 5.1. Overview of the Service Model 261 The customer and the provider communicate via a management interface. 262 The provider management system(s) communicate with the PE/P to set up 263 a connection. 265 Note that in this service model the PE-PE connections may be signaled 266 using GMPLS under management control at the ingress PE, or may be 267 statically provisioned through management control of the PEs and 268 Ps. Thus, it remains appropriate to describe signaling and routing 269 mechanisms within this service model. 271 5.2. Applicability of Existing Solutions 273 SNMP MIB modules are one way to realize connection 274 setup/deletion/modification from the management system(s). In 275 particular, GMPLS-LSR-STD-MIB [LSR MIB] can control static 276 connections, while GMPLS-TE-STD-MIB [TE MIB] can control signaled 277 connections. 279 As indicated in [L1VPN-FW], the specification of interface(s) 280 between management system(s) (i.e. customer and provider) is out of 281 the scope of this document. 283 5.3. Additional Work Area(s) 285 The following additional work areas are identified to support the 286 Management-based Service Model. 288 o MIB module for SPC (Soft Permanent Connection) 290 The notion of an SPC only applies if the PE-PE connection is 291 signaled. 293 There are no required extensions to the MIB modules to support the 294 static parts of the connections (CE-PE links) since they can be 295 managed as normal static links using [LSR-MIB]. 297 For the signaled part of the connection (PE-PE), the ingress and 298 egress PEs need to know which (static) CE-PE TE links to use. This 299 information can be carried to the egress PE using egress control 300 [EGRESS-CONTROL], but needs to be configurable at the ingress PE. 301 There are two alternatives. 303 Option1: MIB module extension 305 Define two new MIB objects as part of the specification of the 306 TE LSP [TE-MIB] to specify the ingress and egress CE-PE TE links 307 to be used. 309 Option2: MIB object usage extension 311 Use the current MIB objects, but define new, extended meanings. 312 There are two possible ways to do this. 314 (1) Set the mplsTunnelIngressLSRId in the mplsTunnelTable (that 315 corresponds to the Tunnel Sender Address in the Sender 316 Template object of RSVP-TE) to the ingress CE-PE TE link 317 address. Set the mplsTunnelHopIpAddr of the final 318 MplsTunnelHopEntry in the mplsTunnelHopTable to the egress 319 CE-PE TE link address. 321 (2) Set the mplsTunnelHopIpAddr of the first MplsTunnelHopEntry 322 in the mplsTunnelHopTable to the ingress CE-PE TE link 323 address. This may require a new mplsTunnelHopAddrType value 324 to be defined in order to give precise meaning. Set the 325 mplsTunnelHopIpAddr of the final MplsTunnelHopEntry in the 326 mplsTunnelHopTable to the egress CE-PE TE link address. 328 Detailed analysis of options 1 and 2 is for further study. 330 o Resource management per VPN 332 In the Management-based service model, the data plane may be 333 managed to create two optional functional requirements. 335 - Resource management to create a dedicated per-VPN data plane. The 336 provider network partitions link resources per-VPN for exclusive 337 use by a particular VPN. 338 - Resource management to share part of the data plane among a 339 specific sub-set of VPNs. The provider network assigns link 340 resources to a specific sub-set of VPNs. 342 The default behavior, without this option, is that all resources 343 are available for use by any VPN. 345 If either of these options are applied with a statically managed 346 PE-PE connection then the required function is a matter for policy 347 within the network management tool for the core network. No 348 extensions are required. 350 There are two alternatives to achieve this function for signaled 351 PE-PE connections. 353 Option 1: Policy 355 A simple way to meet this requirement is to implement resource 356 management functionalities as a policy solely in the entity that 357 computes a path. No protocol extensions are needed because links 358 and resources can be explicitly configured using [TE-MIB] and 359 signaled using [RFC3473]. 361 This scheme is especially effective when path computation is 362 done in a centralized manner (e.g., in the management system(s)) 363 and is similar to the policy applied to achieve these functional 364 options using statically configures PE-PE connections. 366 Option 2: Routing extension 368 The other alternative is advertise the amount of resources 369 available to each VPN using extensions to the TE information 370 flooding performed by the routing protocol within the core 371 provider network. 373 In this scheme, the PE/P can compute a path in a distributed 374 way, thus this scheme is especially beneficial in the case of 375 dynamic restoration (restoration that does not reserve backup 376 resources in advance). 378 Note that link coloring might be used for this purpose, but this 379 would eliminate the opportunity to use link coloring for other 380 purposes (e.g., link coloring within VPNs). 382 Detailed analysis of options 1 and 2 is for further study. 384 o Other considerations 386 When path computation is done in a centralized entity (e.g., 387 management system(s)), it is important that resource information is 388 synchronized between the core provider network and such an entity. 390 6. Applicability to Signaling-based Service Model (Basic Mode) 392 6.1. Overlay Service Model 394 6.1.1. Overview of the Service Model 395 In this service model, there is no routing exchange between the CE 396 and the PE. Connections are setup by GMPLS signaling between the CE 397 and the PE, and then across the provider network. 399 Note that routing operates within the provider network and may be 400 used by PEs to exchange information specific to the VPNs supported by 401 the provider network. 403 6.1.2. Applicability of Existing Solutions 405 The following are required in this service model. 407 - VPN membership information exchange: CE-PE TE link address exchange 408 between PEs, along with information associated with a VPN. The TE 409 link addresses may be customer assigned private addresses. 410 - Signaling: CE-CE LSP setup, deletion and modification 411 - Others: Resource management per VPN etc. 413 [GVPN] and [GMPLS-UNI] cover most of the requirements. 415 Specifically, [GVPN] covers VPN membership information exchange by 416 BGP running on the PEs. Customer assigned private addresses for 417 customer site CEs are configured on the PE that provides VPN access 418 to the customer site, and are exchanged by BGP along with a 419 provider network address (which is reachable in the provider 420 network's routing) and an ID associated with the VPN (i.e., Route 421 Target). This allows PEs to perform address translation/mapping and 422 connectivity restriction. 424 The other possibility is to use IGP based VPN membership information 425 exchange (e.g., similar to as an AS external route, or based on 426 [OSPF-NODE-ADDR], with extensions for VPN applications). 428 In addition, [GVPN] and [GMPLS-UNI] suggest two signaling mechanisms 429 for VPN connections. 431 o Shuffling [GVPN] 433 Information carried in RSVP-TE messages identifying a LSP (i.e., 434 SESSION and SENDER_TEMPLATE objects) is translated by the ingress 435 and egress PE. There is one end-to-end session (i.e., CE-CE), but 436 the identifiers of that session change along the path of the LSP. 438 o Nesting [GVPN][GMPLS-UNI][LSP HIER] 440 When Path message arrives at the ingress PE, the ingress PE checks 441 whether there is appropriate PE-PE connectivity. If there is 442 not, it initiates a PE-PE FA-LSP. The CE-CE LSP is carried nested 443 hierarchically within the FA-LSP. There are two sessions (i.e., 444 CE-CE and PE-PE). 446 LSP stitching [STITCHING] operates in a similar manner to LSP 447 nesting. The properties of the PE-PE LSP segment are such that 448 exactly one end-to-end LSP can be stitched to the LSP segment i.e., 449 the PE-PE LSP and the CE-CE LSP correspond exactly one to one. 450 There are two sessions (i.e., CE-CE and PE-PE). 452 LMP [LMP] may be running between a CE and a PE. In that case, the PE 453 is able to obtain customer assigned private addresses on directly 454 attached CEs automatically. This eliminates configuring manually the 455 customer assigned private addresses on PEs, which are distributed by 456 membership information exchange mechanisms. 458 6.1.3. Additional Work Area(s) 460 The following additional work areas are identified to support the 461 Overlay service model. 463 o Signaling mechanisms 465 As described in section 6.1.2, [GMPLS-UNI] and [GVPN] suggest 466 two signaling mechanisms for VPN connections. 468 Option 1: Shuffling 470 In this mechanism, objects need to be translated at the ingress 471 and egress PEs. It is necessary to specify rules for this 472 translation and mechanisms to ensure that the information is 473 available in order to perform the translation. 475 Option 2: Nesting 477 In this mechanism, there is a need to set up a PE-PE FA-LSP. 479 In the case of nesting, PE-PE direct signaling message exchange 480 takes place, and this message exchange may use the provider 481 network addressing space, or the VPN addressing space. It may be 482 necessary to specify an addressing space to be used. 484 When the provider network addressing space is used, there must 485 be a mechanism to identify which VPN each message is associated 486 with at PEs. Otherwise, the PE received the message is not able 487 to proceed the message furthermore (i.e., session 488 identification, and next hope resolution). This mechanism needs 489 to be specified. 491 When the VPN addressing space is used by forming per-VPN control 492 channels between PEs, the identification of VPN is 493 straightforward. However, the mechanisms to realize per-VPN 494 control channels need to be specified (e.g., IP-based tunnel, 495 physically separate control channels). 497 Detailed analysis, including under which condition signaling 498 mechanisms (shuffling or nesting) should be used, is for further 499 study. 501 o VPN membership information exchange within the provider network 503 As described in section 6.1.2, there are two existing mechanisms 504 for the functional option of exchanging VPN membership information 505 within the provider network. This model does not support VPN 506 membership exchange between CE and PE (see section 7.1) and so such 507 information is assumed to be configured within the provider 508 network, usually on the PEs. 510 Option 1: BGP-based 512 [GVPN] specifies a BGP-based mechanism to realize VPN membership 513 information exchange between PEs without informing core Ps. 514 Configuration of this information is performed at the PEs that 515 provide access to a VPN. There is no additional work required, 516 except to update [GVPN] for detailed specification of format and 517 encoding. 519 Option 2: IGP-based 521 OSPF allows AS external routes to be advertised. In addition, 522 [OSPF-NODE-ADDR] extends OSPF-TE to advertise a router's local 523 addresses. These mechanisms can be used to advertise CE-PE TE 524 link addresses within the core provider network. In order to 525 support customer assigned private addresses and connectivity 526 restrictions, this mechanism needs to be extended to exchange 527 information similar to an RT (Route Target) and possibly an RD 528 (Route Distinguisher), along with CE-PE TE link addresses. 530 Detailed analysis of options 1 and 2 is for further study. 532 o Resource management per VPN 534 Section 5.2 describes how provider network resources can be 535 partitioned for use by a single VPN or a sub-set of VPNs. Note that 536 in option 1 of section 5.2, when path computation is done in a 537 separate entity, the interface to the PCE (Path Computation 538 Element) [PCE ARCH] may need to be extended for VPN identification. 540 Note also that it is also possible to apply resource partitioning 541 in the CEs and on the CE-PE links in this model. It will be 542 necessary, however, to ensure consistent configuration through the 543 network management tools of both the customer and provider 544 equipment to provide this function. 546 o CE-PE TE link information exchange within the provider network 548 In the Signaling-based service model, it may be useful to consider 549 not only TE link information within the provider network (PE-P, 550 PE-PE TE links), but also remote CE-PE TE link information in path 551 computation. This prevents connection setup failure due to lack of 552 resources on remote CE-PE TE links. Therefore, CE-PE TE link 553 information should be optionally propagated within the provider 554 network to be used for path computation. 556 There are two alternatives for this. 558 Option1: BGP-based 560 [GVPN] describes potential use of BGP for exchanging CE-PE TE 561 link information. Detailed protocol specifications are needed as 562 additional work. This option is consistent with the BGP-based 563 membership exchange described above. 565 Option 2: IGP-based 567 An alternative is to use IGP to advertise CE-PE TE links. Since 568 a CE does not participate in routing protocol exchange with the 569 provider network, TE link information must be properly 570 constructed by the PE advertising full CE-PE TE link 571 information. This option is consistent with the IGP-based 572 membership exchange described above. 574 Detailed analysis of options 1 and 2 is for further study. 576 o Other considerations 578 Note, there could be a L1VPN solution where connectivity 579 restriction, address translation/mapping etc. are performed not in 580 PEs, but in other entities, such as a centralized policy server. In 581 this case, the interface between the PE and the other entity may 582 need to be specified. This could utilize existing mechanisms such 583 as COPS or LDAP. 585 Also note that [GVPN] assumes that a PE and a CE communicate using 586 separate control channels for each VPN (i.e., a CE-PE control 587 channel is not shared by multiple VPNs). As described above, this 588 facilitates easy separation of VPN signaling messages, but is 589 achieved at the cost of extra configuration at the CE and PE. If 590 a shared control channel is desired in the [GVPN] solution, 591 additional mechanisms such as VPN identification within signaling 592 messages, may be required. 594 7. Applicability to Signaling and Routing Service Model (Enhanced Mode) 596 7.1. Overlay Extension Service Model 598 7.1.1. Overview of the Service Model 600 This service model is a slight extension from the Overlay service 601 model (section 6.1) and may assume all of the requirements, solutions 602 and work items for that model. 604 In this service model, a CE receives from its attached PEs a list of 605 TE link addresses to which it can request a VPN connection (a list of 606 CE addresses within the same VPN). 608 The CE may also receive some of TE information concerning these CE-PE 609 links within the VPN (e.g., switching type). 611 The CE does not receive any of the following from the PE 613 - Routing information about the core provider network 614 - Information about P device addresses. 615 - Information about P-P, PE-P or PE-PE TE links. 616 - Routing information about other customer sites. The CE may have 617 access to routing information about the remainder of the VPN 618 (C-C and CE-C links) but this is exchanged by control plane 619 tunneling on the CE-CE connections and is not passed to the CE in 620 the control plane exchange between PE and CE. 622 7.1.2. Applicability of Existing Solutions 624 The following are required in this service model. 626 - VPN membership information exchange between a CE and PE 627 - CE-PE TE link information exchange between a CE and a PE 629 [GVPN] covers the requirement to exchange membership information 630 between the CE and the PE by BGP for overlay extension. 632 The other possibility is to use IGP based VPN membership information 633 exchange (e.g., similar to as an AS external route, or based on 634 [OSPF-NODE-ADDR], with extensions for VPN applications). 636 7.1.3. Additional Work Area(s) 638 o VPN membership information exchange between a CE and a PE 639 As described in section 7.1.2, there are two existing mechanisms 640 based on which VPN membership information exchange is realized. 642 Option 1: BGP-based 644 [GVPN] suggests a BGP-based mechanism to realize VPN membership 645 information exchange between a CE and a PE. 647 Option 2: IGP-based 649 OSPF allows AS external routes to be advertised. In addition, 650 [OSPF-NODE-ADDR] extends OSPF-TE to advertise a router's local 651 addresses. These mechanisms can be used to advertise CE-PE TE 652 link addresses between a CE and a PE. 654 Detailed analysis of options 1 and 2 is for further study. 656 o CE-PE TE link information exchange between a CE and a PE 658 As just mentioned [GVPN] suggests a BGP-based mechanism to realize 659 VPN membership information exchange. Such a mechanism does not 660 extend well to carrying additional TE information about the CE-PE 661 link either between PEs or between PE and CE because it is 662 generally agreed that BGP should not be used to transport TE 663 information. 665 However, there is no reason in principle why specific, tightly 666 specified extensions should not be used to transport this 667 additional information within the limited context of the L1VPN. 669 An alternative is to use an IGP mechanism to distribute this 670 information. [GVPN] does not constrain the CE-PE routing protocol 671 to be BGP, so this option could be used in either of the options 672 listed for membership exchange. 674 Note that the additional membership and TE information might be 675 considered as superfluous within the core provider network were it to 676 be flooded by an IGP to all P devices. An option, in this case might 677 be to run a separate instance of the IGP including only the CEs and 678 PEs. 680 Mechanisms other than routing protocols could be used to exchange 681 reachability/TE information between the CE and the PE. 683 7.2. Virtual Node Service Model 685 7.2.1. Overview of the Service Model 686 In this service model, there is a private routing exchange between 687 the CE and the PE, or to be more precise between the CE routing 688 protocol and the VPN routing protocol instance running on the PE. The 689 provider network is considered as one private node from the 690 customer's perspective. The routing information exchanged between the 691 CE and the PE includes CE-PE TE link information, CE sites, and may 692 include TE links (Forwarding Adjacencies) connecting CEs (or Cs) 693 across the provider network as well as control plane topology 694 information from CE sites. 696 7.2.2. Applicability of Existing Solutions 698 The followings are required in this service model. 700 - VPN routing 701 - Signaling: CE-CE LSP setup, deletion, and modification 702 - Others: Resource management per VPN etc. 704 [GVPN] covers most of the requirements. 706 Specifically, [GVPN] handles VPN routing by a per VPN database called 707 the GVSI (Generalized Virtual Switching Instance) held in each PE. 708 GVSIs are inter-connected by tunnel-based control channels, and 709 routing adjacencies are established between them. BGP is used for 710 auto-discovery of remote GVSIs (VPN auto-discovery) in the same VPN. 711 GVSIs advertise VPN routing information by using a single ROUTER_ID 712 to represent the provider network as one node. 714 In addition, [GVPN] supports nested signaling (as in the case of the 715 Signaling-based service model). 717 There are other ways to realize VPN auto-discovery. One such way is 718 to use an IGP-based mechanism (e.g., based on [OSPF-CAP] or 719 [OSPF-NODE-ADDR] with extensions). Other possibilities are to use a 720 server based approach (e.g., DNS, based on [DNS DISCOVERY], RADIUS, 721 based on [RADIUS DISCOVERY]) and multicast (e.g., based on 722 [RFC2917]). 724 7.2.3. Additional Work Area(s) 726 The following additional work areas are identified to support the 727 Virtual Node service model. 729 o Routing representation 731 In the Virtual Node service model, one item that should be 732 considered is how to represent a VPN in routing (e.g., single IGP 733 area, multiple IGP areas, multiple ASes). Depending on the routing 734 representation, solution details may differ (e.g., use of 735 auto-discovery). This requires further discussion. 737 o Resource management per VPN 739 See section 6.1.3 741 o Control plane routing 743 An explicit decision must be taken about whether the provider 744 network's control plane topology information should be leaked to 745 the CE. If it is, it may be necessary to separate the address 746 spaces. Further, if control messages (e.g., BGP messages) can be 747 transferred between CE sites using the provider network control 748 plane, care must be taken over how to route per VPN control packets 749 received from the CE. 751 7.3. Virtual Link Service Model 753 7.3.1. Overview of the Service Model 755 In this service model, virtual links are established between PEs. The 756 routing information exchanged between the CE and the PE includes 757 CE-PE TE links, CE sites, virtual links (i.e., PE-PE links), and may 758 include CE-CE (or C-C) Forwarding Adjacencies as well as control 759 plane topology from the CE sites. 761 7.3.2. Applicability of Existing Solutions 763 Currently, there is no solution document for this type of service 764 model. 766 7.3.3. Additional Work Area(s) 768 Simple modifications of [GVPN], in addition to enhancements mentioned 769 in section 7.2.3, may realize this type of service model. 770 Modifications could be: 772 - Do NOT modify the ROUTER_ID of the TE link information when 773 advertising a CE-PE TE link to the CE (in the OSPF packet header as 774 well as in the LSA header). 776 - Set up FA-LSPs (GVSI-LSPs in [GVPN] terms) between PEs to construct 777 virtual links, and advertise these FAs in VPN routing. Note these 778 FAs (virtual links) may be assigned private addresses, which means 779 customer assigned addresses (or that customers are allowed to 780 configure addresses). This may require extensions to current IGP 781 behavior. 783 Note there could be other ways to construct virtual links (e.g., 784 virtual links without actually setting up a FA-LSP [MRN REQ]). 786 There is no additional work area beyond the work already identified 787 for the Virtual Node service model mentioned in section 7.2.3, and 788 that described above. 790 Note that resource management for a dedicated data plane is a 791 mandatory requirement for the Virtual Link service model. This could 792 be realized by assigning pre-configured FA-LSPs to each VPN routing 793 protocol instance (no protocol extensions needed) in order to 794 instantiate the necessary FAs. 796 Note: as in the case of the Virtual Node service model, solution 797 details may differ depending on the routing representation. This 798 requires further discussion. 800 7.4. Per-VPN Peer Service Model 802 7.4.1. Overview of the Service Model 804 In this service model, the provider partitions TE links within the 805 provider network per VPN. The routing information exchanged between 806 the CE and the PE includes CE-PE TE links, CE sites, as well as 807 partitioned portions of the provider network, and may include CE-CE 808 (or C-C) Forwarding Adjacencies and control plane topology from the 809 CE sites. Note that PEs may abstract routing information about the 810 provider network and advertise it to CEs. 812 Note scalability must be carefully considered for advertising 813 provider network routing information to the CE [INTER-DOMAIN FW]. 815 7.4.2. Applicability of Existing Solutions 817 Currently, there is no solution document for this type of service 818 model. However, [GVPN] provides several functionalities to meet this 819 type of service model, as described in section 7.2.2. One way is to 820 extend mechanisms for the Virtual Node service model. The other way 821 is to extend mechanisms for the Virtual Link service model. 823 7.4.3. Additional Work Area(s) 825 As described in section 7.4.2, there are two approaches for this 826 service model. 828 Note that as in the case of the Virtual Node service mode, solution 829 details may differ depending on routing representation. This requires 830 further discussion. 832 o Signaling and routing for support of the per-VPN Peer service 833 model 835 Option 1: Virtual node-based 837 The Per-VPN Peer service model may be realized by extending the 838 virtual node technique so that PEs selectively advertise 839 provider internal TE links to CEs. There are several extensions 840 needed for this. 842 - Topology filtering 844 The PE must choose TE links that are assigned to a specific 845 VPN, and then advertise these TE links to a specific set of 846 CEs corresponding to that VPN. 848 - Topology abstraction 850 The PE may abstract routing information of the provider 851 network, and then advertise abstracted topology information to 852 the CE. It means that the PE may construct a TE link where a 853 direct physical link does not exit, or the PE may construct a 854 single node to represent multiple nodes and TE links. 856 Note scalability must be carefully considered [INTER-DOMAIN 857 FW]. 859 - ERO/RRO expansion/modification 861 The CE may specify an ERO with abstracted topology. The 862 provider network must expand this ERO to match the provider 863 network topology. Note this must be done even if a strict 864 route is specified in the ERO passed from the CE. 866 At the same time, when an RRO is requested, the RRO passed to 867 the CE must be either edited to match the abstracted topology, 868 or removed. 870 - Private address 872 The provider network may support private addresses for routing 873 information provided to the customer. This means that the 874 customer is able to assign private addresses to a partitioned 875 portion of the TE links within the provider network. 877 Option 2: Virtual link-based 879 The Per-VPN Peer service model may be realized by extending the 880 virtual link technique so that not only PEs but also Ps that 881 contain end points of virtual links in the abstracted topology 882 contain VPN routing instances. There may be no additional protocol 883 extensions needed from the Virtual Link service model. 885 Detailed analysis of options 1 and 2 is for further study. 887 8. Management Aspects 889 8.1. Fault Management 891 The provider network may support various recovery techniques 892 mentioned in [P&R TERM]. The customer may be allowed to specify the 893 desired level of recovery in connection setup requests. The provider 894 network may constitute a recovery domain (PE-PE recovery). 896 The following aspects need to be considered relative to L1VPNs. 898 o Shared recovery 900 When the provider network supports shared recovery (e.g., shared 901 mesh restoration), the provider network may be able to support 902 shared recovery only within the same VPN and/or shared recovery 903 among multiple VPNs. The default mode is to be specified. 905 If the provider network supports both, the provider network must 906 provide configuration tools for operators. 908 o Extra traffic 910 GMPLS recovery mechanisms support extra traffic. Extra traffic 911 allows supporting preemptable traffic on recovery resources when 912 these resources are not being used for the recovery of normal 913 traffic [P&R TERM]. 915 When the provider network supports extra traffic, the provider 916 network may be able to support extra traffic only within the same 917 VPN and/or extra traffic among multiple VPNs. The default mode is 918 to be specified. 920 If the provider network supports both, the provider network must 921 provide configuration tools for operators. 923 8.2. Configuration Management 925 Some VPN specific configuration aspects must be considered, such as: 927 o Configuration of resource management per VPN 929 Physical link resources may be dedicated, shared by a specific 930 sub-set of VPNs, or shared by any VPNs. The provider network must 931 provide configuration tools for resource management per VPN. 933 o Configuration of virtual links 935 For the Virtual Link service model and the Per-VPN Peer service 936 model, the provider network must provide configuration tools for 937 operators. 939 o Configuration of service model for each VPN 941 When the provider network supports multiple service models, the 942 provider network must provide configuration tools for operators. 944 8.3. Security Management 946 o CE-PE security 948 When a CE-PE control channel is physically shared by multiple VPNs, 949 security mechanisms need to be applied for data integrity and 950 confidentiality of control messages exchanged. Furthermore, when a 951 CE-PE control channel is dynamically setup, authentication need to 952 be performed. The mechanisms to achieve these include IPsec. 954 Denial of service attack is one significant security threat. The 955 provider network must have mechanisms to detect denial of service 956 attach, and to protect against it reactively and proactively. 958 Details for additional work areas are for further study. 960 o CE-CE security 962 The provider network must restrict connections between CEs in the 963 same VPN. As such, the provider network must avoid mis-connection 964 under any scenario, including failures, recovery and preemption. 966 Furthermore, when customers want to assure security against the 967 provider network, the customers may apply their own security 968 mechanisms (CE-CE security). IPsec can be used for this purpose. 970 9. Discussion 972 This section summarizes items for which existing solutions may need 973 to be extended in order to fulfill the full set of L1VPN service 974 model functionalities. 976 Note that several of these items are in support of optional features. 977 For the Management-based service model, the Signaling-based service 978 model, the Overlay Extension service model and the Virtual Node 979 service model, the existing solutions can be applied with few 980 extensions. 982 As described in sections 7.3.2 and 7.4.2, there are no existing 983 solutions to support the Virtual Link service model and the Per-VPN 984 Peer service model. For the Virtual Link service model, however, 985 minor extensions from existing solutions are expected to meet the 986 requirements. 988 Note that the list of additional work areas will be updated in later 989 versions of this document with the development of additional or 990 enhanced requirements and further understanding of the issues. 992 o MIB module for SPC 993 - Optional, but highly required for the Management-based service 994 model 995 - Two alternatives (MIB module extension or MIB object usage 996 extension) 997 - Impact: MIB module or none 999 o Resource management per VPN 1000 - Optional requirement for the Management-based, the 1001 Signaling-based, the Overlay extension and the Virtual Node 1002 service models 1003 - Mandatory requirement for the Virtual Link and the Per-VPN Peer 1004 service models (support of resource management for dedicated data 1005 plane) 1006 - Two alternatives (policy or routing extension) 1007 - For the Virtual Link service model, can be realized by no 1008 protocol extensions (assign pre-configured FA-LSPs to each VPN 1009 routing instance). 1010 - Impact: None or IGP 1012 o Signaling mechanisms 1013 - Mandatory requirement for the Signaling-based service model and 1014 the Signaling and Routing service model 1015 - Two alternatives (shuffling or nesting) 1016 - Impact: Signaling 1018 o VPN membership information exchange within the provider network 1019 - Mandatory requirement for the Signaling-based service model and 1020 the Overlay Extension service model 1021 - Two alternatives (BGP or IGP) 1022 - Impact: BGP or IGP 1024 o CE-PE TE link information exchange within the provider network 1025 - Optional requirement for the Signaling-based service model and 1026 the Overlay Extension service model 1027 - Two alternatives (BGP or IGP) 1028 - Impact: BGP or IGP 1030 o VPN membership information exchange between a CE and a PE 1031 - Mandatory requirement for the Overlay Extension service model 1032 - Two alternatives (BGP or IGP) 1033 - Impact: BGP or IGP 1035 o CE-PE TE link information exchange between a CE and a PE 1036 - Optional requirement for the Overlay Extension service model 1037 - Two alternatives (BGP or IGP) 1038 - Impact: BGP or IGP 1040 o Routing representation 1041 - One building block for the Signaling and Routing service model 1042 - Further discussion required (single area, multi areas, multi 1043 ASes, etc.) 1044 - Impact: Details to be studied (routing, use of auto-discovery, 1045 etc.) 1047 o Control plane routing 1048 - Optional requirement for the Signaling and Routing service model 1049 - Impact: Routing 1051 o Signaling and routing for support of the Per-VPN Peer service model 1052 - Two options (virtual node-based, virtual link-based) 1053 - Impact: Routing, signaling (details to be studied) 1055 o Management aspects 1056 - Default mode to be specified for shared recovery and extra 1057 traffic 1058 - Support of configuration tools mandatory for fault management and 1059 configuration management 1060 - Details for security management to be studied 1061 - Impact: mostly on operational tools (impacts on protocols to be 1062 studied) 1064 10. Security Considerations 1066 Section 8.3 describes security considerations. 1068 11. IANA Considerations 1070 This document defines no new protocols or extensions and makes no 1071 requests to IANA for registry management. 1073 12. Acknowledgement 1075 We would like to thank Marco Carugi, Ichiro Inoue and Takumi Ohba for 1076 their useful comments and suggestions. 1078 13. Normative References 1080 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 1081 Technology", BCP 79, RFC 3668, February 2004. 1083 [L1VPN-FW] Takeda, T., Editor "Framework for Layer 1 Virtual 1084 Private Networks", draft-takeda-l1vpn-framework, 1085 work in progress. 1087 14. Informative References 1089 For information on the availability of this document, please see 1090 http://www.itu.int. 1092 [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic 1093 requirements and architecture elements, ITU-T 1094 Recommendation, September 2003. 1096 For information on the availability of this document, please see 1097 http://www.itu.int. 1099 [Y.1313] Y.1313 - Layer 1 Virtual Private Network 1100 service and network architectures, ITU-T 1101 Recommendation, July 2004. 1103 [GMPLS-UNI] Swallow, G., et al., "Generalize Multiprotocol 1104 Label Switching(GMPLS) User-Network Interface 1105 (UNI): Resource ReserVation Protocol-Traffic 1106 Engineering (RSVP-TE) Support for the Overlay 1107 Model", draft-ietf-ccamp-gmpls-overlay, work in 1108 progress. 1110 [GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN 1111 Services: Generalized VPN Services using BGP and 1112 GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn- 1113 bgpgmpls, work in progress. 1115 [LSP HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with 1116 Generalized MPLS TE", draft-ietf-mpls-lsp- 1117 hierarchy, work in progress. 1119 [STITCHING] Ayyangar, A. (editor), "Label Switched Path 1120 Stitching with Generalized MPLS Traffic 1121 Engineering", draft-ietf-ccamp-lsp-stitching, work 1122 in progress. 1124 [INTER-DOMAIN FW] Farrel, A., et al., "A Framework for Inter-Domain 1125 MPLS Traffic Engineering", draft-ietf-ccamp- 1126 inter-domain-framework, work in progress. 1128 [P&R TERM] Mannie, E., and Papadimitriou, D. (editors), 1129 "Recovery (Protection and Restoration) Terminology 1130 for Generalized Multi-Protocol Label Switching 1131 (GMPLS)", draft-ietf-ccamp-gmpls-recovery- 1132 terminology, work in progress. 1134 [LSR MIB] Nadeau, T., et al., "Generalized Multiprotocol 1135 Label Switching (GMPLS) Label Switching Router 1136 (LSR) Management Information Base", draft-ietf- 1137 ccamp-gmpls-lsr-mib, work in progress. 1139 [TE MIB] Nadeau, T., et al., "Generalized Multiprotocol 1140 Label Switching (GMPLS) Traffic Engineering 1141 Management Information Base", draft-ietf-ccamp- 1142 gmpls-te-mib, work in progress. 1144 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, 1145 "Multiprotocol label switching Architecture", RFC 1146 3031, January 2001. 1148 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 1149 Srinivasan, V. and G. Swallow, "RSVP-TE: 1150 Extensions to RSVP for LSP Tunnels", RFC 3209, 1151 December 2001. 1153 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol 1154 Label Switching (GMPLS) Signaling Functional 1155 Description", RFC 3471, January 2003. 1157 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol 1158 Label Switching (GMPLS) Signaling - Resource 1159 ReserVation Protocol-Traffic Engineering (RSVP-TE) 1160 Extensions", RFC 3473, January 2003. 1162 [GMPLS-RTG] Kompella, K., et al., "Routing Extensions in 1163 Support of Generalized MPLS", draft-ietf-ccamp- 1164 gmpls-routing, work in progress. 1166 [EGRESS CONTROL] Berger, L., "GMPLS Signaling Procedure For Egress 1167 Control", RFC 4003, February 2005. 1169 [OSPF-CAP] Lindem, A. (editor), "Extensions to OSPF for 1170 Advertising Optional Router Capabilities", 1171 draft-ietf-ospf-cap, work in progress. 1173 [OSPF-NODE-ADDR] Aggarwal, R., Kompella, K., "Advertising a 1174 Router's Local Addresses in OSPF TE Extensions", 1175 draft-ietf-ospf-te-node-addr, work in progress. 1177 [LMP] Lang, J., "Link Management Protocol (LMP)", 1178 draft-ietf-ccamp-lmp, work in progress. 1180 [DNS DISCOVERY] Squire, M., et al., "Using DNS for VPN Discovery", 1181 draft-luciani-ppvpn-vpn-discovery (Expired). 1183 [RADIUS DISCOVERY] Weber, G., Editor "Using RADIUS for PE-Based VPN 1184 Discovery", draft-ietf-l2vpn-radius-pe-discovery 1185 (Expired). 1187 [RFC2917] Muthukrishnan, K., Malis, A., " A Core MPLS IP VPN 1188 Architecture", RFC2917, September 2000. 1190 [RFC4026] Anderssion, L., and Madsen, T., "Provider 1191 Provisioned Virtual Private Network (VPN) 1192 Terminology", RFC 4026, March 2005. 1194 [PCE ARCH] Ash, J., et al., "Path Computation Element (PCE) 1195 Architecture", draft-ietf-pce-architecture, work 1196 in progress. 1198 [MRN REQ] Shiomoto, K., et al., "Requirements for GMPLS- 1199 based multi-region and multi-layer networks", 1200 draft-shiomoto-ccamp-gmpls-mrn-reqs, work in 1201 progress. 1203 15. Authors' Addresses 1205 Deborah Brungard (AT&T) 1206 Rm. D1-3C22 - 200 S. Laurel Ave. 1207 Middletown, NJ 07748, USA 1208 Phone: +1 732 4201573 1209 Email: dbrungard@att.com 1211 Adrian Farrel 1212 Old Dog Consulting 1213 Phone: +44 (0) 1978 860944 1214 Email: adrian@olddog.co.uk 1216 Hamid Ould-Brahim 1217 Nortel Networks 1218 P O Box 3511 Station C 1219 Ottawa, ON K1Y 4H7 Canada 1220 Phone: +1 (613) 765 3418 1221 Email: hbrahim@nortel.com 1223 Dimitri Papadimitriou (Alcatel) 1224 Francis Wellensplein 1, 1225 B-2018 Antwerpen, Belgium 1226 Phone: +32 3 2408491 1227 Email: dimitri.papadimitriou@alcatel.be 1229 Tomonori Takeda 1230 NTT Network Service Systems Laboratories, NTT Corporation 1231 3-9-11, Midori-Cho 1232 Musashino-Shi, Tokyo 180-8585 Japan 1233 Phone: +81 422 59 7434 1234 Email: takeda.tomonori@lab.ntt.co.jp 1236 Appendix I: Network Usage of L1VPN Service Models 1238 This appendix provides additional information concerning network 1239 usage of the L1VPN service models. 1241 o Management-based service model 1243 In this model, the provider network can support non-GMPLS capable 1244 CEs. Therefore, this model is best suited when customer networks 1245 are non-GMPLS, e.g., legacy SONET/SDH and IP/MPLS networks. 1247 It is expected that the provider network requires no or minimal 1248 GMPLS extensions for L1VPN specific functions. 1250 o Signaling-based service model 1252 In this model, by implementing GMPLS signaling functions in CEs, 1253 the customer can request an LSP setup/deletion/modification to the 1254 provider by signaling. Other customer site nodes (C devices) do not 1255 need to be GMPLS-capable. Customers will receive rapid failure 1256 notifications of an LSP by using notification mechanisms available 1257 in GMPLS RSVP-TE. 1259 There are some L1VPN specific extensions required within the 1260 provider network. Concerning customer network routing information, 1261 since only CE-PE TE link addresses are contained within the 1262 provider network, it is expected that there is less concern on 1263 scalability. Trust relationships between the customer and the 1264 provider may need to be carefully considered. 1266 o Signaling and Routing service model 1268 In this model, a customer can seamlessly operate its VPN using 1269 end-to-end GMPLS. Therefore, this model is best suited when 1270 customer networks are operated by GMPLS. 1272 For the service model where the provider network's routing 1273 information is not provided to customers (i.e., Virtual Node 1274 service model), a customer can outsource routing complexity within 1275 the provider network to the provider. On the other hand, in the 1276 service model where the provider network routing information is 1277 provided to customers (i.e., Virtual Link service model and Per-VPN 1278 Peer service model), customers play more of a role. For example, by 1279 allowing customers to assign SRLG IDs for virtual links, customers 1280 can compute and set up end to end disjoint LSPs in their VPN. 1282 There are some L1VPN specific extensions required within the 1283 provider network. Concerning customer network routing information, 1284 since the customer network routing information is contained within 1285 the provider network, scalability must be carefully considered. 1286 Trust relationships between the customer and the provider may need 1287 to be carefully considered as well. 1289 Intellectual Property Considerations 1291 The IETF takes no position regarding the validity or scope of any 1292 Intellectual Property Rights or other rights that might be claimed to 1293 pertain to the implementation or use of the technology described in 1294 this document or the extent to which any license under such rights 1295 might or might not be available; nor does it represent that it has 1296 made any independent effort to identify any such rights. Information 1297 on the procedures with respect to rights in RFC documents can be 1298 found in BCP 78 and BCP 79. 1300 Copies of IPR disclosures made to the IETF Secretariat and any 1301 assurances of licenses to be made available, or the result of an 1302 attempt made to obtain a general license or permission for the use of 1303 such proprietary rights by implementers or users of this 1304 specification can be obtained from the IETF on-line IPR repository at 1305 http://www.ietf.org/ipr. 1307 The IETF invites any interested party to bring to its attention any 1308 copyrights, patents or patent applications, or other proprietary 1309 rights that may cover technology that may be required to implement 1310 this standard. Please address the information to the IETF at 1311 ietf-ipr@ietf.org. 1313 Full Copyright Statement 1315 Copyright (C) The Internet Society (2005). This document is subject 1316 to the rights, licenses and restrictions contained in BCP 78, and 1317 except as set forth therein, the authors retain all their rights. 1319 This document and the information contained herein are provided on an 1320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1322 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1323 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1324 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.