summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5253.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5253.txt')
-rw-r--r--doc/rfc/rfc5253.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5253.txt b/doc/rfc/rfc5253.txt
new file mode 100644
index 0000000..c7adc21
--- /dev/null
+++ b/doc/rfc/rfc5253.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+ This 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takeda Informational [Page 1]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+Table of Contents
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takeda Informational [Page 2]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+1. Introduction
+
+ This document provides an applicability statement on the use of
+ Generalized Multiprotocol Label Switching (GMPLS) protocols and
+ mechanisms to Basic Mode Layer 1 Virtual Private Networks (L1VPNs) as
+ specified in [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.
+
+1.1. Terminology
+
+ The reader is assumed to be familiar with the terminology in
+ [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026], and
+ [RFC4847].
+
+2. Basic Mode Overview
+
+ As described in [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
+
+
+
+Takeda Informational [Page 3]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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.
+
+3. Supported Network Types
+
+3.1. Data Plane
+
+ The provider network can be constructed from any type of Layer 1
+ switches, such as Time Division Multiplexing (TDM) switches, Optical
+ Cross-Connects (OXCs), or Photonic Cross-Connects (PXCs).
+ Furthermore, a PE may be an Ethernet Private Line (EPL) type of
+ device, that maps Ethernet frames onto Layer 1 connections (by means
+ of Ethernet over TDM, etc.). The provider network may be constructed
+ from switches providing a single switching granularity (e.g., only
+ VC3 switches), or from switches providing multiple switching
+ granularities (e.g., from VC3/VC4 switches, or from VC3 switches and
+ OXCs). The provider network may provide a single type of L1VPN
+ connection (e.g., VC3 connections only), or multiple types of
+ connection (e.g., VC3/VC4 connections, or VC3 connections and
+ wavelength connections).
+
+ A CE does not have to have the capability to switch at Layer 1, but
+ it must be capable of receiving a Layer 1 signal and either switching
+ it or terminating it with adaptation.
+
+ As described in [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.
+
+3.2. Control Plane
+
+ The provider network is controlled by GMPLS. L1VPN Basic Mode
+ provider networks are limited to a single AS within the scope of this
+ document. Multi-AS Basic Mode L1VPNs are for future study.
+
+
+
+
+Takeda Informational [Page 4]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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.
+
+4. Addressing
+
+ As described in [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).
+
+5. Provider Control of Its Infrastructure
+
+5.1. Provisioning Model
+
+ As described in [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.
+
+
+
+Takeda Informational [Page 5]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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.
+
+5.2. PE-to-PE Segment Control
+
+ In the L1VPN Basic Mode, a PE-to-PE segment of a CE-to-CE L1VPN
+ connection is completely under the control of the provider network.
+
+5.2.1. Path Computation and Establishment
+
+ A PE-to-PE segment of a CE-to-CE L1VPN connection may be established
+ based on various policies. Those policies can be applied per L1VPN
+ or per L1VPN connection. The policy is configured by the provider,
+ possibly based on the contracts with each customer.
+
+ Examples of PE-to-PE segment connection establishment polices
+ supported in the L1VPN Basic Mode are as follows.
+
+ - Policy 1: On-demand establishment, on-demand path computation
+ - Policy 2: On-demand establishment, pre-computed path
+ - Policy 3: Pre-establishment, pre-computed path
+
+
+
+Takeda Informational [Page 6]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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.
+
+5.2.2. Resource Management
+
+ The provider network may operate resource management based on various
+ policies. These policies can be applied per L1VPN or per L1VPN
+ connection. The policy is configured by the provider, possibly based
+ on the contracts with each customer.
+
+ For example, a provider may choose to partition the resources of the
+ provider network for limited use by different L1VPNs or customers.
+ Such a function might be achieved within the scope of the Basic Mode
+ using resource affinities [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.
+
+
+
+
+
+
+
+
+Takeda Informational [Page 7]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+5.2.3. Consideration of CE-to-PE Traffic Engineering Information
+
+ [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.
+
+5.3. Connectivity Restriction
+
+ The L1VPN Basic Mode allows restricting connection establishment
+ between CEs belonging to the same L1VPN for policy reasons (including
+ L1VPN security). Since the PIT at each PE is associated with a
+ L1VPN, this function can be easily supported. The restriction can be
+ applied at the ingress PE or at the egress PE according to the
+ applicable restriction policy, but note that applying the policy at
+ the egress may waste signaling effort within the network as L1VPN
+ connections are pointlessly attempted.
+
+ In addition, the L1VPN Basic Mode does not restrict use of any
+ advanced admission control based on various policies.
+
+6. Customer Control of Its L1VPN
+
+6.1. Topology Control
+
+ In the L1VPN Basic Mode, L1VPN connection topology is controlled by
+ the customer. That is, a customer can request
+ setup/deletion/modification of L1VPN connections using signaling
+ mechanisms specified in [RFC5251].
+
+
+
+
+
+
+
+Takeda Informational [Page 8]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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.
+
+6.2. Note on Routing
+
+ A CE needs to obtain the remote CPI to which it wishes to request a
+ connection. Since, in the L1VPN Basic Mode, there is no routing
+ information exchange between a CE and a PE, there is no dynamic
+ mechanism supported as part of the Basic Mode L1VPN service, and the
+ knowledge of remote CPIs must be acquired in a L1VPN-specific way,
+ perhaps through configuration or through a directory server.
+
+ If an L1VPN is used by a customer to operate a private IP network,
+ the customer may wish to form routing adjacencies over the CE-to-CE
+ L1VPN connections. The L1VPN Basic Mode does not enforce any
+ restriction on such operation by a customer, and the use made of the
+ L1VPN connections is transparent to the provider network.
+
+ Furthermore, if an L1VPN is used by a customer to operate a private
+ Multiprotocol Label Switching (MPLS) or GMPLS network, the customer
+ may wish to treat a L1VPN connection as a TE link, and this requires
+ a CE-to-CE control channel. Note that a Forwarding Adjacency
+ [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].
+
+
+
+
+
+
+
+
+
+
+
+
+Takeda Informational [Page 9]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+7. Scalability and Resiliency
+
+7.1. Scalability
+
+ There are several factors that impact scalability.
+
+ o Number of L1VPNs (PITs) configured on each PE
+
+ With the increase of this number, information to be maintained on
+ the PE increases. Theoretically, the upper limit of the number of
+ L1VPNs supported in a provider network is governed by how the ID
+ associated with a L1VPN is allocated, and the number of PITs
+ configured on each PE is limited by this number. However,
+ implementations may impose arbitrary limits on the number of PITs
+ supported by any one PE.
+
+ o Number of CE-to-PE TE links for each L1VPN
+
+ With the increase of this number, information to be maintained in
+ each PIT increases. When auto-discovery mechanisms are used, the
+ amount of information that an auto-discovery mechanism can support
+ may restrict this number.
+
+ Note that [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
+
+
+
+
+Takeda Informational [Page 10]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ (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.
+
+7.2. Data Plane Resiliency
+
+ The L1VPN Basic Mode supports the following data plane recovery
+ techniques [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.
+
+
+
+
+Takeda Informational [Page 11]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ - 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.
+
+7.3. Control Plane Resiliency
+
+ The L1VPN Basic Mode allows use of GMPLS control plane resiliency
+ mechanisms. This includes, but is not limited to, control channel
+ management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473]
+ and [RFC5063]) between a CE and a PE, as well as within the provider
+ network.
+
+8. Security Considerations
+
+ Security considerations are described in [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].
+
+8.1. Topology Confidentiality
+
+ As specified in [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].
+
+
+
+
+Takeda Informational [Page 12]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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.
+
+8.2. External Control of the Provider Network
+
+ The provider network is protected from direct control from within
+ customer networks through policy and through filtering of signaling
+ messages.
+
+ There is a service-based policy installed at each PE that directs how
+ a PE should react to a L1VPN connection request received from any CE.
+ Each CE is configured at the PE (or through a policy server) for its
+ membership of a L1VPN, and so CEs cannot dynamically bind to a PE or
+ join a L1VPN. With this configuration comes the policy that tells
+ the PE how to react to a L1VPN connection request (for example,
+ whether to allow dynamic establishment of PE-to-PE connections).
+ Thus, the provider network is protected against spurious L1VPN
+ connection requests and can charge for all L1VPN connections
+ according to the service agreement with the customers. Hence, the
+ provider network is substantially protected against denial-of-service
+ (DoS) attacks.
+
+ At the same time, if a Path message from a CE contains an Explicit
+ Route Object (ERO) specifying the route within provider network, it
+ is rejected by the PE. Thus, the customer network has no control
+ over the resources in the provider network.
+
+8.3. Data Plane Security
+
+ As described in [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
+
+
+
+
+Takeda Informational [Page 13]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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).
+
+8.4 Control Plane Security
+
+ There are two aspects for control plane security.
+
+ First, the entity connected over a CE-to-PE control channel must be
+ identified. This is done when a new CE is added as part of the
+ service contract and the necessary control channel is established.
+ This identification can use authentication procedures available in
+ RSVP-TE [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
+
+
+
+
+Takeda Informational [Page 14]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ 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.
+
+9. Manageability Considerations
+
+ Manageability considerations are described in [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.
+
+10. References
+
+10.1. Normative References
+
+ [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.
+
+
+
+
+Takeda Informational [Page 15]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ [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.
+
+10.2. Informative References
+
+ [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.
+
+
+
+Takeda Informational [Page 16]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+ [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.
+
+11. Acknowledgments
+
+ The authors would like to thank Ichiro Inoue for valuable comments.
+ In addition, the authors would like to thank Marco Carugi and Takumi
+ Ohba for valuable comments in the early development of this document.
+
+ Thanks to Tim Polk and Mark Townsley for comments during IESG review.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takeda Informational [Page 17]
+
+RFC 5253 AS for L1VPN Basic Mode July 2008
+
+
+Authors' Addresses
+
+ Tomonori Takeda (editor)
+ NTT Network Service Systems Laboratories, NTT Corporation
+ 3-9-11, Midori-Cho
+ Musashino-Shi, Tokyo 180-8585 Japan
+ Phone: +81 422 59 7434
+ EMail: takeda.tomonori@lab.ntt.co.jp
+
+ Deborah Brungard
+ AT&T
+ Rm. D1-3C22 - 200 S. Laurel Ave.
+ Middletown, NJ 07748, USA
+ Phone: +1 732 4201573
+ EMail: dbrungard@att.com
+
+ Adrian Farrel
+ Old Dog Consulting
+ Phone: +44 (0) 1978 860944
+ EMail: adrian@olddog.co.uk
+
+ Hamid Ould-Brahim
+ Nortel Networks
+ P O Box 3511 Station C
+ Ottawa, ON K1Y 4H7 Canada
+ Phone: +1 (613) 765 3418
+ EMail: hbrahim@nortel.com
+
+ Dimitri Papadimitriou
+ Alcatel-Lucent
+ Francis Wellensplein 1,
+ B-2018 Antwerpen, Belgium
+ Phone: +32 3 2408491
+ EMail: dimitri.papadimitriou@alcatel-lucent.be
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takeda Informational [Page 18]
+
+RFC 5253 AS for L1VPN Basic Mode July 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
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Takeda Informational [Page 19]
+