idnits 2.17.1 draft-ietf-l1vpn-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1694. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 1698), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 36. 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 copyright year in the IETF Trust 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 (January 2007) is 6309 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) ** Downref: Normative reference to an Informational RFC: RFC 4026 -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: July 2007 January 2007 7 Framework and Requirements for Layer 1 Virtual Private Networks 8 draft-ietf-l1vpn-framework-05.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be 32 accessed at http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2007). 38 Abstract 40 This document provides a framework and service level requirements 41 for Layer 1 Virtual Private Networks (L1VPNs). This framework is 42 intended to aid in developing and standardizing protocols and 43 mechanisms to support interoperable L1VPNs. 45 The document examines motivations for L1VPNs, high level (service 46 level) requirements, and outlines some of the architectural models 47 that might be used to build L1VPNs. 49 Contents 51 1. Contributors ............................................... 3 52 2. Terminology ................................................ 3 53 3. Introduction ............................................... 5 54 3.1 Overview ................................................... 5 55 3.1.1 Network Topology ........................................... 5 56 3.1.2 Introducing Layer 1 VPNs ................................... 6 57 3.1.3 Current Technologies for Dynamic Layer 1 Provisioning ...... 6 58 3.2 Relationship with ITU-T .................................... 7 59 4. Motivations ................................................ 8 60 4.1 Basic Layer 1 Services ..................................... 9 61 4.1.1 L1VPN for Dynamic Layer 1 Provisioning ..................... 9 62 4.2 Merits of L1VPN ............................................ 10 63 4.2.1 Customer Merits ............................................ 10 64 4.2.2 Provider Merits ............................................ 10 65 4.3 L1VPN Deployment Scenarios ................................. 10 66 4.3.1 Multi-Service Backbone ..................................... 11 67 4.3.2 Carrier's Carrier .......................................... 11 68 4.3.3 Layer 1 Resource Trading .................................. 12 69 4.3.4 Inter-AS and Inter-SP L1VPNs ............................... 12 70 4.3.5 Scheduling Service ......................................... 13 71 5. Reference Model ............................................ 13 72 5.1 Management Systems ......................................... 15 73 6. Generic Service Description ................................ 15 74 6.1 CE Construct ............................................... 15 75 6.2 Generic Service Features ................................... 15 76 7. Service Models ............................................. 16 77 7.1 Management-based Service Model ............................. 16 78 7.2 Signaling-based Service Model (Basic Mode) ................. 17 79 7.2.1 Overlay Service Model ...................................... 17 80 7.3 Signaling and Routing Service Model (Enhanced Mode) ........ 18 81 7.3.1 Overlay Extension Service Model ............................ 19 82 7.3.2 Virtual Node Service Model ................................. 19 83 7.3.3 Virtual Link Service Model ................................. 20 84 7.3.4 Per-VPN Peer Service Model ................................. 21 85 8. Service Models and Service Requirements .................... 21 86 8.1 Detailed Service Level Requirements ........................ 23 87 9. Recovery Aspects ........................................... 24 88 9.1 Recovery Scope ............................................. 24 89 9.2 Recovery Resource Sharing Schemes .......................... 25 90 10. Control Plane Connectivity ................................. 26 91 10.1 Control Plane Connectivity between a CE and a PE ........... 26 92 10.2 Control Plane Connectivity between CEs ..................... 26 93 11. Manageability Considerations ............................... 27 94 12. Security Considerations .................................... 29 95 12.1 Types of Information ....................................... 29 96 12.2 Security Features .......................................... 30 97 12.3 Scenarios .................................................. 31 98 13. IANA Considerations ........................................ 31 99 14. Acknowledgements ........................................... 32 100 15. Normative References ....................................... 32 101 16. Informative References ..................................... 33 102 17. Authors' Addresses ......................................... 34 103 18. Intellectual Property Consideration ........................ 35 104 19. Full Copyright Statement ................................... 35 106 1. Contributors 108 The foundation of this document is based heavily on the work of ITU-T 109 Study Group 13 Question 11. SG13/Q11 has been investigating the 110 service requirements and architecture for Layer 1 VPNs for some time, 111 and the foundation of this document is a summary and development of 112 the conclusions they have reached. Based on such material, the IETF 113 and the L1VPN WG in particular have developed this framework and 114 requirements for the support of L1VPNs by use of GMPLS protocols. 116 The details of this document are the result of contributions from 117 several authors who are listed here in alphabetic order. Contact 118 details for these authors can be found in a separate section near 119 the end of this document. 121 Raymond Aubin (Nortel) 122 Marco Carugi (Nortel) 123 Ichiro Inoue (NTT) 124 Hamid Ould-Brahim (Nortel) 125 Tomonori Takeda (NTT) 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 The reader is assumed to be familiar with the terminology in 134 [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202] [RFC3945], 135 [RFC4208] and [RFC4026]. 137 In this context a Layer 1 Network is any transport network that has 138 connectivity and/or switching using spatial switching (e.g., incoming 139 port or fiber to outgoing port or fiber), lambda-switching, or 140 time-division-multiplex-switching. 142 A Layer 1 VPN (L1VPN) is a service offered by a core layer 1 network 143 to provide layer 1 connectivity between two or more customer sites 144 and where the customer has some control over the establishment and 145 type of the connectivity. An alternative definition is simply to say 146 that an L1VPN is a VPN whose data plane operates at layer 1. Further 147 details of the essence of an L1VPN are provided in Section 3. 149 In addition, following new terms are used within this document. 151 - Virtual link: A provider network Traffic Engineering (TE) link 152 advertised to customers in routing information for purposes which 153 include path computation. A direct data link may or may not exist 154 between the two end points of a virtual link. 156 - Virtual node: A provider network logical node advertised to 157 customers in routing information. A virtual node may represent a 158 single physical node, or multiple physical nodes and the links 159 between them. 161 - VPN end point: A Customer Edge (CE) device's data plane interface, 162 which is connected to a Provider Edge (PE) device, and which is 163 part of the VPN membership. Note that a data plane interface is 164 associated with a TE link end point. For example, if a CE router's 165 interface is a channelized interface (defined in SONET/SDH), a 166 channel in the channelized interface can be a data plane interface. 168 - VPN connection (or connection in the L1VPN context): A connection 169 between a pair of VPN end points. Note that in some scenarios, a 170 connection may be established between a pair of C (Customer) 171 devices, using this CE-CE VPN connection as a segment or 172 forwarding adjacency defined in [RFC4206]. 174 Note that following terms are aligned with Provider Provisioned VPN 175 (PPVPN) terminology [RFC4026], and in this document, have a meaning 176 in the context of L1VPNs, unless otherwise specified. 178 - CE device: A CE device is a customer device that receives L1VPN 179 service from the provider. A CE device is connected to at least one 180 PE device. A CE device can be a variety of devices, for example, 181 Time Division Multiplexing (TDM) switch, router, and layer 2 182 switch. A CE device does not have to have the capability to switch 183 at layer 1, but it is capable of receiving a layer 1 signal and 184 either switching it or terminating it with adaptation. A CE device 185 may be attached to one or more C devices on the customer site, may 186 be a host using a layer 1 connection directly. 188 - PE device: A PE device is a provider device that provides L1VPN 189 service to the customer. A PE device is connected to at least one 190 CE device. A layer 1 PE device is a TDM switch, an Optical Cross- 191 Connect (OXC) (see [RFC3945]), a Photonic Cross-Connect (PXC) 192 (see [RFC3945]). Alternatively, a PE device may be an Ethernet 193 Private Line (EPL) type of device, that maps Ethernet frames onto 194 layer 1 connections (by means of Ethernet over TDM etc.). 196 - P (Provider) device: A P device is a provider device, which is 197 connected only to other provider devices (P or PE devices). A layer 198 1 P is a TDM switch, OXC, or PXC. 200 - Customer: A customer has authority over a set of CE devices within 201 the same VPN (e.g., the owner of CE devices). Note that a customer 202 may outsource the management of CE devices to other organizations, 203 including to the provider itself. 205 - Provider: A provider has authority over the management of the 206 provider network. 208 - Membership information: A list of CE-PE TE link addresses belonging 209 to the same VPN. Membership information contains association of a 210 CE, a PE and a VPN. 212 3. Introduction 214 The document examines motivations for Layer 1 Virtual Private 215 Networks (L1VPNs), provides high level (service level) requirements, 216 and outlines some of the architectural models that might be used to 217 build L1VPNs. 219 The objective of the document is mainly to present the requirements 220 and architecture based on the work undertaken within the ITU-T. 222 L1VPNs provide services over layer 1 networks. This document provides 223 a framework for L1VPNs and the realization of the framework by those 224 networks being controlled by Generalized Multi-Protocol Label 225 Switching (GMPLS) protocols. 227 Use of GMPLS protocols for providing L1VPN services has several 228 advantages, such as: 230 - Flexible network operation 231 - Use of standardized protocols 232 - Use of common control and measurement plane protocols applicable to 233 various layer 1 networks, including TDM networks and optical 234 networks. 236 3.1 Overview 238 3.1.1 Network Topology 240 The layer 1 network, made of OXCs, TDM switches, or PXCs may be seen 241 as consisting of PE devices that give access from outside of the 242 network, and P devices that operate only within the core of the 243 network. Similarly, outside the layer 1 network is the customer 244 network consisting of C devices with access to the layer 1 network 245 made through CE devices. 247 A CE and PE are connected by one or more links. A CE may also be 248 connected to more than one PE, and a PE may have more than one CE 249 connected to it. 251 A layer 1 connection is provided between a pair of CEs. Such a 252 connection follows the hierarchy defined in [RFC4206]. That is, a 253 CE-CE connection may be nested in a lower layer connection (e.g., VC3 254 connection over STM1 connection). Likewise, the switching 255 capabilities of the interfaces of the CEs, PEs and Ps on which a 256 connection is routed follow the hierarchy defined in [RFC4206]. 258 3.1.2 Introducing Layer 1 VPNs 260 The concept of a PPVPN has been established through many previous 261 documents such as [L2VPN-FW] and [RFC4110]. Terminology for PPVPNs 262 is set out in [RFC4026] with special reference to layer 2 and layer 3 263 VPNs. 265 The realization of L1VPNs can be based on extensions of the concepts 266 of the PPVPN to the layer 1 network. It must be understood that 267 meeting the requirements set out in this document may necessitate 268 extensions to the existing mechanisms both for the control plane 269 within the layer 1 network and for service provisioning at the edge 270 of the network (CE and PE devices). It is at the interface between CE 271 and PE devices that the L1VPN service is provided. 273 Note that the fundamental difference between L1VPNs and L2/L3 274 VPNs is that in L1VPNs data plane connectivity does not guarantee 275 control plane connectivity (and vice versa). But CE-PE control plane 276 connectivity is required for L1VPN services provisioned through 277 the control plane, and CE-CE data plane connectivity is 278 maintained by signaling mechanisms based on this control plane 279 connectivity. Further, the provision of CE-CE control plane 280 connectivity over the provider network is also required for certain 281 levels of L1VPN service, and this can be achieved by the exchange 282 of control packets between CEs over the control plane of the 283 provider network. This aspect is discussed further in Section 10.2. 285 3.1.3 Current Technologies for Dynamic Layer 1 Provisioning 287 Pre-existing efforts at standardization have focused on the provision 288 of dynamic connections within the layer 1 network (signaling and 289 routing) and the definition of interfaces for requesting services 290 between the user and the layer 1 network over the User-Network 291 Interface (UNI), and between networks across the External Network- 292 Network Interface (E-NNI) (see [RFC3945], [RFC4208], [RFC4139], and 293 [RFC4258]). 295 Current UNIs include features to facilitate requests for end-to-end 296 (that is, CE to CE) services that include the specification 297 of constraints such as explicit paths, bandwidth requirements, 298 protection needs, and (of course) destinations. 300 Current E-NNIs include features to exchange routing information, as 301 well as to facilitate requests for end-to-end services. 303 The UNIs and E-NNIs may be applied in the context of L1VPNs. For 304 example, the UNI may be applied between the CE and the PE, and the 305 E-NNI may be applied between PEs (inter-AS/SP L1VPNs), or between the 306 CE and the PE. 308 However, the existing UNI and E-NNI specifications do not provide 309 sufficient parameters to support VPNs without some additions. For 310 example, there is no way to distinguish between control messages 311 received over a shared control link (i.e., a control link shared by 312 multiple VPNs) at a UNI/E-NNI, and these messages must be 313 disambiguated to determine the L1VPN to which they apply. A control 314 link is an IP link used for establishing a control channel between 315 nodes. 317 Another example is that there is no clear defined way of distributing 318 membership information to be used in combination with UNI/E-NNI. This 319 function is necessary in order to discover the existence of and 320 location of the CEs to be connected by L1 connections. Distribution 321 of membership information is typically done by the provider, and may 322 be realized by mechanisms such as static provisioning, or by 323 piggybacking on routing protocols (e.g., see Section 4.2.1 of 324 [RFC4110]). Note that the method chosen for distribution of 325 membership information depends on the solution used for supporting 326 L1VPNs, which is outside of the scope of this document. 328 Furthermore, customer addressing realms may overlap with each other, 329 and may also overlap with the service provider addressing realm. This 330 requires address mapping mechanisms, but such mechanisms are not well 331 defined in existing UNI/E-NNI specifications. 333 Lastly, there is no clear defined way to restrict connectivity 334 among CEs (or over a UNI/E-NNI). In addition, E-NNIs allow routing 335 information exchange, but there is no clear defined way to allow 336 limited routing information exchange (i.e., a specific set of routing 337 information is distributed to a specific set of CEs). 339 In order that L1VPNs can be supported in a fully functional manner, 340 these additional capabilities and other requirements set out later in 341 this document must be addressed. 343 Note that inter-AS/SP L1VPNs require additional analysis beyond the 344 focus of this document. 346 3.2 Relationship with ITU-T 348 The foundation of this document is based on the work of the ITU-T 349 Study Group 13 Question 11. This group has been researching and 350 specifying both the requirements and the architecture of L1VPNs for 351 some time. In this context, the foundation of this document is a 352 representation of the findings of the ITU-T, and a presentation of 353 those findings in terms and format that are familiar to the IETF. 355 In particular, this document is limited to the areas of concern of 356 the IETF. That is, it is limited to layer 1 networks that utilize 357 IP as the underlying support for their control plane. 359 The foundation of this document presents the requirements and 360 architectures developed within the ITU-T for better understanding 361 within the IETF and to further cooperation between the two bodies. 363 Some work related to the L1VPN solution space has already been done 364 within the IETF. This document sets a framework of requirements and 365 architecture into which solutions can fit. 367 4. Motivations 369 In this discussion many merits and motivations may be taken for 370 granted. 372 The general benefits and desirability of VPNs has been described 373 many times and in many places [RFC4110] and [L2VPN-FW]. This 374 document does not dwell on the merits of VPNs as such, but focuses 375 entirely on the applicability of the VPN concept to layer 1 networks. 377 Similarly, the utility and value of a control plane for the 378 configuration, management and operation of a layer 1 network is 379 well-rehearsed [RFC3945]. 381 4.1 Basic Layer 1 Services 383 Basic layer 1 services may be characterized in terms that include: 385 - Connectivity: Between a pair of CEs. 386 - Capacity: For example, the bit rate for a TDM service or the 387 capacity of a lambda. 388 - Transparency: For example, for an SDH network, overhead 389 transparency. 390 - Availability: The percentage of time that the offered service 391 meets the criteria that the provider defines, possibly agreed with 392 each customer. To achieve the required level of availability for 393 the customer connections the service provider's network may use 394 restoration or protected resources [RFC4427]. 395 - Performance: The quality of the service delivered to customers, 396 e.g., the number of error-seconds per month. 398 The layer 1 services may be categorized based on the combination of 399 connectivity features (data plane) and service control capability 400 features (control plane) available to the customer. A CE is 401 associated with the service interface between a customer site and the 402 provider network, and the categorization can be seen in the context 403 of this service interface as follows. 405 1. A single connection between a pair of CEs. 407 - Static Service 408 The classic private line service achieved through a permanent 409 connection. 411 - Dynamic Service 412 Either a switched connection service, or a customer-controlled 413 soft permanent connection service (i.e., the customer is in 414 control of when the signaled part is established). 416 2. Multiple connections among a set of CEs. 418 - Static Service 419 A private network service consisting of a mesh of permanent 420 connections. 422 - Dynamic Service 423 A dynamic private network service consisting of any combination 424 of switched connection services and customer-controlled soft 425 permanent connection services. 427 For service types 1 and 2, connections are point-to-point, and can be 428 permanent, soft-permanent, or switched. For a static service, the 429 management plane of the provider network is responsible for the 430 management of both the network infrastructure and the end-user 431 connections. For dynamic services, the management plane of the 432 provider network is only responsible for the configuration of the 433 infrastructure; end-user connections are established dynamically via 434 the control plane of the provider network upon customer request. 436 This document does not preclude other advanced services and topology 437 support, such as point-to-multipoint (P2MP) services, as part of the 438 layer 1 services, but these are for further study. 440 4.1.1 L1VPN for Dynamic Layer 1 Provisioning 442 Private network services in the second category in Section 4.1 can be 443 enhanced so that multiple private networks are supported across the 444 layer 1 network as virtual private networks. These are Layer 1 445 Virtual Private Networks (L1VPNs). Note the first category in Section 446 4.1 would include L1VPNs with only two CEs as a special case. 448 Compared to the first category of service, the L1VPN service has 449 features such as connectivity restriction, a separate policy, 450 and distribution of membership information applied to a specific 451 group. 453 4.2 Merits of L1VPN 455 4.2.1 Customer Merits 457 From the customer's perspective, there are two main benefits to a 458 L1VPN. These benefits apply over and above the advantages of access 459 to a dynamically provisioned network. 461 - The customer can outsource the direct management of a layer 1 462 network by placing the VPN management in the control of a third 463 party. This frees the customer from the need to configure and 464 manage the connectivity information for the CEs that participate 465 in the VPN. 467 - The customer can make small-scale use of a layer 1 network. So, 468 for example, by sharing the layer 1 network infrastructure with 469 many other users, the customer sites can be connected together 470 across the layer 1 network without bearing the full cost of 471 deploying and managing the layer 1 network. 473 To some extent, the customer may also gain from the provider's 474 benefits (see below). That is, if the provider is able to extract 475 more value from the layer 1 network, the customer will benefit from 476 lower priced services that are better tailored to the customer's 477 needs. 479 4.2.2 Provider Merits 481 The provider benefits from the customer's perception of benefits. 483 In particular, the provider can build on dynamic, on-demand services 484 by offering new VPN services and off-loading the CE-to-CE 485 configuration requirements from the customers. 487 Additionally, a more flexible VPN structure applied to the layer 1 488 network allows the provider to make more comprehensive use of the 489 spare (that is, previously unused) resources within the network. This 490 could be achieved by applying a network model where the provider is 491 responsible for deciding how resources are used and for provisioning 492 of the connection through the layer 1 network. 494 4.3 L1VPN Deployment Scenarios 496 In large carrier networks providing various kinds of service, it is 497 often the case that multiple service networks are supported over a 498 shared transport network. By applying L1VPNs, multiple internal 499 service networks (which may be managed and operated separately) can 500 be supported over a shared layer 1 transport network controlled and 501 managed using GMPLS. In addition, L1VPNs can support capabilities to 502 offer innovative services to external clients. 504 Some more specific deployment scenarios are as follows. 506 4.3.1 Multi-Service Backbone 508 A multi-service backbone is characterized in terms such that each 509 service department of a carrier that receives the carrier's L1VPN 510 service provides a different kind of higher-layer service. The 511 customer receiving the L1VPN service (i.e., each service department) 512 can offer its own services whose payloads can be any layer (e.g., 513 ATM, IP, TDM). The layer 1 transport network and each service network 514 belong to the same organization, but may be managed separately. From 515 the L1VPN service provider's point of view, these services are not 516 visible and are not part of the L1VPN service. That is, the type of 517 service being carried within the layer 1 payload is not known by the 518 service provider. 520 The benefit is that the same layer 1 transport network resources are 521 shared by multiple services. A large capacity backbone network (data 522 plane) can be built economically by having the resources shared by 523 multiple services usually with flexibility to modify topologies, 524 while separating the control functions for each service department. 525 Thus, each customer can select a specific set of features that are 526 needed to provide their own service. 528 Note that it is also possible to control and manage these service 529 networks and the layer 1 transport network by using GMPLS in the 530 integrated model [RFC3945] instead of using L1VPNs. However, using 531 L1VPNs is beneficial in the following points. 533 - Independent address space for each of the service networks. 534 - Network isolation (topology information isolation, fault isolation 535 among service networks). 536 - Independent layer 1 resource view for each of the service networks. 537 - Independent policies that could be applied for each of the service 538 networks. 540 These points may apply to the management plane functionalities as 541 well as to the control plane functionalities. 543 4.3.2 Carrier's Carrier 545 A carrier's carrier is characterized in terms such that one carrier 546 that receives another carrier's L1VPN service provides its own 547 services. In this scenario, two carriers are in different 548 organizations. It is, therefore, expected that the information 549 provided at the service demarcation points is more limited than in 550 the multi-service backbone case. Similarly, less control of the 551 L1VPN service is given at the service demarcation points. For 552 example, customers of an L1VPN service receive: 554 - A more limited view of the L1VPN service provider network. 555 - More limited control over the L1VPN service provider network. 557 One of the merits is that each carrier can concentrate on a specific 558 service. For example, the customer of the L1VPN service may focus on 559 L3 services, e.g., providing secure access to the Internet, leaving 560 the L1VPN provider to focus on the layer 1 service, e.g., providing a 561 long-haul bandwidth between cities. The L1VPN customer can construct 562 its own network using layer 1 resources supplied by the L1VPN 563 provider, usually with flexibility to modify topologies, while 564 separating the control functions for each customer carrier. 566 4.3.3 Layer 1 Resource Trading 568 In addition to the scenarios where the second tier service provider 569 is using a single core service provider as mentioned in Section 570 4.3.2, it is possible for the second tier provider to receive 571 services from more than one core service provider. In this scenario, 572 there are some benefits for the second tier service provider such as 573 route redundancy and dynamic carrier selection based on the price. 575 The second tier service provider can support a function that enables 576 a layer 1 resource trading service. Using resource information 577 published by its core service providers, a second tier service 578 provider can decide how to best use the core providers. For example, 579 if one core service provider is no longer able to satisfy requests 580 for service, an alternate service provider can be used. Or the second 581 tier service provider could choose to respond to price changes of 582 service over time. 584 Another example of second tier service provider use is to reduce 585 exposure to failures in each provider (i.e., to improve 586 availability). 588 4.3.4 Inter-AS and Inter-SP L1VPNs 590 In addition to the scenarios where a single connection between two 591 CEs is routed over a single service provider as mentioned in Section 592 4.3.2, it is possible that a connection is routed over multiple 593 ASes within a service provider (called inter-AS L1VPN) or over 594 multiple service providers (called inter-SP L1VPN). 596 The inter-AS L1VPN scenario can be used to construct a single L1VPN 597 from network resources administered by different domains of a single 598 service provider. These administrative domains might not usually have 599 a collaborative relationship at layer 1, and so the inter-AS L1VPN 600 offers a new business model for joint delivery of services to a 601 customer. Consideration of inter-AS L1VPNs requires further analysis 602 beyond the scope of this document. 604 The inter-SP scenario can be used to construct a single L1VPN from 605 services provided by multiple regional providers. There could be a 606 variety of business relationships among providers and customers, and 607 this scenario contains many more manageability, security, privacy, 608 policy, and commercial issues than the more simple inter-AS L1VPN 609 case. Consideration of inter-SP L1VPN requires further analysis 610 beyond the scope of this document. 612 4.3.5 Scheduling Service 614 In some deployment scenarios, customers of L1VPN services may wish to 615 use layer 1 connections not on-demand, but at a planned time in the 616 future (e.g., tomorrow). Or, even though customers of L1VPN services 617 may wish to use layer 1 connections on-demand, they can tolerate 618 some delay, for example, due to lack of resources at that moment. 620 In those scenarios, the provider can reserve bandwidth at a specified 621 time in the future, and can establish the VPN connections according 622 to a schedule. This makes it possible to use bandwidth more 623 efficiently over time (i.e., support more demand). This service, the 624 scheduling service, may be used to support customers who use layer 1 625 connections for data backup applications, content delivery 626 applications, and some other applications. 628 Furthermore, customers may be able to specify when to release layer 1 629 connections in advance. By considering this information, the provider 630 may be able to further engineer scheduling, which leads to still more 631 efficient bandwidth usage. 633 Note that scheduling of L1VPN services requires time-scoped resource 634 management, which is not well considered in current GMPLS protocols 635 and requires the support of the management plane. In addition, 636 offering scheduling service and on-demand service on the same 637 infrastructure needs careful consideration. 639 5. Reference Model 641 Figure 5.1 describes the L1VPN reference model. 643 : +--------------------+ : 644 : | +------------+ | : 645 : | | Management | | : 646 +------+ : | | system(s) | | : +------+ 647 | C | : | +------------+ | : | CE | +------+ 648 |device| : | | : |device|--| C | 649 +------+ : | +------+ : | of | |device| 650 | : | | |=:=|VPN A| +------+ 651 | : | | | : +------+ 652 +------+ : | | PE | : +------+ 653 +------+ | CE | : | |device| : | CE | +------+ 654 | C | |device| : +------+ +------+ | | : |device| | C | 655 |device|--| of |=:=| |==| |==| |-:-| of |--|device| 656 +------+ |VPN A| : | | | | +------+ : |VPN B| +------+ 657 +------+ : | PE | | P | : +------+ 658 +------+ : |device| |device| : +------+ 659 +------+ | CE | : | | | | +------+ : | CE | +------+ 660 | C |--|device|=:=| |==| |==| |-:-|device|--| C | 661 |device| | of | : +------+ +------+ | | : | of | |device| 662 +------+ |VPN B| : | | P | : |VPN A| +------+ 663 +------+ : | |device| : +------+ 664 | : | | | : +------+ 665 | : | | |=:=| CE | +------+ 666 +------+ : | +------+ : |device| | C | 667 | C | : | | : | of |--|device| 668 |device| : | | : |VPN B| +------+ 669 +------+ : | | : +------+ 670 : | | : 671 Customer | | Customer 672 interface | | interface 673 +--------------------+ 674 |<---- Provider ---->| 675 | network | 677 Key: ==== Layer 1 Connection ---- link 679 Figure 5.1: L1VPN reference model 681 In a L1VPN, layer 1 connections are provided between CEs' data plane 682 interfaces within the same VPN. In Figure 5.1, a connection is 683 provided between the left-hand CE of VPN A and the upper right-hand 684 CE of VPN A, and another connection is provided between the left-hand 685 CE of VPN B and lower right-hand CE of VPN B (shown as "=" mark). 686 These layer 1 connections are called VPN connections. 688 Note that as mentioned in Section 3.1.1, these VPN connections follow 689 the hierarchy defined in [RFC4206]. 691 5.1 Management Systems 693 As shown in the reference model, a provider network may contain one 694 or more management systems. A management system may support functions 695 including provisioning, monitoring, billing and recording. Provider 696 management systems may also communicate with customer management 697 systems in order to provide services. Sections 7 and 11 describe more 698 detail. 700 6. Generic Service Description 702 This section describes generic L1VPN services. Detailed descriptions 703 are provided through specific service models in Section 7. 705 6.1 CE Construct 707 - The CE device may support more than one customer VPN. 708 - CE-PE data plane links (between data plane interfaces) may be 709 shared by multiple VPNs. 711 Note that it is necessary to disambiguate control plane messages 712 exchanged between CE and PE if the CE-PE relationship is applicable 713 to more than one VPN. This makes it possible to determine to which 714 VPN such control plane messages apply. Such disambiguation might be 715 achieved by allocating a separate control channel to each VPN (either 716 using a separate physical channel, a separate logical channel such as 717 IP tunnel, or using separate addressing). 719 A customer addressing realm consists of CE-PE TE link addresses and 720 CE-PE control channel addresses as well as customer site addresses (C 721 and CE addresses). Customer addressing realms may overlap, and may 722 also overlap with the service provider addressing realm. 724 NATs or firewalls might reasonably be placed at customer interfaces, 725 or between administrative domains within the core network. Addressing 726 in the L1VPN model must handle such eventualities. Traversal of NATs 727 and firewalls within the customer network might have implications for 728 L1VPN services that connect C devices, and is for further study. 730 6.2 Generic Service Features 732 L1VPN has the following two generic service features. 734 - Connectivity restriction: Layer 1 connectivity is provided to a 735 limited set of CEs' data plane interfaces, called VPN end points. 736 (This set forms the L1VPN membership.) 738 - Per VPN control and management: Some level of control and 739 management capability is provided to the customer. Details differ 740 depending on service models described in Section 7. 742 7. Service Models 744 This section describes Layer 1 VPN service models that can be 745 supported by GMPLS protocols enabled networks. These models are 746 derived from the generic service description presented above. 748 Such layer 1 networks are managed and controlled using GMPLS 749 signaling as described in [RFC3471] and [RFC3473], and GMPLS routing 750 as described in [RFC4202]. It must be understood that meeting the 751 requirements set out in this document may necessitate extensions 752 to the existing GMPLS protocols both for the control plane within the 753 layer 1 network and for service provisioning at the edge of the 754 network (CE and PE devices). A CE and a PE are connected by one or 755 more data links. The ends of each link are usually represented as 756 GMPLS-capable interfaces. 758 Note that in this document, service models are classified by the 759 semantics of information exchanged over the customer interface. The 760 customer interface may be instantiated by the CE-PE control plane 761 communication and/or the management plane communication between the 762 customer management systems(s) and the provider management system(s). 763 Note that how to realize a CE-PE control channel is discussed in 764 Section 10.1. Customer management system(s) and provider management 765 systems(s) may communicate by utilizing the CE-PE control channel(s). 767 7.1 Management-based Service Model 769 Figure 7.1 describes the management-based service model. 771 +--------------------+ 772 : | | 773 +----------+ : | +----------+ | 774 | Customer | : | | Provider | | 775 |Management| : | |Management| | 776 | system(s)|-:-----+----| system(s)| | 777 +----------+ : | +----------+ | 778 : | | : 779 : | | : 780 +----+ : +----+ +----+ +----+ : +----+ 781 | CE |----:---| PE |----| P |----| PE |---:---| CE | 782 +----+ : +----+ +----+ +----+ : +----+ 783 : | | : 784 : | | : 785 : +--------------------+ : 786 : | | : 787 : |<-Provider network->| : 788 Customer Customer 789 interface interface 791 Figure 7.1: Management-based service model 793 In this service model, customer management systems and provider 794 management systems communicate with each other. Customer management 795 systems access provider management systems to request layer 1 796 connection setup/deletion between a pair of CEs. Customer management 797 systems may obtain additional information, such as resource 798 availability information and monitoring information, from provider 799 management systems. There is no control message exchange between a CE 800 and PE. 802 The provider network may be based on GMPLS. In this case, mechanisms 803 to support soft permanent connections can be applied. However, 804 interfaces between management systems are not within the scope of 805 this document. 807 7.2 Signaling-based Service Model (Basic Mode) 809 In this service model, the CE-PE interface's functional repertoire is 810 limited to path setup signaling only. The provider's network is not 811 involved in distribution of customer network's routing information. 813 Note in addition that there may be communication between customer 814 management system(s) and provider management system(s) in order to 815 provide customers with detailed monitoring, fault information, etc. 817 7.2.1 Overlay Service Model 819 Figure 7.2 describes the Overlay service model. 821 +--------------------+ 822 : | | : 823 : | | : 824 +----+ : +----+ +----+ : +----+ 825 | CE |---:---| PE | | PE |---:---| CE | 826 +----+ : +----+ +----+ : +----+ 827 : | | : 828 : | | : 829 : +--------------------+ : 830 : | | : 831 : |<-Provider network->| : 832 Customer Customer 833 interface interface 835 Figure 7.2: Overlay service model 837 In this service model, the customer interface is based on the GMPLS 838 UNI Overlay [RFC4208]. The CE requests layer 1 connection 839 setup/deletion to a remote CE. There is no routing protocol running 840 (i.e., no routing neighbor/peering relationship) between a CE and 841 a PE. The CE does not receive routing information from remote 842 customer sites, nor routing information about the provider network. 844 The CE's interface may be assigned a public or private address, that 845 designates VPN end points. 847 In this model, membership information needs to be configured on PEs, 848 so that the PE that receives a Path message from the ingress CE can 849 identify the remote PE connected to the egress CE. Distribution of 850 membership information between PEs is typically done by the provider, 851 and may be realized by mechanisms such as static provisioning, or by 852 piggybacking on routing protocols (auto-discovery). 854 There are various ways that customers perceive the provider network. 855 In one example, the whole provider network may be considered as one 856 node - the path specified and recorded in signaling messages reflects 857 this. Note that this is distinct from the Virtual Node service model 858 described in Section 7.3.2 because such a model requires that the 859 network is represented to the VPN sites as a virtual node - that is, 860 some form of routing advertisement is implied, and this is not in 861 scope for the Signaling-based service model. 863 7.3 Signaling and Routing Service Model (Enhanced Mode) 865 In this service model, the CE-PE interface provides the signaling 866 capabilities as in the Basic Mode, plus permits limited exchange of 867 information between the control planes of the provider and the 868 customer to help such functions as discovery of customer network 869 routing information (i.e., reachability or TE information in remote 870 customer sites), or parameters of the part of the provider's network 871 dedicated to the customer. 873 By allowing CEs to obtain customer network routing information, a 874 so-called N-square routing problem could be solved. 876 In addition, by using the received traffic engineering-based routing 877 information, a customer can use traffic engineering capabilities. For 878 example, a customer can set up two disjoint connections between a 879 pair of CEs. Another example is that a customer can request a 880 connection between a pair of devices within customer sites, and not 881 necessarily between CEs, with more effective traffic engineering. 883 As such, the customer interface is based on GMPLS signaling and 884 mechanisms to exchange reachability/TE information. Typically, a 885 routing protocol is used between a CE and PE, or more precisely 886 between a CE and the VPN routing context instantiated on the PE. Link 887 state routing information would be needed to implement the above two 888 example scenarios. Some scenarios may be satisfied with reachability 889 routing information only. 891 Note that this service model does not preclude the use of mechanisms 892 other than routing protocols to exchange reachability/TE information. 894 As with the Signaling-based service model, there may be communication 895 between customer management system(s) and provider management 896 system(s) in order to provide detailed monitoring, fault information 897 etc. to customers. 899 Four specific types of the Signaling and Routing service model are 900 the Overlay Extension service model, the Virtual Node service model, 901 the Virtual Link service model and the Per-VPN Peer service model, 902 depending on how customers perceive the provider network in routing 903 and signaling (i.e., the level of information details that a customer 904 is allowed to receive in routing and signaling). 906 7.3.1 Overlay Extension Service Model 908 This service model complements the Overlay service model. In this 909 service model, a CE receives a list of CE-PE TE link addresses to 910 which it can request a VPN connection (i.e., membership information). 911 This may include additional information concerning these TE links 912 (e.g., switching type). Mechanisms other than routing could be used 913 to exchange reachability/TE information between the CE and the PE. 915 7.3.2 Virtual Node Service Model 917 Figure 7.3 describes the Virtual Node service model. 919 +--------------------+ 920 : | | : 921 +----+ : | | : +----+ 922 | CE |---:---| Virtual Node |---:---| CE | 923 +----+ : | | : +----+ 924 : | | : 925 : +--------------------+ : 926 : | | : 927 : |<-Provider network->| : 928 Customer Customer 929 interface interface 931 Figure 7.3: Virtual Node service model 933 In this type of service model, the whole provider network is 934 represented as a virtual node (defined in Section 2). The customer 935 perceives the provider network as one single node, i.e., a 936 Generalized Virtual Private Cross-Connect (GVPXC). The CE receives 937 routing information about CE-PE links and customer network (i.e., 938 remote customer sites). 940 Note that in this service model, there must be one single virtual 941 node, and this virtual node must be connected with every CE in the 942 VPN. 944 7.3.3 Virtual Link Service Model 946 Figure 7.4 describes the Virtual Link service model. 948 +--------------------+ 949 : | | : 950 : | Virtual | : 951 +----+ : +----+ link +----+ : +----+ 952 | CE |---:---| PE |**************| PE |---:---| CE | 953 +----+ : +----+ +----+ : +----+ 954 : | | : 955 : +--------------------+ : 956 : | | : 957 : |<-Provider network->| : 958 Customer Customer 959 interface interface 961 Figure 7.4: Virtual Link service model 963 In this service model, a virtual link is constructed between PEs. 964 For the definition of a virtual link, please refer to terminology in 965 Section 2. A virtual link is assigned to each VPN and disclosed to 966 the corresponding CEs. As such, the CE receives routing information 967 about CE-PE links, customer network (i.e., remote customer sites), as 968 well as virtual links assigned to each VPN. A special property of the 969 virtual links used in this service model is that the provider network 970 allocates data plane link resources for the exclusive use of each 971 virtual link. The TE attributes of a virtual link are determined 972 according to data plane link resources allocated to this virtual 973 link. Virtual links are an abstraction of the provider network to 974 customers for administrative purposes as well as to exclude 975 "unnecessary information". 977 Note that in this service model, both end points of each virtual link 978 must be a PE device. 980 7.3.4 Per-VPN Peer Service Model 982 Figure 7.5 describes the Per-VPN Peer service model. 984 +--------------------+ 985 : | | : 986 +----+ : +----+ +----+ +----+ : +----+ 987 | CE |---:---| PE |----| P |----| PE |---:---| CE | 988 +----+ : +----+ +----+ +----+ : +----+ 989 : | | : 990 : +--------------------+ : 991 : | | : 992 : |<-Provider network->| : 993 Customer Customer 994 interface interface 996 Figure 7.5: Per-VPN Peer service model 998 This service model is a generalization and combination of the Virtual 999 Link service model and the Virtual Node service model mentioned in 1000 Sections 7.3.2 and 7.3.3 respectively. 1002 In this service model, the provider partitions the TE links within 1003 the provider network per VPN, and discloses per-VPN TE link 1004 information to corresponding CEs. As such, a CE receives routing 1005 information about CE-PE links, customer network (i.e., remote 1006 customer sites), as well as partitioned portions of the provider 1007 network. 1009 Note that PEs may advertise abstracted routing information about the 1010 provider network to CEs for administrative purpose as well as to 1011 exclude "unnecessary information". In other words, virtual links may 1012 be constructed between two nodes where direct data links do not 1013 exist, or virtual nodes may be constructed to represent multiple 1014 physical nodes and links between them. 1016 In the Per-VPN Peer service model, at least one virtual node 1017 corresponding to P devices (one single P or a set of Ps) must be 1018 visible to customers. 1020 8. Service Models and Service Requirements 1022 The service models mentioned in Section 7 are related to what 1023 information is exchanged between CE and PE. In addition, service 1024 models differ in how data plane resources are allocated for each VPN. 1026 Note that in the ITU-T documents, the term "U-Plane" is used instead 1027 of "data plane". 1029 o Data plane resource allocation 1031 - Shared or dedicated: 1033 Shared means that provider network data plane links are shared by 1034 multiple (i.e., any or a specific set of) VPNs. (Data plane links 1035 are dynamically allocated to a VPN when a VPN connection is 1036 requested, and data plane links allocated to one VPN at one time 1037 can be allocated to another VPN at another time.) 1039 Dedicated means that provider network data plane links are 1040 partitioned per VPN. (Data plane links are statically allocated 1041 to one VPN and can not be used by other VPNs.) 1043 o Information exchanged between CE and PE 1045 - Signaling 1046 - Membership information (optionally includes TE information of the 1047 associated CE-PE TE links) 1048 - Customer network routing information (reachability only, or may 1049 include TE information) 1050 - Provider network routing information (TE information) 1052 Note that link management information (e.g., LMP [RFC4204]) may be 1053 exchanged between a CE and a PE, but this is orthogonal to the 1054 definition of the service models. 1056 Table 1 shows combination of service requirements and service models. 1058 | Data plane | Data plane 1059 | shared | dedicated 1060 ---------------------------+------------------+------------------- 1061 Signaling | Overlay | Overlay 1062 ---------------------------+------------------+------------------- 1063 Signaling + | Overlay | Overlay 1064 Membership information | Extension | Extension 1065 ---------------------------+------------------+------------------- 1066 Signaling + | | 1067 Membership information + | Virtual Node | Virtual Node 1068 Customer network routing | | 1069 information | | 1070 ---------------------------+------------------+------------------- 1071 Signaling + | | 1072 Membership information + | | Virtual Link 1073 Customer network routing | Not applicable | 1074 information + | | Per-VPN Peer 1075 Provider network routing | | 1076 information | | 1078 Table 1: Combination of service requirements and service models 1080 As described in previous sections, the difference between the Virtual 1081 Link service model and the Per-VPN Peer service model is whether 1082 customers have visibility of P devices. In the Virtual Link service 1083 model, the end points of virtual links must be PE devices, thus P 1084 devices are not visible to customers. In the Per-VPN Peer service 1085 model, at least one virtual node corresponding to P devices (one 1086 single P, or a set of Ps) is visible to customers. 1088 Note that when customers receive provider network routing information 1089 in the form of virtual link, customers must be able to specify such 1090 links for a VPN connection over the provider network in signaling. 1092 8.1 Detailed Service Level Requirements 1094 In addition to the requirements set out in table 1, more detailed 1095 service requirements are provided below. They are generally common to 1096 the various service models, except where indicated. 1098 - Selection of layer 1 service class: Customers MAY be allowed to 1099 specify a layer 1 service class (e.g., availability level) for a 1100 VPN connection. Further details are described in Section 9. 1102 - Reception of performance information: Customers MAY be allowed to 1103 receive performance information for their VPN connections (e.g., 1104 performance monitoring data). When data plane links are dedicated, 1105 customers MAY be allowed to receive performance information for 1106 links dedicated to them. 1108 - Reception of fault information: Customers MAY be allowed to receive 1109 fault information for their VPN connections (e.g., failure 1110 notification by RSVP-TE, data plane alarm notification through the 1111 management plane, notification of connection setup rejection 1112 causes). Note that this does not prevent customers from using OAM 1113 mechanisms for or on their VPN connections. When data plane links 1114 are dedicated, customers MAY be allowed to receive fault 1115 information for links dedicated to them. 1117 - Reception of connection information: Customers MAY be allowed to 1118 receive information for current VPN connections (through the 1119 management plane). 1121 - Reception of accounting information: Customers MUST be able to 1122 receive accounting information for each VPN. 1124 - Specification of policy: Customers MAY be allowed to specify 1125 policies (e.g., path computation policies, recovery policies 1126 including parameters) for each VPN. 1128 - Security: The communication between the customer and the provider 1129 MUST be secure. Further details are described in Section 12. 1131 - Filtering: Unnecessary information (e.g., information concerning 1132 other VPNs) MUST NOT be provided to each customer. This applies 1133 particularly to the Signaling and Routing service model, but is 1134 also relevant to the Signaling-based service model and to the 1135 Management-based service model. Further details are described in 1136 Section 12. 1138 9. Recovery Aspects 1140 9.1 Recovery Scope 1142 GMPLS provides various recovery techniques for use in different 1143 recovery scenarios [RFC4427]. The provider network may apply these 1144 recovery techniques to protect VPN connections as part of the L1VPN 1145 service, for example as follows. 1147 o PE-PE recovery 1149 The provider network constitutes a recovery domain, and the 1150 recovery scope is the PE-PE part of the CE-CE VPN connection. 1152 It should be possible for the provider network to hide the provider 1153 network recovery operation from the customer. Namely, it should be 1154 possible to configure the provider network to not notify the 1155 customer when a failure occurs and a PE-PE recovery operation 1156 successfully repairs the failure. Further, when PE-PE recovery 1157 fails and the failure should be notified to the customer, it should 1158 be possible for the provider network to hide its internal topology. 1160 o CE-PE recovery 1162 The recovery scope is either or both of the ingress and egress 1163 CE-PE links of the CE-CE VPN connection. 1165 o CE-CE recovery 1167 The recovery scope is the entire CE-CE VPN connection. 1169 When a failure needs to be notified to a customer so that the 1170 customer can initiate recovery operation, it should be possible for 1171 the provider network to hide its internal topology. 1173 These recovery schemes may be applied in combination. 1175 Customers may be allowed to specify the desired recovery level in a 1176 connection setup request. Furthermore, the customer may be allowed to 1177 specify the desired recovery level in a way that is agnostic of the 1178 recovery technique (e.g., when the recovery operation does not 1179 require cooperation between the provider network and the customer 1180 network). In such cases, the provider network must translate the 1181 specified recovery level into specific recovery techniques, based on 1182 operational policies. This allows enhanced recovery techniques above 1183 and beyond the GMPLS specifications to be used in the provider 1184 network. 1186 9.2 Recovery Resource Sharing Schemes 1188 The provider network may support various recovery resource sharing 1189 schemes, such as the following. 1191 o Shared recovery 1193 When the provider network supports shared recovery (e.g., shared 1194 mesh restoration [RFC4427]), the provider network may provide 1195 sharing recovery resources between VPN connections that serve with 1196 only the same VPN, a specific set of VPNs, or any VPN. The default 1197 mode is sharing recovery resources with any VPN. 1199 o Extra traffic 1201 GMPLS recovery mechanisms support extra traffic. Extra traffic 1202 allows the transfer of preemptable traffic on the recovery 1203 resources when these resources are not being used for the recovery 1204 of protected normal traffic [RFC4427]. 1206 In the context of L1VPNs, extra traffic is applied for CE-CE VPN 1207 connections, or PE-PE part of CE-CE VPN connections. The latter 1208 case may be applied only when there is hierarchy (i.e., CE-CE VPN 1209 connection is nested on top of PE-PE connection). In this section, 1210 the latter aspect is analyzed. 1212 When the provider network allows a CE-CE VPN connection to be set 1213 up as "extra traffic", it means that the VPN connection may use a 1214 PE-PE connection that protects some other CE-CE VPN connection. In 1215 such a case the provider network may restrict extra traffic CE-CE 1216 VPN connection to use resources (i.e., the PE-PE connections) that: 1218 - protect VPN connections from the same VPN as the extra traffic 1219 connection 1220 - are used for a specific set of VPNs 1221 - are available for any VPN. 1223 The default mode is to support preemptable traffic on recovery 1224 resources reserved for any VPN. 1226 10. Control Plane Connectivity 1228 10.1 Control Plane Connectivity between a CE and a PE 1230 In the Signaling-based service model and the Signaling and Routing 1231 service model, there must be a control channel (IP level 1232 connectivity) between a CE and its PE. The instantiation of the 1233 control channel may differ depending on addressing and security. 1235 As stated in Section 6.1, it is necessary to disambiguate control 1236 plane messages exchanged between the CE and PE if the CE-PE 1237 relationship is applicable to more than one VPN. Furthermore, private 1238 addresses may be assigned to CE-PE control channels. 1240 Security aspects of the CE-PE control channel are discussed in 1241 Section 12. 1243 10.2 Control Plane Connectivity between CEs 1245 A customer network connected by VPN connections may be controlled by 1246 MPLS or GMPLS, and the VPN connections may be treated as TE links 1247 within the customer network. In such cases, there must be control 1248 plane (IP level) connectivity between the CEs, so that control 1249 messages, such as signaling and routing messages, can be exchanged 1250 between the CEs. Furthermore, in some recovery techniques, Notify 1251 message exchange is needed between the ingress and egress of the VPN 1252 connection, which requires control plane connectivity between the 1253 CEs. There are several potential ways to achieve this. 1255 o Use of VPN connections as in-band control channels 1257 If the CEs have the ability to inject control messages into the VPN 1258 connections and to extract the messages at the far end of the VPN 1259 connections, then control messages can be exchanged in-band. For 1260 example, when a VPN connection is a PSC TE link in the customer 1261 network this operation is transparent to the L1VPN service 1262 provider. 1264 o Use of overhead associated with the VPN connections 1266 If the VPN connection provides connectivity in the customer network 1267 at a different switching capability (implying network technology 1268 layer) from that used by the provider network to support the CE-PE 1269 and PE-PE connectivity, then the customer network can utilize any 1270 overhead available within the VPN connection as a control channel 1271 to connect the CEs. For example, if a VPN connection provides a TDM 1272 TE link in the customer network but is supported by a technology 1273 such as lambda or fiber, then the CEs may utilize the overhead 1274 (DCC) as a control channel, if the network supports transparent 1275 transfer of such overhead. This operation is transparent to the 1276 L1VPN service provider. 1278 o Use of control channel specific VPN connections 1280 A customer establishes VPN connections dedicated as control 1281 channels. This operation is transparent to the L1VPN service 1282 provider, but since control plane traffic is likely to be 1283 relatively low compared with the capacity of VPN connections, this 1284 may be an expensive solution for the customer. 1286 o Use of separate network 1288 A customer may utilize another network and network service, such as 1289 private line service, L3VPN service, L2VPN service, or Internet 1290 access service, to establish CE-CE control channel connectivity. 1291 This operation is transparent to the L1VPN service provider. 1293 o Use of CE-PE control channels 1295 In the Signaling-based service model, and the Signaling and Routing 1296 service model, there must be control plane (IP level) connectivity 1297 between the CE and PE, as described in Section 10.1. 1299 By utilizing this, CE-CE control message exchange could be realized 1300 as part of the service provided by the L1VPN service provider. 1301 Namely, the provider network transfers control messages received 1302 over the CE-PE control channel to the other side of the provider 1303 network and delivers them through the PE-CE control channel. The 1304 realization of this within the provider network is up to the 1305 operator, but where the provider network uses a GMPLS control 1306 plane, the customer control plane messages could be forwarded 1307 through the provider control plane, perhaps using IP tunnels. 1309 Care must be taken to protect the provider network and other 1310 customers from Denial of Service (DoS) attack. Traffic saturation 1311 over the control plane network needs to be carefully managed as 1312 well. Note that if private addresses are assigned to the CE-PE 1313 control channels, the provider network must support VPN-scoped 1314 routing and forwarding for control messages. 1316 11. Manageability Considerations 1318 Manageability considerations for GMPLS are described in existing 1319 documents, such as [RFC3945]. Also, manageability considerations for 1320 L3VPN are described in existing documents, such as [RFC4176]. These 1321 manageability considerations should also be applied in L1VPNs, and 1322 these aspects are described in this section. In addition, there are 1323 some specific manageability considerations for L1VPNs, such as 1324 configuration and accounting. 1326 o Fault management 1328 The provider network MUST support fault management. It MUST support 1329 liveness detection, monitoring and verification of correct 1330 operation. 1332 When a failure occurs, the provider network SHOULD correlate the 1333 failure. Also, it SHOULD be able to detect which customer is 1334 affected by the failure. 1336 If the provider network can resolve failures without intervention 1337 from the customer network, it MUST be possible to configure the 1338 provider network to not report failures to the customers. However, 1339 it MAY be part of an agreement between a customer and provider that 1340 failures are reported to the customer regardless. 1342 o Configuration management 1344 The provider network MUST support configuration management, such as 1345 the following. 1347 - Service mode/model configuration 1348 - Network representation configuration: Configuration of virtual 1349 node and virtual link 1350 - Resource allocation configuration: Dedicated, shared. See Section 1351 8 for more detail. 1352 - Recovery policy configuration: For example, recovery resource 1353 sharing schemes, such as shared recovery, extra traffic. See 1354 Section 9 for more detail. 1355 - Membership configuration 1356 - Network/Element level configuration: For example, TE link 1357 configuration 1359 It SHOULD be possible for the provider network to verify that 1360 configuration is correctly made. 1362 o Accounting management 1364 The provider network MUST support accounting management. It MUST be 1365 able to record usage of VPN connections for each customer. 1367 o Performance management 1369 The provider network MUST support performance management. 1371 In particular, it MUST support performance monitoring of parameters 1372 associated with the Service Level Agreement (SLA), such as bit 1373 error rate per VPN connections, and SLA verification. 1375 In addition, it MUST support performance monitoring and analysis of 1376 parameters related to the network and equipment not directly 1377 associated with the SLA, such as network resource utilization. 1379 o Security management 1381 The provider network MUST support security management. See Section 1382 12 for details. 1384 o Management systems 1386 In order to support various management functionalities, the 1387 provider network relies on management systems and related tools. 1388 GMPLS protocols and potential extensions of GMPLS MUST be able to 1389 work with management systems and related tools to provide such 1390 functionalities. 1392 In particular, MIB modules for GMPLS protocols and potential 1393 extensions MUST be supported. 1395 o Management of customer networks 1397 Customers MAY outsource management of their network (especially CEs 1398 and CE-CE links) to the provider network. In such case, the 1399 provider MUST be able to manage the customer network, as well as 1400 the provider network. 1402 12. Security Considerations 1404 Security is clearly one of the essential requirements in L1VPNs. In 1405 this section, key security requirements are highlighted. Security 1406 considerations for L3VPNs and L2VPNs are described in existing 1407 documents, such as [RFC4110], [RFC4111] and [L2VPN-FW]. These 1408 security considerations should also be applied in L1VPNs, and these 1409 aspects are described in this section. In addition, there are some 1410 specific security considerations for L1VPNs, such as connectivity 1411 restriction and shared control links. 1413 This section first describes types of information to be secured. 1414 Then, security features or aspects are described. Finally, some 1415 considerations concerning scenarios where security mechanisms are 1416 applied is described. 1418 12.1 Types of Information 1420 It MUST be possible to secure the information exchanged between the 1421 customer and the provider. This includes data plane information, 1422 control plane information, and management plane information. 1424 At layer 1, data plane information is normally assumed to be secured 1425 once connections are established, since those connections are 1426 dedicated to each VPN. That is, it is not possible to communicate 1427 unless there is a connection. Therefore, in L1VPNs, the main concern 1428 of data plane security is restricting VPN connections to be used 1429 only within the same VPN, as described in Section 6.2. Note that a 1430 customer may wish to assure data plane information security against 1431 not only other customers, but also the provider. In such case, the 1432 customer may wish to apply their own security mechanisms for data 1433 plane information (CE-CE security), as later described. 1435 In addition, information contained in the provider network MUST be 1436 secured. This includes VPN service contract information, current VPN 1437 connection information, VPN membership information, and system 1438 information. Note these types of information MAY be accessible to 1439 authorized entities. 1441 12.2 Security Features 1443 Security features include the following: 1445 o Data integrity 1447 The information exchanged between the customer and the provider 1448 MUST be delivered unchanged. 1450 o Confidentiality 1452 The information exchanged between the customer and the provider 1453 MUST NOT be disclosed to a third party. 1455 o Authentication 1457 The entity requesting the service to the provider MUST be 1458 identified and have its identify authenticated, and the provider 1459 providing the service MUST also be identified and have its 1460 identify authenticated. 1462 o Access control 1464 Access to the information contained in the provider network, which 1465 may be information about the customer networks or the existence of 1466 customers, as well as about the provider network, MUST be 1467 restricted to the authorized entity. 1469 o DoS attack detection and protection 1471 The provider network MUST have mechanisms to detect DoS attack and 1472 to protect against it reactively and proactively. 1474 12.3 Scenarios 1476 There are two scenarios (or occasions) in which security mechanisms 1477 are applied. One is the service contract phase, where security 1478 mechanisms are applied once. The other is the service access phase, 1479 where security mechanisms are applied every time the service is 1480 requested. 1482 o Service contract scenario (static) 1484 This scenario includes the addition of new physical devices, such 1485 as CE devices, data links and control links. It MUST be guaranteed 1486 that these physical devices are connected to the right entity. In 1487 addition, authority to access specific information MAY be given to 1488 each customer as a part of service contract. 1490 o Service access scenario (dynamic) 1492 This scenario includes the reception of connection requests, 1493 routing information exchange requests (e.g., attempts to establish 1494 a neighbor relationship in routing protocols, or command request 1495 via the management plane interface), and management information 1496 retrieval requests. If a communication channel between the customer 1497 and the provider (control channel, management interface) is 1498 physically separate per customer, and the entity connected over 1499 this communication channel is identified in the service contract 1500 phase, the provider can ensure who is requesting the service. Also, 1501 the communication channel could be considered as secure. However, 1502 when communication channel is physically shared among customers, 1503 security mechanisms MUST be available and SHOULD be enforced. 1504 Examples of such security mechanisms include IPsec [RFC2402] and 1505 [RFC2406]. Note that even in the case of physically separate 1506 communication channels, customers may wish to apply security 1507 mechanisms to assure higher security, and such mechanisms MUST be 1508 available. 1510 When the entity requesting the service is identified, the provider 1511 MUST ensure that the request is authorized for that entity. This 1512 includes assuring that connection request is between VPN end points 1513 belonging to the same VPN. 1515 Also note that customers may wish to apply their own security 1516 mechanisms for data plane information (CE-CE security). This 1517 includes IPsec [RFC2402] and [RFC2406] for IP traffic. 1519 13. IANA Considerations 1521 This informational document makes no requests for IANA action. 1522 [RFC Editor - please remove this entire section before publication] 1524 14. Acknowledgements 1526 The material in this document is based on the work of the ITU-T Study 1527 Group 13. 1529 We would like to thank Dimitri Papadimitriou, Deborah Brungard, 1530 Yakov Rekhter, Alex Zinin, Igor Bryskin, Adrian Farrel and Ross 1531 Callon for their useful comments and suggestions. 1533 Thanks to Mark Townsley, Dan Romascanu, and Cullen Jennings for 1534 helpful input during IESG review. 1536 15. Normative References 1538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1539 Requirement Levels", BCP 14, RFC 2119, March 1997. 1541 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol 1542 label switching Architecture", RFC 3031, January 2001. 1544 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 1545 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1546 Tunnels", RFC 3209, December 2001. 1548 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 1549 Switching (GMPLS) Signaling Functional Description", 1550 RFC 3471, January 2003. 1552 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label 1553 Switching (GMPLS) Signaling - Resource ReserVation 1554 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1555 RFC 3473, January 2003. 1557 [RFC3945] Mannie, E., Editor, "Generalized Multi-Protocol Label 1558 Switching (GMPLS) Architecture", RFC 3945, October 2004. 1560 [RFC4026] Anderssion, L., and Madsen, T., "Provider Provisioned 1561 Virtual Private Network (VPN) Terminology", RFC 4026, 1562 March 2005. 1564 [RFC4202] Kompella, K., and Rekhter, Y., Editors, "Routing 1565 Extensions in Support of Generalized Multi-Protocol 1566 Label Switching (GMPLS)", RFC 4202, October 2005. 1568 [RFC4208] Swallow, G., et al., "Generalized Multiprotocol Label 1569 Switching (GMPLS) User-Network Interface (UNI): 1570 Resource ReserVation Protocol-Traffic Engineering 1571 (RSVP-TE) Support for the Overlay Model", RFC 4208, 1572 October 2005. 1574 For information on the availability of this document, please see 1575 http://www.itu.int. 1577 [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic 1578 requirements and architecture elements, ITU-T 1579 Recommendation, September 2003. 1581 16. Informative References 1583 For information on the availability of this document, please see 1584 http://www.itu.int. 1586 [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and 1587 network architectures, ITU-T Recommendation, July 2004. 1589 [RFC2402] Kent, S., and Atkinson, R., " IP Authentication 1590 Header," RFC 2402, November 1998. 1592 [RFC2406] Kent, S., and Atkinson, R., " IP Encapsulating 1593 Security Payload (ESP)," RFC 2406, November 1998. 1595 [RFC4110] Callon, R., and Suzuki, M., Editors, "A Framework 1596 for Layer 3 Provider Provisioned Virtual Private 1597 Networks (PPVPNs)", RFC4110, July 2005. 1599 [RFC4111] Fang., L. (Editor), "Security Framework for 1600 Provider-Provisioned Virtual Private Networks 1601 (PPVPNs)," RFC 4111, July 2005. 1603 [RFC4176] Mghazli, Y. El, Editor, "Framework for Layer 3 1604 Virtual Private Networks (L3VPN) Operations and 1605 Management," RFC 4176, October 2005. 1607 [RFC4139] Papadimitriou, D., et al., "Requirements for 1608 Generalized MPLS (GMPLS) Signaling Usage and 1609 Extensions for Automatically Switched Optical Network 1610 (ASON)," RFC 4139, July 2005. 1612 [RFC4204] Lang, J., Editor, "Link Management Protocol (LMP)," 1613 RFC 4204, October 2005. 1615 [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths 1616 (LSP) Hierarchy with Generalized Multi-Protocol Label 1617 Switching (GMPLS) Traffic Engineering (TE)," RFC 1618 4206, October 2005. 1620 [RFC4258] Brungard, D., Editor, "Requirements for Generalized 1621 Multi-Protocol Label Switching (GMPLS) Routing for 1622 the Automatically Switched Optical Network (ASON)," 1623 RFC 4258, November 2005. 1625 [RFC4427] Mannie, E., and Papadimitriou, D., Editors, 1626 "Recovery (Protection and Restoration) Terminology 1627 for Generalized Multi-Protocol Label Switching 1628 (GMPLS)", RFC 4427, March 2006. 1630 [L2VPN-FW] Andersson, L., and Rosen, E., Editors, "Framework 1631 for Layer 2 Virtual Private Networks (L2VPNs)", 1632 draft-ietf-l2vpn-l2-framework, work in progress. 1634 17. Authors' Addresses 1636 Raymond Aubin 1637 Nortel Networks 1638 P O Box 3511 Station C 1639 Ottawa, ON K1Y 4H7 Canada 1640 Phone: +1 (613) 763 2208 1641 Email: aubin@nortel.com 1643 Marco Carugi 1644 Nortel Networks S.A. 1645 Parc d'activites de Magny-Chateaufort 1646 Les Jeunes Bois - MS CTF 32B5 - Chateaufort 1647 78928 YVELINES Cedex 9 - FRANCE 1648 Phone: +33 1 6955 7027 1649 Email: marco.carugi@nortel.com 1651 Ichiro Inoue 1652 NTT Network Service Systems Laboratories, NTT Corporation 1653 3-9-11, Midori-Cho 1654 Musashino-Shi, Tokyo 180-8585 Japan 1655 Phone: +81 422 59 6076 1656 Email: inoue.ichiro@lab.ntt.co.jp 1658 Hamid Ould-Brahim 1659 Nortel Networks 1660 P O Box 3511 Station C 1661 Ottawa, ON K1Y 4H7 Canada 1662 Phone: +1 (613) 765 3418 1663 Email: hbrahim@nortel.com 1665 Tomonori Takeda 1666 NTT Network Service Systems Laboratories, NTT Corporation 1667 3-9-11, Midori-Cho 1668 Musashino-Shi, Tokyo 180-8585 Japan 1669 Phone: +81 422 59 7434 1670 Email : takeda.tomonori@lab.ntt.co.jp 1672 18. Intellectual Property Consideration 1674 The IETF takes no position regarding the validity or scope of any 1675 Intellectual Property Rights or other rights that might be claimed 1676 to pertain to the implementation or use of the technology 1677 described in this document or the extent to which any license 1678 under such rights might or might not be available; nor does it 1679 represent that it has made any independent effort to identify any 1680 such rights. Information on the procedures with respect to 1681 rights in RFC documents can be found in BCP 78 and BCP 79. 1683 Copies of IPR disclosures made to the IETF Secretariat and any 1684 assurances of licenses to be made available, or the result of an 1685 attempt made to obtain a general license or permission for the use 1686 of such proprietary rights by implementers or users of this 1687 specification can be obtained from the IETF on-line IPR repository 1688 at http://www.ietf.org/ipr. 1690 The IETF invites any interested party to bring to its attention 1691 any copyrights, patents or patent applications, or other 1692 proprietary rights that may cover technology that may be required 1693 to implement this standard. Please address the information to the 1694 IETF at ietf-ipr@ietf.org. 1696 19. Full Copyright Statement 1698 Copyright (C) The IETF Trust (2007). 1700 This document is subject to the rights, licenses and restrictions 1701 contained in BCP 78, and except as set forth therein, the authors 1702 retain all their rights. 1704 This document and the information contained herein are provided on an 1705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1707 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1708 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1709 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.