idnits 2.17.1 draft-ietf-l1vpn-applicability-basic-mode-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 857. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 840. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (April 14, 2008) is 5848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 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 Intended Status: Informational 5 Created: April 14, 2008 6 Expires: October 14, 2008 8 Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) 9 Basic Mode 11 draft-ietf-l1vpn-applicability-basic-mode-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document provides an applicability statement on the use of 39 Generalized Multiprotocol Label Switching (GMPLS) protocols and 40 mechanisms to support Basic Mode Layer 1 Virtual Private Networks 41 (L1VPNs). 43 L1VPNs provide customer services and connectivity at layer 1 over 44 layer 1 networks. The operation of L1VPNs is divided into the Basic 45 Mode and the Enhanced Mode where the Basic Mode of operation does not 46 feature any exchange of routing information between the layer 1 47 network and the customer domain. This document examines how GMPLS 48 protocols can be used to satisfy the requirements of a Basic Mode 49 L1VPN. 51 Table of Contents 53 1. Introduction...................................................2 54 1.1 Terminology...................................................3 55 2. Basic Mode Overview............................................3 56 3. Supported Network Types........................................4 57 3.1 Data Plane....................................................4 58 3.2 Control Plane.................................................4 59 4. Addressing.....................................................5 60 5. Provider Control of its Infrastructure.........................5 61 5.1 Provisioning Model............................................5 62 5.2 PE-PE Segment Control.........................................6 63 5.2.1 Path Computation and Establishment..........................6 64 5.2.2 Resource Management.........................................7 65 5.2.3 Consideration of CE-PE Traffic Engineering Information......7 66 5.3 Connectivity Restriction......................................8 67 6. Customer Control of its L1VPN..................................8 68 6.1 Topology Control..............................................8 69 6.2 Note on Routing...............................................8 70 7. Scalability and Resiliency.....................................9 71 7.1 Scalability...................................................9 72 7.2 Data Plane Resiliency........................................10 73 7.3 Control Plane Resiliency.....................................11 74 8. Security......................................................11 75 8.1 Topology Confidentiality.....................................12 76 8.2 External Control of the Provider Network.....................12 77 8.3 Data Plane Security..........................................13 78 8.4 Control Plane Security.......................................13 79 9. Manageability Considerations..................................14 80 10. IANA Considerations..........................................15 81 11. References...................................................15 82 11.1 Normative References........................................15 83 11.2 Informative References......................................16 84 12. Acknowledgments..............................................17 85 13. Authors' Addresses...........................................17 86 14. Intellectual Property Consideration..........................18 87 15. Full Copyright Statement.....................................18 89 1. Introduction 91 This document provides an applicability statement on the use of 92 Generalized Multiprotocol Label Switching (GMPLS) protocols and 93 mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as 94 specified in [RFC4847]. 96 The operation of L1VPNs is divided into the Basic Mode and the 97 Enhanced Mode. The Basic Mode of operation does not feature any 98 exchange of routing information between the layer 1 network and the 99 customer domain, while the Enhanced Mode of operation features 100 exchange of routing information between the layer 1 network and the 101 customer domain. 103 The main GMPLS protocols and mechanisms applicable to the L1VPN Basic 104 Mode are described in [L1VPN-BM], [L1VPN-BGP-DISC], and 105 [L1VPN-OSPF-DISC], along with several other documents referenced 106 within this document. 108 Note that discussion in this document is focused on areas where GMPLS 109 protocols and mechanisms are relevant. 111 1.1 Terminology 113 The reader is assumed to be familiar with the terminology in 114 [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026] and 115 [RFC4847]. 117 2. Basic Mode Overview 119 As described in [RFC4847], in the Basic Mode service model, there is 120 no routing exchange between the Customer Edge (CE) and the Provider 121 Edge (PE). CE-CE L1VPN connections (i.e., CE-CE VPN connection in 122 RFC4847) are set up by GMPLS signaling between the CE and the PE, and 123 then across the provider network. A L1VPN connection is limited to 124 the connection between CEs belonging to the same L1VPN. 126 Note that in L1VPNs, routing operates within the provider network and 127 may be used by PEs to exchange information specific to the L1VPNs 128 supported by the provider network (e.g., membership information). 130 In the L1VPN Basic Mode, the provider network is completely under the 131 control of the provider. This includes the PE-PE segment of the CE-CE 132 L1VPN connection that is controlled and computed by the provider (PE- 133 PE segment control). On the other hand, the L1VPN itself, constructed 134 from a set of CEs and the L1VPN connections provided by the provider, 135 is under the control of each customer. This includes that a customer 136 can request between which CEs a connection is to be established 137 (topology control). Note that a customer may outsource the management 138 of its L1VPN to a third party, including to the provider itself. 139 There is a confidentiality requirement between the provider and each 140 customer. 142 [L1VPN-BM], which extends [RFC4208], specifies GMPLS signaling to 143 establish CE-CE L1VPN connections. 145 [L1VPN-BGP-DISC] and [L1VPN-OSPF-DISC] specify alternative mechanisms 146 to exchange L1VPN membership information between PEs, based on BGP 147 and OSPF respectively. 149 3. Supported Network Types 151 3.1 Data Plane 153 The provider network can be constructed from any type of layer 1 154 switches, such as Time Division Multiplexing (TDM) switches, Optical 155 Cross-Connects (OXCs), or Photonic Cross-Connects (PXCs). 156 Furthermore, a PE may be an Ethernet Private Line (EPL) type of 157 device, that maps Ethernet frames onto layer 1 connections (by means 158 of Ethernet over TDM etc.). The provider network may be constructed 159 from switches providing a single switching granularity (e.g., only 160 VC3 switches), or from switches providing multiple switching 161 granularities (e.g., from VC3/VC4 switches, or from VC3 switches and 162 OXCs). The provider network may provide a single type of L1VPN 163 connection (e.g., VC3 connections only), or multiple types of 164 connection (e.g., VC3/VC4 connections, or VC3 connections and 165 wavelength connections). 167 A CE does not have to have the capability to switch at layer 1, but 168 it must be capable of receiving a layer 1 signal and either switching 169 it or terminating it with adaptation. 171 As described in [RFC4847] and [L1VPN-BM], a CE and a PE are connected 172 by one or more links. A CE may also be connected to more than one PE, 173 and a PE may have more than one CE connected to it. 175 A CE may belong to a single L1VPN, or to multiple L1VPNs, and a PE 176 may support one or more L1VPNs through a single CE or through 177 multiple CEs. 179 3.2 Control Plane 181 The provider network is controlled by GMPLS. L1VPN Basic Mode 182 provider networks are limited to a single AS within the scope of this 183 document. Multi-AS Basic Mode L1VPNs are for future study. 185 As described in [RFC4847] and [L1VPN-BM], a CE and a PE need to be 186 connected by at least one control channel. It is necessary to 187 disambiguate control plane messages exchanged between a CE and a PE 188 if the CE-PE relationship is applicable to more than one L1VPN. This 189 makes it possible to determine to which L1VPN such control plane 190 messages apply. Such disambiguation can be achieved by allocating a 191 separate control channel to each L1VPN (either using a separate 192 physical channel, a separate logical channel such as an IP tunnel, or 193 using separate addressing). 195 GMPLS allows any type of control channel to be used, as long as there 196 is IP level reachability. In the L1VPN context, instantiation of a 197 control channel between a CE and a PE may differ depending on 198 security requirements, etc. This is discussed in Section 8. 200 4. Addressing 202 As described in [L1VPN-BM], the L1VPN Basic Mode allows that customer 203 addressing realms overlap with each other, and also overlap with the 204 service provider addressing realm. That is, a customer network may 205 re-use addresses used by the provider network, and may re-use 206 addresses used in another customer network supported by the same 207 provider network. This is the same as in any other VPN model. 209 In addition, the L1VPN Basic Mode allows CE-PE control channel 210 addressing realms to overlap. That is, a CE-PE control channel 211 address (CE's address of this control channel and PE's address of 212 this control channel) is unique within the L1VPN they belong to, but 213 not necessarily unique across multiple L1VPNs. 215 Furthermore, once a L1VPN connection has been established, the L1VPN 216 Basic Mode does not enforce any restriction on address assignment for 217 this L1VPN connection (treated as a link) for customer network 218 operation (e.g., IP network, MPLS network). 220 5. Provider Control of its Infrastructure 222 5.1 Provisioning Model 224 As described in [L1VPN-BM], for each L1VPN that has at least one 225 customer-facing port on a given PE, the PE maintains a Port 226 Information Table (PIT) associated with that L1VPN. A PIT provides a 227 cross-reference between Customer Port Indices (CPIs) and Provider 228 Port Indices (PPIs) and contains a list of tuples for all 229 the ports within the L1VPN. In addition, for local PE ports of a 230 given L1VPN the PE retains an identifier known as the VPN-PPI, and 231 this is stored in the PIT with the tuples. 233 When a new CE belonging to one or more L1VPNs is added to a PE, PIT 234 entries associated to those L1VPNs need to be configured on the PE. 235 Section 4 of [L1VPN-BM] specifies such procedures: 237 - If no PIT exists for the L1VPN on the PE, a new PIT is created by 238 the provider and associated with the VPN identifier. 240 - The PIT (new or pre-existing) is updated to include information 241 related to the newly added CE. The VPN-PPI, PPI, and CPI are 242 installed in the PIT. Note that the PPI is well-known by the PE, 243 but the CPI must be discovered either through manual configuration 244 or automatically by mechanisms such as the Link Management Protocol 245 (LMP) [RFC4204]. In addition, a CE to PE control channel needs to 246 be configured. 248 - The updated PIT information needs to be configured in the PITs on 249 remote PE associated with the L1VPN. For such purposes, manual 250 configuration or some sort of auto-discovery mechanisms can be 251 used. [L1VPN-BGP-DISC] and [L1VPN-OSPF-DISC] specify alternative 252 auto-discovery mechanisms. 254 - In addition, remote PIT information associated with the L1VPN needs 255 to be configured on this PE if the PIT has been newly created. 256 Again, this can be achieved through manual configuration or through 257 auto-discovery, [L1VPN-BGP-DISC] and [L1VPN-OSPF-DISC]. 259 When L1VPN membership of an existing CE changes, or when a CE is 260 removed from a PE, similar procedures need to be applied to update 261 the local and remote PITs. 263 5.2 PE-PE Segment Control 265 In the L1VPN Basic Mode, a PE-PE segment of a CE-CE L1VPN connection 266 is completely under the control of provider network. 268 5.2.1 Path Computation and Establishment 270 A PE-PE segment of a CE-CE L1VPN connection may be established based 271 on various policies. Those policies can be applied per L1VPN or per 272 L1VPN connection. The policy is configured by the provider, possibly 273 based on the contracts with each customer. 275 Examples of PE-PE segment connection establishment polices supported 276 in the L1VPN Basic Mode are as follows. 278 - Policy 1: On-demand establishment, on-demand path computation 279 - Policy 2: On-demand establishment, pre-computed path 280 - Policy 3: Pre-establishment, pre-computed path 282 In each policy, the PE-PE path may be computed by the local PE, or by 283 a path computation entity outside of the local PE (e.g., a Path 284 Computation Element (PCE) [RFC4655], or a management system). 286 In policies 2 and 3, pre-computation of paths (and pre-establishment 287 if applicable) can be done at the network planning phase, or just 288 before signaling (e.g., triggered by an off-line customer request). 289 As the result of pre-computation (and pre-establishment), there could 290 be multiple PE-PE segments for a specific pair of PEs. When a PE 291 receives a Path message from a CE for a L1VPN connection, a PE needs 292 to determine which PE-PE segment to use. In such cases, the provider 293 may want to control: 295 - Which L1VPN uses which PE-PE L1VPN segment. 296 - Which CE-CE L1VPN connection uses which PE-PE L1VPN segment. 298 The former requires mapping between the PIT and the PE-PE segment. 299 The latter requires some more sophisticated mapping method, for 300 example: 302 - Mapping between individual PIT entries and PE-PE segments. 303 - Use of a Path Key ID [CONF-SEG] supplied by the provider to the CE, 304 and signaled by the CE as part of the L1VPN connection request. 306 The L1VPN Basic Mode does not preclude usage of other methods, if 307 applicable. 309 In policy 3, stitching or nesting is necessary in order to map the 310 CE-CE L1VPN connection to a pre-established PE-PE segment. 312 5.2.2 Resource Management 314 The provider network may operate resource management based on various 315 policies. These policies can be applied per L1VPN or per L1VPN 316 connection. The policy is configured by the provider, possibly based 317 on the contracts with each customer. 319 For example, a provider may choose to partition the resources of the 320 provider network for limited use by different L1VPNs or customers. 321 Such a function might be achieved within the scope of the Basic Mode 322 using resource affinities [RFC3209], but the details of per-L1VPN 323 resource models (especially in terms of CE-PE routing) are considered 324 as part of the Enhanced Mode. 326 5.2.3 Consideration of CE-PE Traffic Engineering Information 328 [L1VPN-OSPF-DISC] and [BGP-TE] allow CE-PE Traffic Engineering (TE) 329 link information to be injected into the provider network, and in 330 particular to be exchanged between PEs. This may be helpful for the 331 ingress PE to prevent connection setup failure due to lack of 332 resources or incompatible switching capabilities on remote CE-PE TE 333 links. 335 Furthermore, the L1VPN Basic Mode allows a remote CE to be reached 336 through more than one TE link connected to the same PE (single-homed) 337 or to different PEs (dual-homed). In such cases, to facilitate route 338 choice, the ingress CE needs to initiate signaling by specifying the 339 egress CE's router ID not the egress CPI in the Session Object and 340 the Explicit Route Object (ERO) if present so as to not constrain the 341 choice of route within the provider network. Therefore, the CE's 342 router ID needs to be configured in the PITs. 344 Note that, as described in Section 7.2, consideration of the full 345 feature set enabled by dual-homing (such as resiliency) is out of 346 scope of the L1VPN Basic Mode. 348 5.3 Connectivity Restriction 350 The L1VPN Basic Mode allows restricting connection establishment 351 between CEs belonging to the same L1VPN for policy reasons (including 352 L1VPN security). Since the PIT at each PE is associated with a L1VPN, 353 this function can be easily supported. The restriction can be applied 354 at the ingress PE or at the egress PE according to the applicable 355 restriction policy, but note that applying the policy at the egress 356 may waste signaling effort within the network as L1VPN connections 357 are pointlessly attempted. 359 In addition, the L1VPN Basic Mode does not restrict use of any 360 advanced admission control based on various policies. 362 6. Customer Control of its L1VPN 364 6.1 Topology Control 366 In the L1VPN Basic Mode, L1VPN connection topology is controlled by 367 the customer. That is, a customer can request 368 setup/deletion/modification of L1VPN connections using signaling 369 mechanisms specified in [L1VPN-BM]. 371 Also note that if there are multiple CE-PE TE links (single-homed or 372 multi-homed), a customer can specify which CE-PE TE link to use to 373 support any L1VPN connection. Alternatively, a customer may let the 374 provider choose the CE-PE TE link at the egress side, as described in 375 Section 5.2.3. 377 6.2 Note on Routing 379 A CE needs to obtain the remote CPI to which it wishes to request a 380 connection. Since, in the L1VPN Basic Mode, there is no routing 381 information exchange between a CE and a PE, there is no dynamic 382 mechanism supported as part of the Basic Mode L1VPN service, and the 383 knowledge of remote CPIs must be acquired in a L1VPN-specific way, 384 perhaps through configuration or through a directory server. 386 If a L1VPN is used by a customer to operate a private IP network, the 387 customer may wish to form routing adjacencies over the CE-CE L1VPN 388 connections. The L1VPN Basic Mode does not enforce any restriction on 389 such operation by a customer, and the use made of the L1VPN 390 connections is transparent to the provider network. 392 Furthermore, if a L1VPN is used by a customer to operate a private 393 Multiprotocol Label Switching (MPLS) or GMPLS network, the customer 394 may wish to treat a L1VPN connection as a TE link, and this requires 395 a CE-CE control channel. Note that a Forwarding Adjacency [RFC4206] 396 cannot be formed from the CE-CE L1VPN connection in the Basic Mode 397 because there is no routing exchange between CE and PE - that is, the 398 customer network and the provider network do not share a routing 399 instance, and the customer control channel cannot be carried within 400 the provider control plane. But where the CE provides suitable 401 adaptation (for example, where the customer network is a packet- 402 switched MPLS or GMPLS network) the customer control channel may be 403 in-band and a routing adjacency may be formed between the CEs using 404 the L1VPN connection. Otherwise, CE-CE control plane connectivity may 405 form part of the L1VPN service provided to the customer by the 406 provider and may be achieved within the L1VPN connection (for 407 example, through the use of overhead bytes) or through a dedicated 408 control channel connection or tunnel. The options available are 409 discussed further in Section 10.2 of [RFC4847]. 411 7. Scalability and Resiliency 413 7.1 Scalability 415 There are several factors that impact scalability. 417 o Number of L1VPNs (PITs) configured on each PE 419 With the increase of this number, information to be maintained on 420 the PE increases. Theoretically, the upper limit of the number of 421 L1VPNs supported in a provider network is governed by how the ID 422 associated with a L1VPN is allocated, and the number of PITs 423 configured on each PE is limited by this number. However, 424 implementations may impose arbitrary limits on the number of PITs 425 supported by any one PE. 427 o Number of CE-PE TE links for each L1VPN 429 With the increase of this number, information to be maintained in 430 each PIT increases. When auto-discovery mechanisms are used, the 431 amount of information that an auto-discovery mechanism can support 432 may restrict this number. 434 Note that [L1VPN-OSPF-DISC] floods membership information not only 435 among PEs, but also to all P nodes. This may lead to scalability 436 concerns, compared to [L1VPN-BGP-DISC], which distributes 437 membership information only among PEs. Alternatively, a separate 438 instance of the OSPF protocol can be used just between PEs for 439 distributing membership information. In such a case, Ps do not 440 participate in flooding. 442 Note that in the L1VPN Basic Mode, a PE needs to obtain only CE-PE 443 TE link information, and not customer routing information, which is 444 quite different from the mode of operation of a L3VPN. Therefore, 445 the scalability concern is considered to be less problematic. 447 o Number of L1VPN connections 449 With the increase of this number, information to be maintained on 450 each PE/P increases. When stitching or nesting is used, state to 451 be maintained at each PE increases compared to when connectivity is 452 achieved without stitching or nesting. 454 However, in a layer 1 core, this number is always bounded by the 455 available physical resource because each LSP uses a separate label 456 which is directly bound to a physical, switchable resource 457 (timeslot, lambda, fiber). Thus, it can be safely assumed that the 458 PEs/Ps can comfortably handle the number of LSPs that they may be 459 called on to switch for a L1VPN. 461 7.2 Data Plane Resiliency 463 The L1VPN Basic Mode supports following data plane recovery 464 techniques [L1VPN-BM]. 466 o PE-PE segment recovery 468 The CE indicates to protect the PE-PE segment by including 469 Protection Object specified in [RFC4873] in the Path message and 470 setting Segment Recovery Flags. The CE may also indicate the branch 471 and merge nodes by including Secondary Explicit Route Object. 473 Depending on the signaling mechanisms used within the provider 474 network, details on how to protect the PE-PE segment may differ as 475 follows. 477 - If LSP stitching or LSP hierarchy are used to provision the PE-PE 478 segment, then the PE-PE LSP may be protected using end-to-end 479 recovery within the provider network. 481 - If the CE-CE L1VPN connection is a single end-to-end LSP 482 (including if session shuffling is used), then the PE-PE LSP 483 segment may be protected using segment protection [RFC4873] 485 o CE-PE recovery and PE-PE recovery via link protection 487 The CE indicates to protect ingress and egress CE-PE links as well 488 as links within the provider network by including Protection Object 489 specified in [RFC3473] and setting Link Flags in the Path message. 491 - The ingress and egress CE-PE link may be protected at a lower 492 layer 494 Depending on the signaling mechanisms used within the provider 495 network, details on how to protect links within the provider 496 network may differ as follows. 498 - If the PE-PE segment is provided as a single TE link (stitching 499 or hierarchy) so that the provider network can perform simple PE- 500 to-PE routing, then the TE link may offer link-level protection 501 through the instantiation of multiple PE-PE LSPs. 503 - The PE-PE segment may be provisioned using only link-protected 504 links within the core network. 506 Note that it is not possible to protect only the CE-PE portion or the 507 PE-PE portion by link protection because the CE-CE signaling request 508 asks for a certain level of link protection on all links used by the 509 LSP. Also, it is not possible to protect the CE-PE portion by link 510 recovery and the PE-PE portion by segment recovery at the same time. 512 CE-CE recovery through the use of connections from one CE to diverse 513 PEs (i.e., dual-homing) is not supported in the L1VPN Basic Mode. 515 7.3 Control Plane Resiliency 517 The L1VPN Basic Mode allows use of GMPLS control plane resiliency 518 mechanisms. This includes, but not limited to, control channel 519 management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473] 520 and [RFC5063]) between a CE and a PE as well as within the provider 521 network. 523 8. Security 525 Security considerations are described in [RFC4847], and this section 526 describes how these considerations are addressed in the L1VPN Basic 527 Mode. 529 Additional discussion of GMPLS security an be found in [GMPLS-SEC]. 531 8.1 Topology Confidentiality 533 As specified in [L1VPN-BM], a provider's topology confidentiality is 534 preserved by the Basic Mode. Since there is no routing exchange 535 between PE and CE, the customer network can gather no information 536 about the provider network. Further, as described in Section 4 of 537 [RFC4208], a PE may filter the information present in a Record Route 538 Object (RRO) that is signaled from the provider network to the 539 customer network. In addition, as described in Section 5 of [RFC4208] 540 and Section 4.4 of [L1VPN-BM], when a Notify message is sent to a CE, 541 it is possible to hide the provider internal address. This is 542 accomplished by a PE updating the Notify Node Address with its own 543 address when the PE receives NOTIFY_REQUEST object from the CE. 545 Even in the case of pre-computed and/or pre-signaled PE-PE segments, 546 provider topology confidentiality may be preserved through the use of 547 path key IDs [CONF-SEG]. 549 The customer's topology confidentiality cannot be completely hidden 550 from the provider network. At the least, the provider network will 551 know about the addresses and locations of CEs. Other customer 552 topology information will remain hidden from the provider in the 553 Basic Mode although care may be needed to protect the customer 554 control channel as described in Section 8.4. 556 The provider network is responsible for maintaining confidentiality 557 of topology information between customers and across L1VPNs. Since 558 there is no distribution of routing information from PE to CE in the 559 Basic Mode, there is no mechanism by which the provider could 560 accidentally, or deliberately but automatically, distribute this 561 information. 563 8.2 External Control of the Provider Network 565 The provider network is protected from direct control from within 566 customer networks through policy and through filtering of signaling 567 messages. 569 There is a service-based policy installed at each PE that directs how 570 a PE should react to a L1VPN connection request received from any CE. 571 Each CE is configured at the PE (or through a policy server) for its 572 membership of a L1VPN, and so CEs cannot dynamically bind to a PE or 573 join a L1VPN. With this configuration comes the policy that tells the 574 PE how to react to a L1VPN connection request (for example, whether 575 to allow dynamic establishment of PE-PE connections). Thus, the 576 provider network is protected against spurious L1VPN connection 577 requests and can charge for all L1VPN connections according to the 578 service agreement with the customers. Hence the provider network is 579 substantially protected against denial of service attacks. 581 At the same time, if a Path message from a CE contains an Explicit 582 Route Object (ERO) specifying the route within provider network, it 583 is rejected by the PE. Thus, the customer network has no control over 584 the resources in the provider network. 586 8.3 Data Plane Security 588 As described in [RFC4847], at layer 1, data plane information is 589 normally assumed to be secure once connections are established since 590 the optical signals themselves are normally considered to be hard to 591 intercept or modify, and it is considered difficult to insert data 592 into an optical stream. This, the very use of an optical signal may 593 be considered to provide confidentiality and integrity to the payload 594 data. Furthemore, as indicated in [RFC4847], layer 1 VPN connections 595 are each dedicated to a specific L1VPN which provides an additional 596 element of security for the payload data. 598 Misconnection remains a security vulnerabilty for user data. If a 599 L1VPN connection were to be misconnected to the wrong destination, 600 user data would be delivered to the wrong consumers. In order to 601 protect against mis-delivery, each L1VPN connection is restricted to 602 use only within a single L1VPN. That is, a L1VPN connection does not 603 connect CEs that are in different L1VPNs. In order to realize this, 604 the identity of CEs is assured as part of the service contract. And 605 upon receipt of a request for connection setup, the provider network 606 assures that the connection is requested between CEs belonging to the 607 same L1VPN. This is achieved as described in Section 5.3. 609 Furthermore, users with greater sensitivity to the security of their 610 payload data should apply appropriate security measures within their 611 own network layer. For example, a customer exchanging IP traffic over 612 a L1VPN connection may choose to use IPsec to secure that traffic 613 (i.e., to operate IPsec on the CE-CE exchange of IP traffic). 615 8.4 Control Plane Security 617 There are two aspects for control plane security. 619 First, the entity connected over a CE-PE control channel must be 620 identified. This is done when a new CE is added as part of the 621 service contract and the necessary control channel is established. 622 This identification can use authentication procedures available in 623 RSVP-TE [RFC3209]. That is, control plane entities are identified 624 within the core protocols used for signaling, but are not 625 authenticated unless the authentication procedures of [RFC3209] are 626 used. 628 Second, it must be possible to secure communication over a CE-PE 629 control channel. If a communication channel between the customer and 630 the provider (control channel, management interface) is physically 631 separate per customer, the communication channel could be considered 632 as secure. However, when the communication channel is physically 633 shared among customers, security mechanisms need to be available and 634 should be enforced. RSVP-TE [RFC3209] provides for tamper-protection 635 of signaling message exchanges through the optional Integrity object. 636 IPsec tunnels can be used to carry the control plane messages to 637 further ensure the integrity of the signaling messages. 639 Note that even in the case of physically separate communication 640 channels, customers may wish to apply security mechanisms, such as 641 IPsec, to assure higher security, and such mechanisms must be 642 available. 644 Furthermore, the provider network needs mechanisms to detect Denial 645 of Service (DoS) attacks and to protect against them reactively and 646 proactively. In the Basic Mode, this relies on management systems. 647 For example, management systems collect and analyze statistics on 648 signaling requests from CEs, and protect against malicious behaviors 649 where necessary. 651 Lastly, it should be noted that customer control plane traffic 652 carried over the provider network between CEs needs to be protected. 653 Such protection is normally the responsibility of the customer 654 network and can use the security mechanisms of the customer signaling 655 and routing protocols (for example, RSVP-TE [RFC3209]) or may use 656 IPsec tunnels between CEs. CE-CE control plane security may form part 657 of the data plane protection where the control plane traffic is 658 carried in-band in the L1VPN connection. Where the CE-CE control 659 plane connectivity is provided as an explicit part of the L1VPN 660 service by the provider, control plane security should form part of 661 the service agreement between the provider and customer. 663 9. Manageability Considerations 665 Manageability considerations are described in [RFC4847]. In the L1VPN 666 Basic Mode, we rely on management systems for various aspects of the 667 different service functions, such as fault management, configuration 668 and policy management, accounting management, performance management, 669 and security management (as described in Section 8). 671 In order to support various management functionalities, MIB modules 672 need to be supported. In particular, the GMPLS TE MIB (GMPLS-TE-STD- 673 MIB) [RFC4802] can be used for GMPLS-based traffic engineering 674 configuration and management, while the TE Link MIB (TE-LINK-STD-MIB) 675 [RFC4220] can be used for TE links configuration and management. 677 10. IANA Considerations 679 This informational document makes no requests for IANA action. 680 [RFC Editor - please remove this entire section before publication] 682 11. References 684 11.1 Normative References 686 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, 687 "Multiprotocol label switching Architecture", RFC 688 3031, January 2001. 690 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 691 Srinivasan, V. and G. Swallow, "RSVP-TE: 692 Extensions to RSVP for LSP Tunnels", RFC 3209, 693 December 2001. 695 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol 696 Label Switching (GMPLS) Signaling Functional 697 Description", RFC 3471, January 2003. 699 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol 700 Label Switching (GMPLS) Signaling - Resource 701 ReserVation Protocol-Traffic Engineering (RSVP-TE) 702 Extensions", RFC 3473, January 2003. 704 [RFC4026] Anderssion, L., and Madsen, T., "Provider 705 Provisioned Virtual Private Network (VPN) 706 Terminology", RFC 4026, March 2005. 708 [RFC4202] Kompella, K., et al., "Routing Extensions in 709 Support of Generalized Multi-Protocol Label 710 Switching (GMPLS)", RFC 4202, October 2005. 712 [RFC4208] Swallow, G., et al., "Generalize Multiprotocol 713 Label Switching(GMPLS) User-Network Interface: 714 Resource ReserVation Protocol-Traffic Engineering 715 (RSVP-TE) Support for the Overlay Model," RFC4208, 716 October 2005. 718 [RFC4847] Takeda, T., Editor "Framework and Requirements for 719 Layer 1 Virtual Private Networks", RFC 4847, April 720 2007. 722 [RFC4873] Berger, L., et al., "GMPLS Based Segment 723 Recovery", RFC 4873, May 2007. 725 [L1VPN-BM] Fedyk, D., and Rekhter, Y., Editors, "Layer 1 726 VPN Basic Mode", draft-ietf-l1vpn-basic-mode, 727 work in progress. 729 [L1VPN-BGP-DISC] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., 730 "BGP-based Auto-Discovery for L1VPNs", draft-ietf- 731 l1vpn-bgp-auto-discovery, work in progress. 733 [L1VPN-OSPF-DISC] Bryskin, I., and Berger, L., "OSPF Based L1VPN 734 Auto-Discovery", draft-ietf-l1vpn-ospf-auto- 735 discovery, work in progress. 737 11.2 Informative References 739 [RFC4204] Lang, J., "Link Management Protocol (LMP)", 740 RFC 4204, October 2005. 742 [RFC4206] Kompella, K., Rekhter, Y., "Label Switched Paths 743 (LSP) Hierarchy with Generalized Multi-Protocol 744 Label Switching (GMPLS) Traffic Engineering (TE)", 745 RFC 4206, October 2005. 747 [RFC4220] Dubuc, M., Nadeau, T., Lang, J., "Traffic 748 Engineering Link Management Information Base", RFC 749 4220, November 2005. 751 [RFC4655] Farrel, A., Vasseur, JP, Ash, J., "Path 752 Computation Element (PCE) Architecture", RFC 4655, 753 August 2006. 755 [RFC4802] Nadeau, T., Farrel, A., Editors, "Generalized 756 Multiprotocol Label Switching (GMPLS) Traffic 757 Engineering Management Information Base", RFC 758 4802, February 2007. 760 [RFC5063] Satyanarayana, A., and Rahman, R., "Extensions to 761 GMPLS RSVP Graceful Restart", RFC 5063, October 762 2007. 764 [BGP-TE] Ould-Brahim, H., Fedyk, D., and Rekhter, Y., 765 "Traffic Engineering Attribute", draft-ietf- 766 softwire-bgp-te-attribute, work in progress. 768 [CONF-SEG] Bradford, R., Editor, "Preserving Topology 769 Confidentiality in Inter-Domain Path Computation 770 and Signaling", draft-ietf-pce-path-key, work in 771 progress. 773 [GMPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS 774 Networks", draft-ietf-mpls-mpls-and-gmpls- 775 security-framework, work in progress. 777 12. Acknowledgments 779 Authors would like to thank Ichiro Inoue for valuable comments. In 780 addition, authors would like to thank Marco Carugi and Takumi Ohba 781 for valuable comments in the early development of this document. 783 Thanks to Tim Polk and Mark Townsley for comments during IESG review. 785 13. Authors' Addresses 787 Deborah Brungard (AT&T) 788 Rm. D1-3C22 - 200 S. Laurel Ave. 789 Middletown, NJ 07748, USA 790 Phone: +1 732 4201573 791 Email: dbrungard@att.com 793 Adrian Farrel 794 Old Dog Consulting 795 Phone: +44 (0) 1978 860944 796 Email: adrian@olddog.co.uk 798 Hamid Ould-Brahim 799 Nortel Networks 800 P O Box 3511 Station C 801 Ottawa, ON K1Y 4H7 Canada 802 Phone: +1 (613) 765 3418 803 Email: hbrahim@nortel.com 805 Dimitri Papadimitriou (Alcatel-Lucent) 806 Francis Wellensplein 1, 807 B-2018 Antwerpen, Belgium 808 Phone: +32 3 2408491 809 Email: dimitri.papadimitriou@alcatel-lucent.be 811 Tomonori Takeda 812 NTT Network Service Systems Laboratories, NTT Corporation 813 3-9-11, Midori-Cho 814 Musashino-Shi, Tokyo 180-8585 Japan 815 Phone: +81 422 59 7434 816 Email: takeda.tomonori@lab.ntt.co.jp 818 14. Intellectual Property Consideration 820 The IETF takes no position regarding the validity or scope of any 821 Intellectual Property Rights or other rights that might be claimed 822 to pertain to the implementation or use of the technology 823 described in this document or the extent to which any license 824 under such rights might or might not be available; nor does it 825 represent that it has made any independent effort to identify any 826 such rights. Information on the procedures with respect to 827 rights in RFC documents can be found in BCP 78 and BCP 79. 829 Copies of IPR disclosures made to the IETF Secretariat and any 830 assurances of licenses to be made available, or the result of an 831 attempt made to obtain a general license or permission for the use 832 of such proprietary rights by implementers or users of this 833 specification can be obtained from the IETF on-line IPR repository 834 at http://www.ietf.org/ipr. 836 The IETF invites any interested party to bring to its attention 837 any copyrights, patents or patent applications, or other 838 proprietary rights that may cover technology that may be required 839 to implement this standard. Please address the information to the 840 IETF at ietf-ipr@ietf.org. 842 15. Full Copyright Statement 844 Copyright (C) The IETF Trust (2008). 846 This document is subject to the rights, licenses and 847 restrictions contained in BCP 78, and except as set 848 forth therein, the authors retain all their rights. 850 This document and the information contained herein are provided 851 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 852 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 853 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 854 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 855 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 856 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 857 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.