Network Working Group T. Takeda, Ed. Request for Comments: 5253 NTT Category: Informational July 2008 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThis document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs). L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN.
1. Introduction ....................................................3 1.1. Terminology ................................................3 2. Basic Mode Overview .............................................3 3. Supported Network Types .........................................4 3.1. Data Plane .................................................4 3.2. Control Plane ..............................................4 4. Addressing ......................................................5 5. Provider Control of Its Infrastructure ..........................5 5.1. Provisioning Model .........................................5 5.2. PE-to-PE Segment Control ...................................6 5.2.1. Path Computation and Establishment ..................6 5.2.2. Resource Management .................................7 5.2.3. Consideration of CE-to-PE Traffic Engineering Information .........................................8 5.3. Connectivity Restriction ...................................8 6. Customer Control of Its L1VPN ...................................8 6.1. Topology Control ...........................................8 6.2. Note on Routing ............................................9 7. Scalability and Resiliency .....................................10 7.1. Scalability ...............................................10 7.2. Data Plane Resiliency .....................................11 7.3. Control Plane Resiliency ..................................12 8. Security Considerations ........................................12 8.1. Topology Confidentiality ..................................12 8.2. External Control of the Provider Network ..................13 8.3. Data Plane Security .......................................13 8.4. Control Plane Security ....................................14 9. Manageability Considerations ...................................15 10. References ....................................................15 10.1. Normative References .....................................15 10.2. Informative References ...................................16 11. Acknowledgments ...............................................17
RFC4847]. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode. The Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain, while the Enhanced Mode of operation features exchange of routing information between the Layer 1 network and the customer domain. The main GMPLS protocols and mechanisms applicable to the L1VPN Basic Mode are described in [RFC5251], [RFC5195], and [RFC5252], along with several other documents referenced within this document. Note that discussion in this document is focused on areas where GMPLS protocols and mechanisms are relevant. RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026], and [RFC4847]. RFC4847], in the Basic Mode service model, there is no routing exchange between the Customer Edge (CE) and the Provider Edge (PE). CE-to-CE L1VPN connections (i.e., the CE-to-CE VPN connection in RFC 4847) are set up by GMPLS signaling between the CE and the PE, and then across the provider network. A L1VPN connection is limited to the connection between CEs belonging to the same L1VPN. Note that in L1VPNs, routing operates within the provider network. Also note that routing may be used by PEs to exchange information specific to the L1VPNs supported by the provider network (e.g., membership information). In the L1VPN Basic Mode, the provider network is completely under the control of the provider. This includes the PE-to-PE segment of the CE-to-CE L1VPN connection that is controlled and computed by the provider (PE-to-PE segment control). On the other hand, the L1VPN itself, constructed from a set of CEs and the L1VPN connections provided by the provider, is under the control of each customer. This control includes that a customer can request between which CEs a
connection is to be established (topology control). Note that a customer may outsource the management of its L1VPN to a third party, including to the provider itself. There is a confidentiality requirement between the provider and each customer. [RFC5251], which extends [RFC4208], specifies GMPLS signaling to establish CE-to-CE L1VPN connections. [RFC5195] and [RFC5252] specify alternative mechanisms to exchange L1VPN membership information between PEs, based on BGP and OSPF, respectively. RFC4847] and [RFC5251], a CE and a PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it. A CE may belong to a single L1VPN, or to multiple L1VPNs, and a PE may support one or more L1VPNs through a single CE or through multiple CEs.
As described in [RFC4847] and [RFC5251], a CE and a PE need to be connected by at least one control channel. It is necessary to disambiguate control plane messages exchanged between a CE and a PE if the CE-to-PE relationship is applicable to more than one L1VPN. This makes it possible to determine to which L1VPN such control plane messages apply. Such disambiguation can be achieved by allocating a separate control channel to each L1VPN (either using a separate physical channel, a separate logical channel such as an IP tunnel, or using separate addressing). GMPLS allows any type of control channel to be used, as long as there is IP level reachability. In the L1VPN context, instantiation of a control channel between a CE and a PE may differ depending on security requirements, etc. This is discussed in Section 8. RFC5251], the L1VPN Basic Mode allows that customer addressing realms overlap with each other, and also overlap with the service provider addressing realm. That is, a customer network may reuse addresses used by the provider network, and may reuse addresses used in another customer network supported by the same provider network. This is the same as in any other VPN model. In addition, the L1VPN Basic Mode allows CE-to-PE control channel addressing realms to overlap. That is, a CE-to-PE control channel address (CE's address of this control channel and PE's address of this control channel) is unique within the L1VPN that the CE-to-PE control channel belongs to, but not necessarily unique across multiple L1VPNs. Furthermore, once a L1VPN connection has been established, the L1VPN Basic Mode does not enforce any restriction on address assignment for this L1VPN connection (treated as a link) for customer network operation (e.g., IP network, MPLS network). RFC5251], for each L1VPN that has at least one customer-facing port on a given PE, the PE maintains a Port Information Table (PIT) associated with that L1VPN. A PIT provides a cross-reference between Customer Port Indices (CPIs) and Provider Port Indices (PPIs) and contains a list of <CPI, PPI> tuples for all the ports within the L1VPN. In addition, for local PE ports of a given L1VPN, the PE retains an identifier known as the VPN-PPI, and this is stored in the PIT with the <CPI, PPI> tuples.
When a new CE belonging to one or more L1VPNs is added to a PE, PIT entries associated to those L1VPNs need to be configured on the PE. Section 4 of [RFC5251] specifies such procedures: - If no PIT exists for the L1VPN on the PE, a new PIT is created by the provider and associated with the VPN identifier. - The PIT (new or pre-existing) is updated to include information related to the newly added CE. The VPN-PPI, PPI, and CPI are installed in the PIT. Note that the PPI is well-known by the PE, but the CPI must be discovered either through manual configuration or automatically by mechanisms such as the Link Management Protocol (LMP) [RFC4204]. In addition, a CE-to-PE control channel needs to be configured. - The updated PIT information needs to be configured in the PITs on the remote PE associated with the L1VPN. For such purposes, manual configuration or some sort of auto-discovery mechanisms can be used. [RFC5195] and [RFC5252] specify alternative auto-discovery mechanisms. - In addition, remote PIT information associated with the L1VPN needs to be configured on this PE if the PIT has been newly created. Again, this can be achieved through manual configuration or through auto-discovery; see [RFC5195] and [RFC5252]. When L1VPN membership of an existing CE changes, or when a CE is removed from a PE, similar procedures need to be applied to update the local and remote PITs.
In each policy, the PE-to-PE path may be computed by the local PE or by a path computation entity outside of the local PE (e.g., a Path Computation Element (PCE) [RFC4655] or a management system). In policies 2 and 3, pre-computation of paths (and pre-establishment if applicable) can be done at the network planning phase, or just before signaling (e.g., triggered by an off-line customer request). As the result of pre-computation (and pre-establishment), there could be multiple PE-to-PE segments for a specific pair of PEs. When a PE receives a Path message from a CE for a L1VPN connection, a PE needs to determine which PE-to-PE segment to use. In such cases, the provider may want to control: - Which L1VPN uses which PE-to-PE L1VPN segment. - Which CE-to-CE L1VPN connection uses which PE-to-PE L1VPN segment. The former requires mapping between the PIT and the PE-to-PE segment. The latter requires some more sophisticated mapping method, for example: - Mapping between individual PIT entries and PE-to-PE segments. - Use of a Path Key ID [CONF-SEG] supplied by the provider to the CE, and signaled by the CE as part of the L1VPN connection request. The L1VPN Basic Mode does not preclude usage of other methods, if applicable. In policy 3, stitching or nesting is necessary in order to map the CE-to-CE L1VPN connection to a pre-established PE-to-PE segment. RFC3209], but the details of per-L1VPN resource models (especially in terms of CE-to-PE routing) are considered as part of the Enhanced Mode.
RFC5252] and [BGP-TE] allow CE-to-PE Traffic Engineering (TE) link information to be injected into the provider network, and in particular to be exchanged between PEs. This may be helpful for the ingress PE to prevent connection setup failure due to lack of resources or incompatible switching capabilities on remote CE-to-PE TE links. Furthermore, the L1VPN Basic Mode allows a remote CE to be reached through more than one TE link connected to the same PE (single-homed) or to different PEs (dual-homed). In such cases, to facilitate route choice, the ingress CE needs to initiate signaling by specifying the egress CE's router ID, not the egress CPI, in the Session Object and the Explicit Route Object (ERO), if present, so as to not constrain the choice of route within the provider network. Therefore, the CE's router ID needs to be configured in the PITs. Note that, as described in Section 7.2, consideration of the full feature set enabled by dual-homing (such as resiliency) is out of scope of the L1VPN Basic Mode. RFC5251].
Also note that if there are multiple CE-to-PE TE links (single-homed or multi-homed), a customer can specify which CE-to-PE TE link to use to support any L1VPN connection. Alternatively, a customer may let the provider choose the CE-to-PE TE link at the egress side, as described in Section 5.2.3. RFC4206] cannot be formed from the CE-to-CE L1VPN connection in the Basic Mode because there is no routing exchange between CE and PE. That is, the customer network and the provider network do not share a routing instance, and the customer control channel cannot be carried within the provider control plane. But where the CE provides suitable adaptation (for example, where the customer network is a packet- switched MPLS or GMPLS network), the customer control channel may be in-band and a routing adjacency may be formed between the CEs using the L1VPN connection. Otherwise, CE-to-CE control plane connectivity may form part of the L1VPN service provided to the customer by the provider and may be achieved within the L1VPN connection (for example, through the use of overhead bytes) or through a dedicated control channel connection or tunnel. The options available are discussed further in Section 10.2 of [RFC4847].
RFC5252] floods membership information not only among PEs, but also to all P nodes. This may lead to scalability concerns, compared to [RFC5195], which distributes membership information only among PEs. Alternatively, a separate instance of the OSPF protocol can be used just between PEs for distributing membership information. In such a case, Ps do not participate in flooding. Note that in the L1VPN Basic Mode, a PE needs to obtain only CE- to-PE TE link information, and not customer routing information, which is quite different from the mode of operation of an L3VPN. Therefore, the scalability concern is considered to be less problematic. o Number of L1VPN connections With the increase of this number, information to be maintained on each PE/P increases. When stitching or nesting is used, the state to be maintained at each PE increases compared to when connectivity is achieved without stitching or nesting. However, in a Layer 1 core, this number is always bounded by the available physical resource because each LSP uses a separate label which is directly bound to a physical, switchable resource
(timeslot, lambda, or fiber). Thus, it can be safely assumed that the PEs/Ps can comfortably handle the number of LSPs that they may be called on to switch for a L1VPN. RFC5251]. o PE-to-PE segment recovery The CE indicates to protect the PE-to-PE segment by including Protection Object specified in [RFC4873] in the Path message and setting Segment Recovery Flags. The CE may also indicate the branch and merge nodes by including a Secondary Explicit Route Object. Depending on the signaling mechanisms used within the provider network, details on how to protect the PE-to-PE segment may differ as follows. - If LSP stitching or LSP hierarchy are used to provision the PE- to-PE segment, then the PE-to-PE LSP may be protected using end- to-end recovery within the provider network. - If the CE-to-CE L1VPN connection is a single end-to-end LSP (including if session shuffling is used), then the PE-to-PE LSP segment may be protected using segment protection [RFC4873]. o CE-to-PE recovery and PE-to-PE recovery via link protection The CE indicates to protect ingress and egress CE-to-PE links as well as links within the provider network by including the Protection Object specified in [RFC3473] and setting Link Flags in the Path message. - The ingress and egress CE-to-PE link may be protected at a lower layer. Depending on the signaling mechanisms used within the provider network, details on how to protect links within the provider network may differ as follows. - If the PE-to-PE segment is provided as a single TE link (stitching or hierarchy) so that the provider network can perform simple PE-to-PE routing, then the TE link may offer link-level protection through the instantiation of multiple PE-to-PE LSPs.
- The PE-to-PE segment may be provisioned using only link-protected links within the core network. Note that it is not possible to protect only the CE-to-PE portion or the PE-to-PE portion by link protection because the CE-to-CE signaling request asks for a certain level of link protection on all links used by the LSP. Also, it is not possible to protect the CE- to-PE portion by link recovery and the PE-to-PE portion by segment recovery at the same time. CE-to-CE recovery through the use of connections from one CE to diverse PEs (i.e., dual-homing) is not supported in the L1VPN Basic Mode. RFC4204] and fault handling in RSVP-TE ([RFC3473] and [RFC5063]) between a CE and a PE, as well as within the provider network. RFC4847], and this section describes how these considerations are addressed in the L1VPN Basic Mode. Additional discussion of GMPLS security can be found in [GMPLS-SEC]. RFC5251], a provider's topology confidentiality is preserved by the Basic Mode. Since there is no routing exchange between PE and CE, the customer network can gather no information about the provider network. Further, as described in Section 4 of [RFC4208], a PE may filter the information present in a Record Route Object (RRO) that is signaled from the provider network to the customer network. In addition, as described in Section 5 of [RFC4208] and Section 4.4 of [RFC5251], when a Notify message is sent to a CE, it is possible to hide the provider internal address. This is accomplished by a PE updating the Notify Node Address with its own address when the PE receives a NOTIFY_REQUEST object from the CE. Even in the case of pre-computed and/or pre-signaled PE-to-PE segments, provider topology confidentiality may be preserved through the use of path key IDs [CONF-SEG].
The customer's topology confidentiality cannot be completely hidden from the provider network. At the least, the provider network will know about the addresses and locations of CEs. Other customer topology information will remain hidden from the provider in the Basic Mode, although care may be needed to protect the customer control channel as described in Section 8.4. The provider network is responsible for maintaining confidentiality of topology information between customers and across L1VPNs. Since there is no distribution of routing information from PE to CE in the Basic Mode, there is no mechanism by which the provider could accidentally, or deliberately but automatically, distribute this information. RFC4847], at Layer 1, data plane information is normally assumed to be secure once connections are established since the optical signals themselves are normally considered to be hard to intercept or modify, and it is considered difficult to insert data into an optical stream. The very use of an optical signal may be considered to provide confidentiality and integrity to the payload data. Furthermore, as indicated in [RFC4847], L1VPN connections are
each dedicated to a specific L1VPN by which an additional element of security for the payload data is provided. Misconnection remains a security vulnerability for user data. If a L1VPN connection were to be misconnected to the wrong destination, user data would be delivered to the wrong consumers. In order to protect against mis-delivery, each L1VPN connection is restricted to use only within a single L1VPN. That is, a L1VPN connection does not connect CEs that are in different L1VPNs. In order to realize this, the identity of CEs is assured as part of the service contract. And upon receipt of a request for connection setup, the provider network assures that the connection is requested between CEs belonging to the same L1VPN. This is achieved as described in Section 5.3. Furthermore, users with greater sensitivity to the security of their payload data should apply appropriate security measures within their own network layer. For example, a customer exchanging IP traffic over a L1VPN connection may choose to use IPsec to secure that traffic (i.e., to operate IPsec on the CE-to-CE exchange of IP traffic). RFC3209]. That is, control plane entities are identified within the core protocols used for signaling, but are not authenticated unless the authentication procedures of [RFC3209] are used. Second, it must be possible to secure communication over a CE-to-PE control channel. If a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, the communication channel could be considered as secure. However, when the communication channel is physically shared among customers, security mechanisms need to be available and should be enforced. RSVP-TE [RFC3209] provides for tamper-protection of signaling message exchanges through the optional Integrity object. IPsec tunnels can be used to carry the control plane messages to further ensure the integrity of the signaling messages. Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms, such as
IPsec, to assure higher security, and such mechanisms must be available. Furthermore, the provider network needs mechanisms to detect DoS attacks and to protect against them reactively and proactively. In the Basic Mode, this relies on management systems. For example, management systems collect and analyze statistics on signaling requests from CEs, and protect against malicious behaviors where necessary. Lastly, it should be noted that customer control plane traffic carried over the provider network between CEs needs to be protected. Such protection is normally the responsibility of the customer network and can use the security mechanisms of the customer signaling and routing protocols (for example, RSVP-TE [RFC3209]) or may use IPsec tunnels between CEs. CE-to-CE control plane security may form part of the data plane protection where the control plane traffic is carried in-band in the L1VPN connection. Where the CE-to-CE control plane connectivity is provided as an explicit part of the L1VPN service by the provider, control plane security should form part of the service agreement between the provider and customer. RFC4847]. In the L1VPN Basic Mode, we rely on management systems for various aspects of the different service functions, such as fault management, configuration and policy management, accounting management, performance management, and security management (as described in Section 8). In order to support various management functionalities, MIB modules need to be supported. In particular, the GMPLS TE MIB (GMPLS-TE-STD- MIB) [RFC4802] can be used for GMPLS-based traffic engineering configuration and management, while the TE Link MIB (TE-LINK-STD-MIB) [RFC4220] can be used for configuration and management of TE links. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4026] Anderssion, L. and Madsen, T., "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008. [RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008. [RFC5252] Bryskin, I. and Berger, L., "OSPF-Based Layer 1 VPN Auto- Discovery", RFC 5252, July 2008. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005. [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007. [RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007. [BGP-TE] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "Traffic Engineering Attribute", Work in Progress, January 2008. [CONF-SEG] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, May 2008. [GMPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, February 2008.
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.