idnits 2.17.1 draft-takeda-l1vpn-applicability-basic-mode-00.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 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 780. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (October 2006) is 6403 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 draft: draft-ietf-l1vpn-framework (ref. 'L1VPN-FW') Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft Tomonori Takeda (Editor) 4 Proposed Status: Informational NTT 5 Expires: April 2007 October 2006 7 Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) 8 Basic Mode 10 draft-takeda-l1vpn-applicability-basic-mode-00.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 Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document provides an applicability statement on the use of 38 Generalized Multiprotocol Label Switching (GMPLS) protocols and 39 mechanisms to support Basic Mode Layer 1 Virtual Private Networks 40 (L1VPNs). 42 L1VPNs provide customer services and connectivity at layer 1 over 43 layer 1 networks. The operation of L1VPNs is divided into the Basic 44 Mode and the Enhanced Mode where the Basic Mode of operation does not 45 feature any exchange of routing information between the layer 1 46 network and the customer domain. This document examines how GMPLS 47 protocols can be used to satisfy the requirements of a Basic Mode 48 L1VPN. 50 Table of Contents 52 1. Contributors...................................................2 53 2. Terminology....................................................3 54 3. Introduction...................................................3 55 4. Basic Mode Overview............................................3 56 5. Supported Network Types........................................4 57 5.1 Data Plane....................................................4 58 5.2 Control Plane.................................................4 59 6. Addressing.....................................................5 60 7. Provider Control of its Infrastructure.........................5 61 7.1 Provisioning Model............................................5 62 7.2 PE-PE Segment Control.........................................6 63 7.2.1 Path Computation and Establishment..........................6 64 7.2.2 Resource Management.........................................7 65 7.2.3 Consideration of CE-PE TE information.......................7 66 7.3 Connectivity Restriction......................................8 67 8. Customer Control of its VPN....................................8 68 8.1 Topology Control..............................................8 69 8.2 Note on Routing...............................................8 70 9. Scalability, Resiliency........................................9 71 9.1 Scalability...................................................9 72 9.2 Data Plane Resiliency........................................10 73 9.3 Control Plane Resiliency.....................................11 74 10. Security.....................................................11 75 10.1 Topology Confidentiality....................................11 76 10.2 External Control of the Provider Network....................12 77 10.3 Data Plane Security.........................................12 78 10.4 Control Plane Security......................................13 79 11. Management...................................................14 80 12. References...................................................14 81 12.1 Normative References........................................14 82 12.2 Informative References......................................14 83 13. Acknowledgments..............................................15 84 14. Author's Addresses...........................................15 85 15. Intellectual Property Consideration..........................16 86 16. Full Copyright Statement.....................................17 88 1. Contributors 90 This document is the result of contributions from several authors who 91 are listed here in alphabetic order. Contact details for these 92 authors can be found in a separate section near the end of this 93 document. 95 Deborah Brungard (AT&T) 96 Adrian Farrel (Old Dog Consulting) 97 Hamid Ould-Brahim (Nortel Networks) 98 Dimitri Papadimitriou (Alcatel) 99 Tomonori Takeda (NTT) 101 2. Terminology 103 The reader is assumed to be familiar with the terminology in 104 [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026] and 105 [L1VPN-FW]. 107 3. Introduction 109 This document provides an applicability statement on the use of 110 Generalized Multiprotocol Label Switching (GMPLS) protocols and 111 mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as 112 specified in [L1VPN-FW]. 114 The operation of L1VPNs is divided into the Basic Mode and the 115 Enhanced Mode. The Basic Mode of operation does not feature any 116 exchange of routing information between the layer 1 network and the 117 customer domain, while the Enhanced Mode of operation features 118 exchange of routing information between the layer 1 network and the 119 customer domain. 121 The main GMPLS protocols and mechanisms applicable to the L1VPN Basic 122 Mode are [L1VPN-BM], [L1VPN-BGP-DISC], and [L1VPN-OSPF-DISC], along 123 with several other documents referenced within this document. 125 Note that discussion in this document is focused on areas where GMPLS 126 protocols and mechanisms are relevant. 128 4. Basic Mode Overview 130 As described in [L1VPN-FW], in the Basic Mode service model, there is 131 no routing exchange between the CE and the PE. CE-CE VPN connections 132 are set up by GMPLS signaling between the CE and the PE, and then 133 across the provider network. A VPN connection is limited to the 134 connection between CEs belonging to the same VPN. 136 Note that in L1VPNs, routing operates within the provider network and 137 may be used by PEs to exchange information specific to the VPNs 138 supported by the provider network (e.g., membership information). 140 In the L1VPN Basic Mode, the provider network is completely under the 141 control of the provider. This includes the PE-PE segment of the CE-CE 142 VPN connection that is controlled and computed by the provider (PE-PE 143 segment control). On the other hand, the VPN itself, constructed from 144 a set of CEs and the VPN connections provided by the provider, is 145 under the control of each customer. This includes that a customer can 146 request between which CEs a connection is to be established (topology 147 control). Note that a customer may outsource the management of its 148 VPN to a third party, including to the provider itself. There is a 149 confidentiality requirement between the provider and each customer. 151 [L1VPN-BM], which expands [RFC4208], specifies GMPLS signaling to 152 establish CE-CE VPN connections. 154 [L1VPN-BGP-DISC] and [L1VPN-OSPF-DISC] specify alternative mechanisms 155 to exchange membership information between PEs, based on BGP and OSPF 156 respectively. 158 5. Supported Network Types 160 5.1 Data Plane 162 The provider network can be constructed from any type of layer 1 163 switches, such as Time Division Multiplexing (TDM) switches, Optical 164 Cross-Connects (OXCs), or Photonic Cross-Connects (PXCs). 165 Furthermore, a PE may be an Ethernet Private Line (EPL) type of 166 device, that maps Ethernet frames onto layer 1 connections (by means 167 of Ethernet over TDM etc.). The provider network may be constructed 168 from switches providing a single switching granularity (e.g., only 169 VC3 switches), or from switches providing multiple switching 170 granularities (e.g., from VC3/VC4 switches, or from VC3 switches and 171 OXCs). The provider network may provide a single type of VPN 172 connection (e.g., VC3 connections only), or multiple types of 173 connection (e.g., VC3/VC4 connections, or VC3 connections and 174 wavelength connections). 176 A CE does not have to have the capability to switch at layer 1, but 177 it must be capable of receiving a layer 1 signal and either switching 178 it or terminating it with adaptation. 180 As described in [L1VPN-FW] and [L1VPN-BM], a CE and a PE are 181 connected by one or more links. A CE may also be connected to more 182 than one PE, and a PE may have more than one CE connected to it. 184 A CE may belong to a single VPN, or to multiple VPNs, and a PE may 185 support one or more VPNs through a single CE or through multiple CEs. 187 5.2 Control Plane 189 The provider network is controlled by GMPLS. L1VPN Basic Mode 190 provider networks are limited to a single AS within the scope of this 191 document. Multi-AS Basic Mode L1VPNs are for future study. 193 As described in [L1VPN-FW] and [L1VPN-BM], a CE and a PE need to be 194 connected by at least one control channel. It is necessary to 195 disambiguate control plane messages exchanged between a CE and a PE 196 if the CE-PE relationship is applicable to more than one VPN. This 197 makes it possible to determine to which VPN such control plane 198 messages apply. Such disambiguation can be achieved by allocating a 199 separate control channel to each VPN (either using a separate 200 physical channel, a separate logical channel such as an IP tunnel, or 201 using separate addressing). 203 GMPLS allows any type of control channel to be used, as long as there 204 is IP level reachability. In the L1VPN context, instantiation of a 205 control channel between a CE and a PE may differ depending on 206 security requirements, etc. This is discussed in Section 10. 208 6. Addressing 210 As described in [L1VPN-BM], the L1VPN Basic Mode allows that customer 211 addressing realms overlap with each other, and also overlap with the 212 service provider addressing realm. That is, a customer network may 213 re-use addresses used by the provider network, and may re-use 214 addresses used in another customer network supported by the same 215 provider network. This is the same as in any other VPN model. 217 In addition, the L1VPN Basic Mode allows a CE-PE control channel 218 addressing realm overlap. Furthermore, once a VPN connection has been 219 established, the L1VPN Basic Mode does not enforce any restriction on 220 address assignment for this VPN connection (treated as a link) for 221 customer network operation (e.g., IP network, MPLS network). 223 7. Provider Control of its Infrastructure 225 7.1 Provisioning Model 227 As described in [L1VPN-BM], for each VPN that has at least one 228 customer-facing port on a given PE, the PE maintains a Port 229 Information Table (PIT) associated with that VPN. A PIT provides a 230 cross-reference between Customer Port Indices (CPIs) and Provider 231 Port Indices (PPIs) and contains a list of tuples for all 232 the ports within the VPN. In addition, for local PE ports of a given 233 VPN the PE retains an identifier known as the VPN-PPI, and this is 234 stored in the PIT with the tuples. 236 When a new CE belonging to one or more VPNs is added to a PE, PIT 237 entries associated to those VPNs need to be configured on the PE. 238 Section 4 of [L1VPN-BM] specifies such procedures: 240 - If no PIT exists for the VPN on the PE, a new PIT is created by the 241 provider and associated with the VPN identifier. 243 - The PIT (new or pre-existing) is updated to include information 244 related to the newly added CE. The VPN-PPI, PPI, and CPI are 245 installed in the PIT. Note that the PPI is well-known by the PE, 246 but the CPI must be discovered either through manual configuration 247 or automatically by mechanisms such as the Link Management Protocol 248 (LMP) [RFC4204]. In addition, a CE to PE control channel needs to 249 be configured. 251 - The updated PIT information needs to be configured in the PITs on 252 remote PE associated with the VPN. For such purpose, manual 253 configuration, or some sort of auto-discovery mechanisms can be 254 used. [L1VPN-BGP-DISC] and [L1VPN-OSPF-DISC] specifies alternative 255 auto-discovery mechanisms. 257 - In addition, remote PIT information associated with the VPN needs 258 to be configured on this PE if the PIT has been newly created. 259 Again, this can be achieved through manual configuration or through 260 auto-discovery, [L1VPN-BGP-DISC] and [L1VPN-OSPF-DISC]. 262 When VPN membership of an existing CE changes, or when a CE is 263 removed from a PE, similar procedures need to be applied to update 264 the local and remote PITs. 266 7.2 PE-PE Segment Control 268 In L1VPN Basic mode, a PE-PE segment of a CE-CE VPN connection is 269 completely under the control of provider network. 271 7.2.1 Path Computation and Establishment 273 A PE-PE segment of a CE-CE VPN connection may be established based on 274 various policies. Those policies can be applied per VPN or per VPN 275 connection. The policy is configured by the provider, possibly based 276 on the contracts with each customer. 278 Examples of PE-PE segment connection establishment polices supported 279 in the L1VPN Basic Mode are as follows. 281 - Policy 1: On-demand establishment, on-demand path computation 282 - Policy 2: On-demand establishment, pre-computed path 283 - Policy 3: Pre-establishment, pre-computed path 285 In each policy, the PE-PE path may be computed by the local PE, or by 286 a path computation entity outside of the local PE (e.g., a Path 287 Computation Element (PCE) [RFC4655], or management systems). 289 In policies 2 and 3, pre-computation of paths (and pre-establishment 290 if applicable) can be done at the network planning phase, or just 291 before signaling (e.g., triggered by an off-line customer request). 292 As the result of pre-computation (and pre-establishment), there could 293 be multiple PE-PE segments for a specific pair of PEs. When a PE 294 receives a Path message from a CE for a VPN connection, a PE needs to 295 determine which PE-PE segment to use. In such cases, the provider may 296 want to control: 298 - Which VPN uses which PE-PE VPN segment. 299 - Which CE-CE VPN connection uses which PE-PE VPN segment. 301 The former requires mapping between the PIT and the PE-PE segment. 302 The latter requires some more sophisticated mapping method, for 303 example: 305 - Mapping between individual PIT entries and PE-PE segments. 306 - Use of a Path Key ID [Conf-Segment] supplied by the provider to the 307 CE, and signaled by the CE as part of the VPN connection request. 309 The L1VPN Basic Mode does not preclude usage of other methods, if 310 applicable. 312 In policy 3, stitching or nesting is necessary in order to map the 313 CE-CE VPN connection to a pre-established PE-PE segment. 315 7.2.2 Resource Management 317 The provider network may operate resource management based on various 318 policies. These policies can be applied per VPN or per VPN 319 connection. The policy is configured by the provider, possibly based 320 on the contracts with each customer. 322 For example, a provider may choose to partition the resources of the 323 provider network for limited use by different VPNs or customers. Such 324 a function might be achieved within the scope of the Basic Mode using 325 resource affinities [RFC3209], but the details of per-VPN resource 326 models (especially in terms of CE-PE routing) are considered as part 327 of the Enhanced Mode. 329 7.2.3 Consideration of CE-PE TE information 331 [L1VPN-OSPF-DISC] and [BGP-TE] allow CE-PE TE link information to be 332 injected into the provider network. This may be helpful for the 333 ingress PE to prevent connection setup failure due to lack of 334 resources or incompatible switching capabilities on remote CE-PE TE 335 links. 337 Furthermore, the L1VPN Basic Mode allows a remote CE to be reached 338 through more than one TE link connected to the same PE (single-homed) 339 or to different PEs (dual-homed). In such cases, to facilitate route 340 choice, the ingress CE needs to initiate signaling by specifying the 341 egress CE's router ID not the egress CPI in the Session Object and 342 ERO (if present) so as to not constrain the choice of route within 343 the provider network. Therefore, the CE's router ID needs to be 344 configured in the PITs. 346 Note that, as described in Section 9.2, consideration of the full 347 feature set enabled by dual-homing (such as resiliency) is out of 348 scope of the L1VPN Basic Mode. 350 7.3 Connectivity Restriction 352 The L1VPN Basic Mode allows restricting connection establishment 353 between CEs belonging to the same VPN for policy reasons (including 354 VPN security). Since the PIT at each PE is associated with a VPN, 355 this function can be easily supported. The restriction can be applied 356 at the ingress PE or at the egress PE according to the applicable 357 restriction policy, but note that applying the policy at the egress 358 may waste signaling effort within the network as VPN connections are 359 pointlessly attempted. 361 In addition, the L1VPN Basic Mode does not restrict use of any 362 advanced admission control based on various policies. 364 8. Customer Control of its VPN 366 8.1 Topology Control 368 In the L1VPN Basic Mode, VPN connection topology is controlled by the 369 customer. That is, a customer can request setup/deletion/modification 370 of VPN connections using signaling mechanisms specified in 371 [L1VPN-BM]. 373 Also note that if there are multiple CE-PE TE links (single-homed or 374 multi-homed), a customer can specify which CE-PE TE link to use to 375 support any VPN connection. Alternatively, a customer may let the 376 provider choose the CE-PE TE link at the egress side, as described in 377 Section 6.2.3. 379 8.2 Note on Routing 381 A CE needs to obtain the remote CPI to which it wishes to request a 382 connection. Since, in the L1VPN Basic Mode, there is no routing 383 information exchange between a CE and a PE, there is no dynamic 384 mechanism supported as part of the Basic Mode L1VPN service, and the 385 knowledge of remote CPIs must be acquired in a VPN-specific way, 386 perhaps through configuration or through a directory server. 388 If a VPN is used by a customer to operate a private IP network, the 389 customer may wish to form routing adjacencies over the CE-CE VPN 390 connections. The L1VPN Basic Mode does not enforce any restriction on 391 such operation by a customer, and the use made of the VPN connections 392 is transparent to the provider network. 394 Furthermore, if a VPN is used by a customer to operate a private 395 Multiprotocol Label Switching (MPLS) or GMPLS network, the customer 396 may wish to treat a VPN connection as a Traffic Engineering (TE) 397 link, and this requires a CE-CE control channel. Note that a 398 Forwarding Adjacency [RFC4206] cannot be formed from the CE-CE VPN 399 connection in the Basic Mode because there is no routing exchange 400 between CE and PE - that is, the customer network and the provider 401 network do not share a routing instance, and the customer control 402 channel cannot be carried within the provider control plane. But 403 where the CE provides suitable adaptation (for example, where the 404 customer network is a packet-switched MPLS or GMPLS network) the 405 customer control channel may be in-band and a routing adjacency may 406 be formed between the CEs using the VPN connection. Otherwise, CE-CE 407 control plane connectivity may form part of the L1VPN service 408 provided to the customer by the provider and may be achieved within 409 the L1VPN connection (for example, through the use of overhead bytes) 410 or through a dedicated control channel connection or tunnel. The 411 options available are discussed further in Section 10.2 of 412 [L1VPN-FW]. 414 9. Scalability, Resiliency 416 9.1 Scalability 418 There are several factors that impact scalability. 420 o Number of VPNs (PITs) configured on each PE 422 With the increase of this number, information to be maintained on 423 the PE increases. Theoretically, the upper limit of the number of 424 VPNs supported in a provider network is governed by how the ID 425 associated with a VPN is allocated, and the number of PITs 426 configured on each PE is limited by this number. However, 427 implementations may impose arbitrary limits on the number of PITs 428 supported by any one PE. 430 o Number of CE-PE TE links for each VPN 432 With the increase of this number, information to be maintained in 433 each PIT increases. When auto-discovery mechanisms are used, the 434 amount of information that an auto-discovery mechanism can support 435 may restrict this number. 437 Note that [L1VPN-OSPF-DISC] floods membership information not only 438 among PEs, but also to all P nodes. This may lead to scalability 439 concerns, compared to [L1VPN-BGP-DISC], which distributes 440 membership information only among PEs. Alternatively, a separate 441 instance of the OSPF protocol can be used just between PEs for 442 distributing membership information. In such a case, Ps do not 443 participate in flooding. 445 Note that in the L1VPN Basic Mode, a PE needs to obtain only CE-PE 446 TE link information, and not customer routing information, which is 447 quite different from the mode of operation of a L3VPN. Therefore, 448 the scalability concern is considered to be less problematic. 450 o Number of VPN connections 452 With the increase of this number, information to be maintained on 453 each PE/P increases. When stitching or nesting is used, states to 454 be maintained at PE increase compared to when connectivity is 455 achieved without stitching or nesting. 457 However, in a layer 1 core, this number is always bounded by the 458 available physical resource because each LSP uses a separate label 459 which is directly bound to a physical, switchable resource 460 (timeslot, lambda, fiber). Thus, it can be safely assumed that the 461 PEs/Ps can comfortably handle the number of LSPs that they may be 462 called on to switch for a L1VPN. 464 9.2 Data Plane Resiliency 466 The L1VPN Basic Mode supports following data plane recovery 467 techniques [L1VPN-BM]. 469 o PE-PE segment recovery 471 - If LSP stitching or LSP hierarchy are used to provision the PE-PE 472 segment, then the PE-PE LSP may be protected using end-to-end 473 recovery within the provider network. 475 - If the CE-CE VPN connection is a single end-to-end LSP (including 476 if session shuffling is used), then the PE-PE LSP segment may be 477 protected using segment protection [SEG-PROT] 479 o CE-PE recovery and PE-PE recovery via link protection 481 - The CE-PEs link may be protected at a lower layer and GMPLS 482 signaling may request the use of link-level protection 484 - If the PE-PE segment is provided as a single TE link (stitching 485 or hierarchy) so that the provider network can perform simple PE- 486 to-PE routing, then the TE link may offer link-level protection 487 through the instantiation of multiple PE-PE LSPs. 489 - The PE-PE segment may be provisioned using only link-protected 490 links within the core network. 492 Note that it is not possible to protect only CE-PE portion or PE-PE 493 portion by link protection because the CE-CE signaling request asks 494 for a certain level of link protection on all links used by the LSP. 495 Also, it is no possible to protect CE-PE portion by link recovery and 496 PE-PE portion by segment recovery at the same time. 498 CE-CE recovery through the use connections from one CE to diverse PEs 499 (i.e., dual-homing) is not supported in the L1VPN Basic Mode. 501 9.3 Control Plane Resiliency 503 The L1VPN Basic Mode allows use of GMPLS control plane resiliency 504 mechanisms. This includes, but not limited to, control channel 505 management in LMP [RFC4204] and fault handling in RSVP-TE [RFC3473] 506 between a CE and a PE as well as within the provider network. 508 10. Security 510 Security considerations are described in [L1VPN-FW], and this section 511 describes how these considerations are addressed in the L1VPN Basic 512 Mode. 514 10.1 Topology Confidentiality 516 As specified in [L1VPN-BM], a provider's topology confidentiality is 517 preserved by the Basic Mode. Since there is no routing exchange 518 between PE and CE, the customer network can gather no information 519 about the provider network. Further, as described in Section 4 of 520 [RFC4208], a PE may filter the information present in a Record Route 521 Object (RRO) that is signaled from the provider network to the 522 customer network. In addition, as described in Section 5 of [RFC4208] 523 and Section 4.4 of [L1VPN-BM], when a Notify message is sent to a CE, 524 it is possible to hide the provider internal address. This is 525 accomplished by a PE updating the Notify Node Address with its own 526 address when the PE receives NOTIFY_REQUEST object from the CE. 528 Even in the case of pre-computed and/or pre-signaled PE-PE segments, 529 provider topology confidentiality may be preserved through the use of 530 path key IDs [Conf-Segment]. 532 The customer's topology confidentiality cannot be completely hidden 533 from the provider network. At the least, the provider network will 534 know about the addresses and locations of CEs. Other customer 535 topology information will remain hidden from the provider in the 536 Basic Mode although care may be needed to protect the customer 537 control channel as described in Section 10.4. 539 The provider network is responsible for maintaining confidentiality 540 of topology information between customers and across VPNs. Since 541 there is no distribution of routing information from PE to CE in the 542 Basic Mode, there is no mechanism by which the provider could 543 accidentally, or deliberately but automatically, distribute this 544 information. 546 10.2 External Control of the Provider Network 548 The provider network is protected from direct control from within 549 customer networks through policy and through filtering of signaling 550 messages. 552 There is a service-based policy installed at each PE that directs how 553 a PE should react to a VPN connection request received from any CE. 554 Each CE is configured at the PE (or through a policy server) for its 555 membership of a VPN, and so CEs cannot dynamically bind to a PE or 556 join a VPN. With this configuration comes the policy that tells the 557 PE how to react to a VPN connection request (for example, whether to 558 allow dynamic establishment of PE-PE connections). Thus, the provider 559 network is protected against spurious VPN connection requests and can 560 charge for all VPN connections according to the service agreement 561 with the customers. Hence the provider network is substantially 562 protected against denial of service attacks. 564 At the same time, if a Path message from a CE contains an Explicit 565 Route Object (ERO) specifying the route within provider network, it 566 is rejected by the PE. Thus, the customer network has no control over 567 the resources in the provider network. 569 10.3 Data Plane Security 571 As described in [L1VPN-FW], at layer 1, data plane information is 572 normally assumed to be secure once connections are established since 573 those connections are dedicated VPNs. That is, it is not possible to 574 communicate unless there is a connection. 576 In order to protect against mis-delivery, each VPN connection is 577 restricted to use only within a single VPN. That is, a VPN connection 578 does not connect CEs that are in different VPNs. In order to realize 579 this, the identity of CEs is assured as part of the service contract. 580 And upon receipt of a request for connection setup, the provider 581 network assures that the connection is requested between CEs 582 belonging to the same VPN. This is achieved as described in Section 583 7.3. 585 Furthermore, customers can apply their own security mechanisms to 586 protect data plane information (CE-CE security). This includes IPsec 587 for IP traffic. 589 10.4 Control Plane Security 591 There are two aspects for control plane security. 593 First, the entity connected over a CE-PE control channel must be 594 identified. This is done when a new CE is added as part of the 595 service contract and the necessary control channel is established. 596 This identification can use authentication procedures available in 597 RSVP-TE [RFC3209]. 599 Second, it must be possible to secure communication over a CE-PE 600 control channel. If a communication channel between the customer and 601 the provider (control channel, management interface) is physically 602 separate per customer, the communication channel could be considered 603 as secure. However, when the communication channel is physically 604 shared among customers, security mechanisms need to be available and 605 should be enforced. RSVP-TE [RFC3209] provides for tamper-protection 606 of signaling message exchanges. IPsec tunnels can further be used for 607 this purpose. 609 Note that even in the case of physically separate communication 610 channels, customers may wish to apply security mechanisms, such as 611 IPsec, to assure higher security, and such mechanisms must be 612 available. 614 Furthermore, the provider network need mechanisms to detect Denial of 615 Service (DoS) attacks and to protect against them reactively and 616 proactively. In the Basic Mode, this relies on management system(s). 618 Lastly, it should be noted that customer control plane traffic 619 carried over the provider network between CEs needs to be protected. 620 Such protection is normally the responsibility of the customer 621 network and can use the security mechanisms of the customer signaling 622 and routing protocols (for example, RSVP-TE [RFC3209]) or may use 623 IPsec tunnels between CEs. CE-CE control plane security may form part 624 of the data plane protection where the control plane traffic is 625 carried in-band in the VPN connection. Where the CE-CE control plane 626 connectivity is provided as an explicit part of the L1VPN service by 627 the provider, control plane security should form part of the service 628 agreement between the provider and customer. 630 11. Management 632 Manageability considerations are described in [L1VPN-FW]. In the 633 L1VPN Basic Mode, we rely on management system(s) for various aspects 634 of the different service functions, such as fault management, 635 configuration and policy management, accounting management, 636 performance management, and security management (as described in 637 Section 10). 639 Details are for further study. 641 12. References 643 12.1 Normative References 645 [L1VPN-FW] Takeda, T., Editor "Framework and Requirements for 646 Layer 1 Virtual Private Networks", draft-ietf- 647 l1vpn-framework, work in progress. 649 [RFC4208] Swallow, G., et al., "Generalize Multiprotocol 650 Label Switching(GMPLS) User-Network Interface: 651 Resource ReserVation Protocol-Traffic Engineering 652 (RSVP-TE) Support for the Overlay Model," RFC4208, 653 October 2005. 655 [L1VPN-BM] Fedyk, D., and Rekhter, Y., Editors, "Layer 1 656 VPN Basic Mode", draft-ietf-l1vpn-basic-mode, 657 work in progress. 659 [L1VPN-BGP-DISC] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., 660 "BGP-based Auto-Discovery for L1VPNs", draft-ietf- 661 l1vpn-bgp-auto-discovery, work in progress. 663 [L1VPN-OSPF-DISC] Bryskin, I., and Berger, L., "OSPF Based L1VPN 664 Auto-Discovery", draft-ietf-l1vpn-ospf-auto- 665 discovery, work in progress. 667 [SEG-PROT] Berger, L., et al., "GMPLS Based Segment 668 Recovery", draft-ietf-ccamp-gmpls-segment- 669 recovery, work in progress. 671 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 672 Srinivasan, V. and G. Swallow, "RSVP-TE: 673 Extensions to RSVP for LSP Tunnels", RFC 3209, 674 December 2001. 676 12.2 Informative References 678 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, 679 "Multiprotocol label switching Architecture", RFC 680 3031, January 2001. 682 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol 683 Label Switching (GMPLS) Signaling Functional 684 Description", RFC 3471, January 2003. 686 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol 687 Label Switching (GMPLS) Signaling - Resource 688 ReserVation Protocol-Traffic Engineering (RSVP-TE) 689 Extensions", RFC 3473, January 2003. 691 [RFC4202] Kompella, K., et al., "Routing Extensions in 692 Support of Generalized Multi-Protocol Label 693 Switching (GMPLS)", RFC 4202, October 2005. 695 [RFC4204] Lang, J., "Link Management Protocol (LMP)", 696 RFC 4204, October 2005. 698 [RFC4026] Anderssion, L., and Madsen, T., "Provider 699 Provisioned Virtual Private Network (VPN) 700 Terminology", RFC 4026, March 2005. 702 [RFC4206] Kompella, K., Rekhter, Y., "Label Switched Paths 703 (LSP) Hierarchy with Generalized Multi-Protocol 704 Label Switching (GMPLS) Traffic Engineering (TE)", 705 RFC 4206, October 2005. 707 [BGP-TE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., 708 "Traffic Engineering Attribute", draft-fedyk-bgp- 709 te-attribute, work in progress. 711 [RFC4655] Farrel, A., Vasseur, JP, Ash, J., "Path 712 Computation Element (PCE) Architecture", RFC 4655, 713 August 2006. 715 [Conf-Segment] Bradford, R., Editor, "Preserving Topology 716 Confidentiality in Inter-Domain Path Computation 717 and Signaling", draft-bradford-pce-path-key, work 718 in progress. 720 13. Acknowledgments 722 Authors would like to thank Ichiro Inoue for valuable comments. In 723 addition, authors would like to thank Marco Carugi and Takumi Ohba 724 for valuable comments in the early development of this document. 726 14. Author's Addresses 727 Deborah Brungard (AT&T) 728 Rm. D1-3C22 - 200 S. Laurel Ave. 729 Middletown, NJ 07748, USA 730 Phone: +1 732 4201573 731 Email: dbrungard@att.com 733 Adrian Farrel 734 Old Dog Consulting 735 Phone: +44 (0) 1978 860944 736 Email: adrian@olddog.co.uk 738 Hamid Ould-Brahim 739 Nortel Networks 740 P O Box 3511 Station C 741 Ottawa, ON K1Y 4H7 Canada 742 Phone: +1 (613) 765 3418 743 Email: hbrahim@nortel.com 745 Dimitri Papadimitriou (Alcatel) 746 Francis Wellensplein 1, 747 B-2018 Antwerpen, Belgium 748 Phone: +32 3 2408491 749 Email: dimitri.papadimitriou@alcatel.be 751 Tomonori Takeda 752 NTT Network Service Systems Laboratories, NTT Corporation 753 3-9-11, Midori-Cho 754 Musashino-Shi, Tokyo 180-8585 Japan 755 Phone: +81 422 59 7434 756 Email: takeda.tomonori@lab.ntt.co.jp 758 15. Intellectual Property Consideration 760 The IETF takes no position regarding the validity or scope of any 761 Intellectual Property Rights or other rights that might be claimed 762 to pertain to the implementation or use of the technology 763 described in this document or the extent to which any license 764 under such rights might or might not be available; nor does it 765 represent that it has made any independent effort to identify any 766 such rights. Information on the procedures with respect to 767 rights in RFC documents can be found in BCP 78 and BCP 79. 769 Copies of IPR disclosures made to the IETF Secretariat and any 770 assurances of licenses to be made available, or the result of an 771 attempt made to obtain a general license or permission for the use 772 of such proprietary rights by implementers or users of this 773 specification can be obtained from the IETF on-line IPR repository 774 at http://www.ietf.org/ipr. 776 The IETF invites any interested party to bring to its attention 777 any copyrights, patents or patent applications, or other 778 proprietary rights that may cover technology that may be required 779 to implement this standard. Please address the information to the 780 IETF at ietf-ipr@ietf.org. 782 16. Full Copyright Statement 784 Copyright (C) The Internet Society (2006). 786 This document is subject to the rights, licenses and restrictions 787 contained in BCP 78, and except as set forth therein, the authors 788 retain all their rights. 790 This document and the information contained herein are provided on an 791 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 792 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 793 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 794 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 795 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.