doc: Add RFC documents

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]
+