summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5251.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5251.txt')
-rw-r--r--doc/rfc/rfc5251.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc5251.txt b/doc/rfc/rfc5251.txt
new file mode 100644
index 0000000..2371df3
--- /dev/null
+++ b/doc/rfc/rfc5251.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group D. Fedyk, Ed.
+Request for Comments: 5251 Nortel
+Category: Standards Track Y. Rekhter, Ed.
+ Juniper Networks
+ D. Papadimitriou
+ Alcatel-Lucent
+ R. Rabbat
+ Google
+ L. Berger
+ LabN
+ July 2008
+
+
+ Layer 1 VPN Basic Mode
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document describes the Basic Mode of Layer 1 VPNs (L1VPNs).
+ L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic
+ Mode, the basic unit of service is a Label Switched Path (LSP)
+ between a pair of customer ports within a given VPN port topology.
+ This document defines the operational model using either provisioning
+ or a VPN auto-discovery mechanism, and the signaling extensions for
+ the L1VPN BM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 1]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Conventions Used in This Document ..........................4
+ 2. Layer 1 VPN Service .............................................4
+ 3. Addressing, Ports, Links, and Control Channels ..................7
+ 3.1. Service Provider Realm .....................................7
+ 3.2. Layer 1 Ports and Index ....................................7
+ 3.3. Port and Index Mapping .....................................8
+ 4. Port-Based L1VPN Basic Mode ....................................10
+ 4.1. L1VPN Port Information Tables .............................11
+ 4.1.1. Local Auto-Discovery Information ...................12
+ 4.1.2. PE Remote Auto-Discovery Information ...............12
+ 4.2. CE-to-CE LSP Establishment ................................14
+ 4.3. Signaling .................................................15
+ 4.3.1. Signaling Procedures ...............................15
+ 4.3.1.1. Shuffling Sessions ........................16
+ 4.3.1.2. Stitched or Nested Sessions ...............17
+ 4.3.1.3. Other Signaling ...........................18
+ 4.4. Recovery Procedures .......................................19
+ 5. Security Considerations ........................................20
+ 6. References .....................................................21
+ 6.1. Normative References ......................................21
+ 6.2. Informative References ....................................22
+ 7. Acknowledgments ................................................23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 2]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+1. Introduction
+
+ This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM)
+ that is outlined in [RFC4847]. The applicability of Layer 1 VPNS is
+ covered in [RFC5253]. In this document, we consider a layer 1
+ service provider network that consists of devices that support GMPLS
+ (e.g., Lambda Switch Capable (LSC) devices, optical cross-connects,
+ Synchronous Optical Network / Synchronous Digital Hierarchy
+ (SONET/SDH) cross-connects, etc.). We partition these devices into P
+ (provider) and PE (provider edge) devices. In the context of this
+ document we will refer to the former devices as just "P", and to the
+ latter devices as just "PE". The Ps are connected only to the
+ devices within the provider's network. The PEs are connected to the
+ other devices within the network (either Ps or PEs), as well as to
+ the devices outside of the service provider network. We'll refer to
+ such other devices as Customer Edge (CE) devices. An example of a CE
+ would be a GMPLS-enabled device that is either a router, an SDH
+ cross-connect, or an Ethernet switch.
+
+ [RFC4208] defines signaling from the CE to the PE. In [RFC4208], the
+ term "Core Node (CN)" corresponds to P and PE nodes, and the term
+ "Edge Node (EN)" corresponds to CE nodes. We additionally define an
+ "edge Core Node" corresponding to a PE.
+
+ Figure 1 illustrates the components in an L1VPN network.
+
+ +---+ +---+
+ | P |....| P |
+ +---+ +---+
+ / \
+ +-----+ +-----+ +--+
+ +--+ | PE | | |----| |
+ |CE|----| | | | |CE|
+ +--+\ +-----+ | |----| |
+ \ | | PE | +--+
+ \ +-----+ | |
+ \| PE | | | +--+
+ | | | |----|CE|
+ +-----+ +-----+ +--+
+ \ /
+ +---+ +---+
+ | P |....| P |
+ +---+ +---+
+
+ Figure 1: Generalized Layer 1 VPN Reference Model
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 3]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ This document specifies how the L1VPN Basic Mode service can be
+ realized using off-line provisioning or VPN auto-discovery,
+ Generalized Multi-Protocol Label Switching (GMPLS) Signaling
+ [RFC3471], [RFC3473], Routing [RFC4202], and LMP [RFC4204]
+ mechanisms.
+
+ L1VPN auto-discovery has similar requirements [RFC4847] to L3VPN
+ auto-discovery. As with L3VPNs, there are protocol choices to be
+ made with auto-discovery. Section 4.1.1 deals with the information
+ that needs to be discovered.
+
+ GMPLS routing and signaling are used without extensions within the
+ service provider network to establish and maintain LSC or SONET/SDH
+ (Time Division Multiplexing (TDM)) connections between service
+ provider nodes. This follows the model in [RFC4208].
+
+ In L1VPN Basic Mode, the use of LMP facilitates the population of the
+ Port Information Tables of the service provider. Indeed, LMP MAY be
+ used as an option to automate local CE-to-PE link discovery. LMP
+ also MAY augment routing (in enhanced mode) as well as failure
+ handling capabilities.
+
+ Consideration of inter-AS and inter-provider L1VPNs requires further
+ analysis beyond the scope of this document.
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ This document expects that the reader is familiar with the
+ terminology defined and used in [RFC3945], [RFC3471], [RFC3473],
+ [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208], and the
+ documents referenced therein.
+
+2. Layer 1 VPN Service
+
+ Layer 1 VPN services on the interfaces of customer and service
+ provider ports MAY be any of the Layer 1 interfaces supported by
+ GMPLS. Since the mechanisms specified in this document use GMPLS as
+ the signaling mechanism, and since GMPLS applies to both SONET/SDH
+ (TDM) and LSC interfaces, it follows that L1VPN services include (but
+ are not restricted) to LSC- or TDM-based equipment. Note that this
+ document describes Basic Mode L1VPNs and as such requires that:
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 4]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ (1) GMPLS RSVP-TE is used for signaling both within the service
+ provider (between PEs), as well as between the customer and the
+ service provider (between CE and PE);
+
+ (2) GMPLS Routing on the CE-to-PE link is outside the scope of the
+ Basic Mode of operation of L1VPN; see [RFC4847].
+
+ A CE is connected to a PE via one or more links. In the context of
+ this document, a link is a GMPLS Traffic Engineering (TE) link
+ construct, as defined in [RFC4202]. In the context of this document,
+ a TE link is a logical construct that is a member of a VPN, hence
+ introducing the notion of membership to a set of CEs forming the VPN.
+ Interfaces at the end of each link are limited to either TDM or LSC
+ as supported by GMPLS. More specifically, a <CE, PE> link MUST be of
+ the type <X, LSC> or <Y, TDM> where X = PSC (Packet Switch Capable),
+ L2SC (Layer 2 Switch Capable), or TDM and Y = PSC or L2SC. In case
+ the LSP is not terminated by the CE, X MAY also = LSC and Y = TDM.
+ One of the applications of a L1VPN connection is to provide a
+ "virtual private lambda" or similar. In this case, the CE is truly
+ the endpoint in GMPLS terms, and its switching capability on the TE
+ link is not relevant (although its Generalized Protocol Identifier
+ (GPID) MUST be signaled and identical at both CEs, i.e., head-end and
+ tail-end CE).
+
+ Likewise, PEs could be any Layer 1 devices that are supported by
+ GMPLS (e.g., optical cross-connects, SDH cross-connects), while CEs
+ MAY be devices at layers 1, 2, and 3, such as an SDH cross-connect,
+ an Ethernet switch, and a router, respectively).
+
+ Each TE link MAY consist of one or more channels or sub-channels
+ (e.g., wavelength or wavelength and timeslot, respectively). For the
+ purpose of this discussion, all the channels within a given link MUST
+ have similar shared characteristics (e.g., switching capability,
+ encoding, type, etc.), and MAY be selected independently from the
+ CE's point of view. Channels on different links of a CE need not
+ have the same characteristics.
+
+ There MAY be more than one TE link between a given CE-PE pair. A CE
+ MAY be connected to more than one PE (with at least one port per PE).
+ And, conversely, a PE MAY have more than one CE from different VPNs
+ connected to it.
+
+ If a CE is connected to a PE via multiple TE links and all the links
+ belong to the same VPN, these links (referred to as component links)
+ MAY be treated as a single TE link using the link bundling constructs
+ [RFC4201].
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 5]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ In order to satisfy the requirements of the L1VPN Basic Mode, it is
+ REQUIRED that for a given CE-PE pair at least one of the links
+ between them has at least one data bearing channel, and at least one
+ control bearing channel, or that there is IP reachability between the
+ CE and the PE that could be used to exchange control information.
+
+ A point-to-point link has two end-points: one on the CE and one on
+ the PE. This document refers to the former as "CE port", and to the
+ latter as "PE port". From the above, it follows that a CE is
+ connected to a PE via one or more ports, where each port MAY consist
+ of one or more channels or sub-channels (e.g., wavelength or
+ wavelength and timeslot, respectively), and all the channels within a
+ given port have shared similar characteristics and can be
+ interchanged from the CE's point of view. Similar to the definition
+ of a TE link, in the context of this document, ports are logical
+ constructs that are used to represent a grouping of physical
+ resources that are used to connect a CE to a PE on a per-L1VPN basis.
+
+ At any point in time, a given port on a PE is associated with at most
+ one L1VPN, or, to be more precise, with at most one Port Information
+ Table maintained by the PE (although different ports on a given PE
+ could be associated with different L1VPNs, or, to be more precise,
+ with different Port Information Tables). The association of a port
+ with a VPN MAY be defined by provisioning the relationship on the
+ service provider devices. In other words, the context of a VPN
+ membership in Basic Mode is enforced through service provider
+ control.
+
+ It is REQUIRED that the interface (that is between the CE and PE and
+ that is used for the purpose of signaling) be capable of
+ initiating/processing GMPLS protocol messages [RFC3473] and of
+ following the procedures described in [RFC4208].
+
+ An important goal of L1VPN service is the ability to support what is
+ known as "single-ended provisioning", where the addition of a new
+ port to a given L1VPN involves configuration changes only on the PE
+ that has this port. The extension of this model to the CE is outside
+ the scope of the L1VPN BM.
+
+ Another important goal in the L1VPN service is the ability to
+ establish/terminate an LSP between a pair of (existing) ports within
+ an L1VPN from the CE devices without involving configuration changes
+ in any of the service provider's devices. In other words, the VPN
+ topology is under the CE device control (assuming that the underlying
+ PE-to-PE connectivity is provided and allowed by the network).
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 6]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ The mechanisms outlined in this document aim to achieve the above
+ goals. Specifically, as part of the L1VPN service offering, these
+ mechanisms (1) enable the service provider to restrict the set of
+ ports to which a given port could be connected and (2) enable a CE to
+ establish the actual LSP to a subset of ports. Finally, the
+ mechanisms allow arbitrary L1VPN topologies to be supported;
+ including topologies ranging from hub-and-spoke to full mesh point-
+ to-point connections. Only point-to-point links are supported.
+
+ The exchange of CE routing or topology information to the service
+ provider is out of scope for L1VPN BM mode.
+
+3. Addressing, Ports, Links, and Control Channels
+
+ GMPLS-established conventions for addressing and link numbering are
+ discussed in [RFC3945]. This section builds on those definitions for
+ the L1VPN case where we now have customer and service provider
+ addresses in a Layer 1 context.
+
+3.1. Service Provider Realm
+
+ It is REQUIRED that a service provider, or a group of service
+ providers that collectively offer L1VPN service, have a single
+ addressing realm that spans all PE devices involved in providing the
+ L1VPN service. This is necessary to enable GMPLS mechanisms for path
+ establishment and maintenance. We will refer to this realm as the
+ service provider addressing realm. It is further REQUIRED that each
+ L1VPN customer have its own addressing realm with complete freedom to
+ use private or public addresses. We will refer to such realms as the
+ customer addressing realms. Customer addressing realms MAY overlap
+ addresses (i.e., non-unique address) with each other, and MAY also
+ overlap addresses with the service provider realm.
+
+3.2. Layer 1 Ports and Index
+
+ Within a given L1VPN, each port on a CE that connects the CE to a PE
+ has an identifier that is unique within that L1VPN (but need not be
+ unique across several L1VPNs). One way to construct such an
+ identifier is to assign each port an address that is unique within a
+ given L1VPN, and use this address as a port identifier. Another way
+ to construct such an identifier is to assign each port on a CE an
+ index that is unique within that CE, assign each CE an address that
+ is unique within a given L1VPN, and then use a tuple <port index, CE
+ address> as a port identifier. Note that both the port and the CE
+ address MAY be an address in several formats. This includes, but is
+ not limited to, IPv4 and IPv6. This identifier is part of the
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 7]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ Customer addressing Realm and is used by the CE device to identify
+ the CE port and the CE remote port for signaling. CEs do not know or
+ understand the service provider realm addresses.
+
+ Within a service provider network, each port on a PE that connects
+ that PE to a CE has an identifier that is unique within that network.
+ One way to construct such an identifier is to assign each port on a
+ PE an index that is unique within that PE, assign each PE an IP
+ address that is unique within the service provider addressing realm,
+ and then use a tuple <port index, PE IPv4 address> or <port index, PE
+ IPv6 address> as a port identifier within the service provider
+ network. Another way to construct such an identifier is to assign an
+ IPv4 or IPv6 address that is unique within the service provider
+ addressing realm to each such port. Either way, this IPv4 or IPv6
+ address is internal to the service provider network and is used for
+ GMPLS signaling within the service provider network.
+
+ As a result, each link connecting the CE to the PE is associated with
+ a CE port that has a unique identifier within a given L1VPN, and with
+ a PE port that has a unique identifier within the service provider
+ network. We'll refer to the former as the Customer Port Identifier
+ (CPI), and to the latter as the Provider Port Identifier (PPI).
+
+3.3. Port and Index Mapping
+
+ This document requires that each PE port that has a PPI also has an
+ identifier that is unique within the L1VPN customer addressing realm
+ of the L1VPN associated with that port. One way to construct such an
+ identifier is to assign each port an address that is unique within a
+ given L1VPN customer addressing realm, and use this address as a port
+ identifier. Another way to construct such an identifier is to assign
+ each port an index that is unique within a given PE, assign each PE
+ an IP address that is unique within a given L1VPN customer addressing
+ realm (but need not be unique within the service provider network),
+ and then use a tuple <port index, PE IP address> that acts as a port
+ identifier. We'll refer to such port identifier as the VPN-PPI. See
+ Figure 2.
+
+ For L1VPNs, it is a requirement that service provider operations are
+ independent of the VPN customer's addressing realm and the service
+ provider addressing realm is hidden from the customer. To achieve
+ this, we define two identifiers at the PE, one customer facing and
+ the other service provider facing. The PE IP address used for the
+ VPN-PPI is independent of the PE IP address used for the PPI (as the
+ two are taken from different address realms, the former from the
+ customer's addressing realm and the latter from a VPN service
+ provider's addressing realm). If for a given port on a PE, the PPI
+
+
+
+
+Fedyk, et al. Standards Track [Page 8]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ and the VPN-PPI port identifiers are unnumbered, then they both could
+ use exactly the same port index. This is a mere convenience since
+ the PPI and VPN_PPI can be in any combination of valid formats.
+
+ (Customer realm)
+ +----+ +----+
+ | |<Port Index> <Port Index> | |
+ | |CPI VPN-PPI | |
+ ---| CE |-----------------------------| PE |---
+ | | <Port Index> | |
+ | | PPI | |
+ +----+ +----+
+ (Provider realm)
+
+ Figure 2: Customer/Provider Port/Index Mapping
+
+ Note, as stated earlier, that IP addresses used for the CPIs, PPIs,
+ and VPN-PPIs could be either IPv4 or IPv6 format addresses.
+
+ For a given link connecting a CE to a PE:
+
+ - If the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4
+ address as well since VPN-PPIs are created from the customer
+ address space. If the CPI is a <port index, CPI IPv4 address>
+ tuple, then the VPN-PPI MUST be a <port index, PE IPv4 address>
+ tuple for the same reason.
+
+ - If the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6
+ address as well since VPN-PPIs are created from the customer
+ address space. If the CPI is a <port index, CPI IPv6 address>
+ tuple, then the VPN-PPI MUST be a <port index, PE IPv6 address>
+ tuple for the same reason.
+
+ Note: for a given port on the PE, whether the VPN-PPI of that port is
+ an IP address or a <port index, PE IP address> is independent of the
+ format of the PPI of that port.
+
+ This document assumes that assignment of the PPIs is controlled
+ solely by the service provider (without any coordination with the
+ L1VPN customers), while assignment of addresses used by the CPIs and
+ VPN-PPIs is controlled solely by the administrators of L1VPN. This
+ provides maximum flexibility. The L1VPN administrator is the entity
+ that controls the L1VPN service specifics for the L1VPN customers.
+ This function may be owned by the service provider but may also be
+ performed by a third party who has agreements with the service
+ provider. And, of course, each L1VPN customer could assign such
+ addresses on its own, without any coordination with other L1VPNs.
+
+
+
+
+Fedyk, et al. Standards Track [Page 9]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ This document also requires IP connectivity between the CE and the PE
+ as specified earlier, which is used for the control channel between
+ CE and PE. This connectivity could be either a single IP hop, which
+ could be realized by either a dedicated link or by an L2 VPN, or an
+ IP private network, such as an L3VPN. The only requirement on this
+ connectivity is an unambiguous way to correlate a particular CE-to-PE
+ control channel with a particular L1VPN. When such a channel is
+ realized by a dedicated link, such a link should be associated with a
+ particular L1VPN. When such channel is realized by an L2VPN, a
+ distinct L2VPN should be associated with an L1VPN. When such channel
+ is realized by an L3VPN, a distinct L3VPN should be associated with
+ an L1VPN.
+
+ We'll refer to the CE's address of this channel as the CE Control
+ Channel Address (CE-CC-Addr), and to the PE's address of this channel
+ as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and
+ PE-CC-Addr are REQUIRED to be unique within the L1VPN they belong to,
+ but are not REQUIRED to be unique across multiple L1VPNs. Control
+ channel addresses are not shared amongst multiple VPNs. Assignment
+ of CE-CC-Addr and PE-CC-Addr is controlled by the administrators of
+ the L1VPN.
+
+ Multiple ports on a CE could share the same control channel only as
+ long as all these ports belong to the same L1VPN. Likewise, multiple
+ ports on a PE could share the same control channel only as long as
+ all these ports belong to the same L1VPN.
+
+4. Port-Based L1VPN Basic Mode
+
+ An L1VPN is a port-based VPN service where a pair of CEs could be
+ connected through the service provider network via a GMPLS-based LSP
+ within a given VPN port topology. It is precisely this LSP that
+ forms the basic unit of the L1VPN service that the service provider
+ network offers. If a port by which a CE is connected to a PE
+ consists of multiple channels (e.g., multiple wavelengths), the CE
+ could establish LSPs to multiple other CEs in the same VPN over this
+ single port.
+
+ In the L1VPN, the service provider does not initiate the creation of
+ an LSP between a pair of CE ports. The LSP establishment is
+ initiated by the CE. However, the SP, by using the
+ mechanisms/toolkit outlined in this document, restricts the set of
+ other CE ports, which may be the remote endpoints of LSPs that have
+ the given port as the local endpoint. Subject to these restrictions,
+ the CE-to-CE connectivity is under the control of the CEs themselves.
+ In other words, the SP allows a L1VPN to have a certain set of
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 10]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ topologies (expressed as a port-to-port connectivity matrix).
+ CE-initiated signaling is used to choose a particular topology from
+ that set.
+
+ For each L1VPN that has at least one port on a given PE, the PE
+ maintains a Port Information Table (PIT) associated with that L1VPN.
+ This table contains a list of <CPI, PPI> tuples for all the ports
+ within its L1VPN. In addition, for local PE ports of a given L1VPN,
+ the tuples also include the VPN-PPIs of these ports.
+
+ PE PE
+ +---------+ +--------------+
+ +--------+ | +------+| | +----------+ | +--------+
+ | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
+ | CE1 |--| |PIT || Route | | PIT | |-| CE2 |
+ +--------+ | | ||<----------->| | | | +--------+
+ | +------+|Dissemination| +----------+ |
+ | | | |
+ +--------+ | +------+| | +----------+ | +--------+
+ | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
+ | CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+ +--------+ | | || (Backbone ) | | | | +--------+
+ | +------+| --------- | +----------+ |
+ | | | |
+ +--------+ | +-----+ | | +----------+ | +--------+
+ | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
+ | CE1 |--| |PIT | | | | PIT | |-| CE2 |
+ +--------+ | | | | | | | | +--------+
+ | +-----+ | | +----------+ |
+ +---------+ +--------------+
+
+ Figure 3: Basic Mode L1VPN Service
+
+4.1. L1VPN Port Information Tables
+
+ Figure 3 illustrates three VPNs, VPN-A, VPN-B, and VPN-C, with their
+ associated PITs. A PIT consists of local information as well as
+ remote information. It follows that a PIT on a given PE is populated
+ from two information sources:
+
+ 1. The information related to the CEs' ports that are attached to
+ the ports local to that PE.
+
+ 2. The information about the CEs connected to the remote PEs.
+
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 11]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ A PIT MAY be populated via provisioning or by auto-discovery
+ procedures. When provisioning is used, the entire table MAY be
+ populated by provisioning commands either at a console or by a
+ management system that may have some automation capability. As the
+ network grows, some form of automation is desirable.
+
+ For local information between a CE and a PE, a PE MAY leverage LMP to
+ populate the <CPI, VPN-PPI> link information. This local information
+ also needs to be propagated to other PEs that share the same VPN.
+ The mechanisms for this are out of scope for this document, but the
+ information needed to be exchanged is described in Section 4.1.1.
+
+ The PIT is by nature VPN-specific. A PE is REQUIRED to maintain a
+ PIT for each L1VPN for which it has member CEs locally attached. A
+ PE does not need to maintain PITs for other L1VPNs. However, the
+ full set of PITs with all L1VPN entries for multiple VPNs MAY also be
+ available to all PEs.
+
+ The remote information in the context of a VPN identifier (i.e., the
+ remote CEs of this VPN) MAY also be sent to the local CE belonging to
+ the same VPN. Exchange of this information is outside the scope of
+ this document.
+
+4.1.1. Local Auto-Discovery Information
+
+ The information that needs to be discovered on a PE local port is the
+ local CPI and the VPN-PPI.
+
+ This information MAY be configured; or, if LMP is used between the CE
+ and PE, LMP MAY be used to exchange this information.
+
+ Once a CPI has been discovered, the corresponding VPN-PPI maps in a
+ local context to a VPN identifier and a corresponding PPI. One way
+ to enforce a provider-controlled VPN context is to pre-provision
+ VPN-PPIs with a VPN identifier. Other policy mechanisms to achieve
+ this are outside the scope of this document. In this manner, a
+ relationship of a CPI to a VPN and PPI port can be established when
+ the port is provisioned as belonging to the VPN.
+
+4.1.2. PE Remote Auto-Discovery Information
+
+ This section provides the information that is carried by any auto-
+ discovery mechanism, and is used to dynamically populate a PIT. The
+ information provides a single <CPI, PPI> mapping. Each auto-
+ discovery mechanism will define the method(s) by which multiple <CPI,
+ PPI> mappings are communicated, as well as invalidated.
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 12]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ This information should be consistent regardless of the mechanism
+ used to distribute the information [RFC5195], [RFC5252].
+
+ The format of encoding a single <PPI, CPI> tuple is:
+
+ +---------------------------------------+
+ | PPI Length (1 octet) |
+ +---------------------------------------+
+ | PPI (variable) |
+ +---------------------------------------+
+ | CPI AFI (2 octets) |
+ +---------------------------------------+
+ | CPI (length) |
+ +---------------------------------------+
+ | CPI (variable) |
+ +---------------------------------------+
+
+ Figure 4: Auto-Discovery Information
+
+ The use and meaning of these fields are as follows:
+
+ PPI Length:
+
+ A one-octet field whose value indicates the length of the PPI
+ field.
+
+ PPI:
+
+ A variable-length field that contains the value of the PPI (either
+ an address or <port index, address> tuple). Note, PPI is always
+ encoded consistently within a provider domain so the format of the
+ PPI field is implicit within a given provider network.
+
+ CPI AFI:
+
+ A two-octet field whose value indicates the address family of the
+ CPI. This value is taken from [RFC1700].
+
+ CPI Length:
+
+ A one-octet field whose value indicates the length of the CPI
+ field.
+
+ CPI:
+
+ A variable-length field that contains the CPI value (either an
+ address or <port index, address> tuple).
+
+
+
+
+Fedyk, et al. Standards Track [Page 13]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ <PPI, CPI> tuples MUST also be associated with one or more globally
+ unique identifiers associated with a particular VPN. A globally
+ unique identifier can encode a VPN-ID, a route target, or any other
+ globally unique identifier. The globally unique identifiers are
+ under control of network providers. Uniqueness within a service
+ provider administrative domain is sufficient for Basic Mode
+ operation. In the case of multiple provider networks (which is
+ beyond the scope of this document), the globally unique identifier
+ need only be unique and consistent between the those providers. In
+ this document, we specify a generic encoding format for the globally
+ unique identifier common to all the auto-discovery mechanisms.
+ However, each auto-discovery mechanism will define the specific
+ method(s) by which the encoding is distributed and the association
+ with a <PPI, CPI> tuple is made. The encoding of the globally unique
+ identifier associated with the VPN is:
+
+ +------------------------------------------------+
+ | L1VPN globally unique identifier (8 octets) |
+ +------------------------------------------------+
+
+ Figure 5: Auto-Discovery Globally Unique Identifier Format
+
+4.2. CE-to-CE LSP Establishment
+
+ In order to establish an LSP, a CE needs to identify all other CEs in
+ the CE's L1VPN that it wants to connect to. A CE may already have
+ obtained this information through provisioning or through some other
+ schemes (such schemes are outside the scope of this document).
+
+ Ports associated with a given CE-to-PE link MAY also have other
+ information, in addition to their CPI and PPI, associated with them
+ that describes characteristics and constraints of the channels within
+ these ports, such as encoding supported by the channels, bandwidth of
+ a channel, total unreserved bandwidth within the port, etc. This
+ information could be further augmented with the information about
+ certain capabilities of the service provider network (e.g., support
+ regeneration section overhead (RSOH), Data Communications Channel
+ (DCC) transparency, arbitrary concatenation, etc.). This information
+ is used to ensure that ports at each end of an LSP have compatible
+ characteristics, and that there are sufficient unallocated resources
+ to establish an LSP between these ports.
+
+ It may happen that for a given pair of ports within an L1VPN, each of
+ the CEs connected to these ports would concurrently try to establish
+ an LSP to the other CE. If having a pair of LSPs between a pair of
+ ports is viewed as undesirable, the way to resolve this is to require
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 14]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ the CE with the lower value of the CPI to terminate the LSP
+ originated by the CE. This option could be controlled by
+ configuration on the CE devices.
+
+4.3. Signaling
+
+ In L1VPN BM, a CE needs to be configured with the CPIs of other
+ ports. Once a CE is configured with the CPIs of the other ports
+ within the same L1VPN, which we'll refer to as "target ports", the CE
+ uses a subset of GMPLS signaling to request the provider network to
+ establish an LSP to a target port.
+
+ For inter-CE connectivity, the CE originates a request that contains
+ the CPI of one of its ports that it wants to use for the LSP, and the
+ CPI of the target port. When the PE attached to the CE that
+ originated the request receives the request, the PE identifies the
+ appropriate PIT, and then uses the information in that PIT to find
+ out the PPI associated with the CPI of the target port carried in the
+ request. The PPI should be sufficient for the PE to establish an
+ LSP. Ultimately, the request reaches the CE associated with the
+ target CPI (note that the request still carries the CPI of the CE
+ that originated the request). If the CE associated with the target
+ CPI accepts the request, the LSP is established.
+
+ Note that a CE needs not establish an LSP to every target port that
+ the CE knows about, i.e., it is a local CE policy matter to select a
+ subset of target ports to which that CE will try to establish LSPs.
+
+ The procedures for establishing an individual connection between two
+ corresponding CEs is the same as the procedure specified for GMPLS
+ overlay [RFC4208].
+
+4.3.1. Signaling Procedures
+
+ When an ingress CE sends an RSVP Path message to an ingress PE, the
+ source IP address in the IP packet that carries the message is set to
+ the appropriate CE-CC-Addr, and the destination IP address in the
+ packet is set to the appropriate PE-CC-Addr. When the ingress PE
+ sends back to the ingress CE the corresponding Resv message, the
+ source IP address in the IP packet that carries the message is set to
+ the PE-CC-Addr, and the destination IP address is set to the CE-CC-
+ Addr.
+
+ Likewise, when an egress PE sends an RSVP Path message to an egress
+ CE, the source IP address in the IP packet that carries the message
+ is set to the appropriate PE-CC-Addr, and the destination IP address
+ in the packet is set to the appropriate CE-CC-Addr. When the egress
+ CE sends back to the egress PE the corresponding Resv message, the
+
+
+
+Fedyk, et al. Standards Track [Page 15]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ source IP address in the IP packet that carries the message is set to
+ the CE-CC-Addr, and the destination IP address is set to the PE-CC-
+ Addr.
+
+ In addition to being used for IP addresses in the IP packet that
+ carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr
+ are also used in the Next/Previous Hop Address field of the IF_ID
+ RSVP_Hop Object that is carried between CEs and PEs.
+
+ In the case where a link between CE and PE is a numbered non-bundled
+ link, the CPI and VPN-PPI of that link are used for the Type 1 or 2
+ TLVs of the IF_ID RSVP_Hop Object that is carried between the CE and
+ PE. In the case where a link between CE and PE is an unnumbered non-
+ bundled link, the CPI and VPN-PPI of that link are used for the IP
+ Address field of the Type 3 TLV. In the case where a link between CE
+ and PE is a bundled link, the CPI and VPN-PPI of that link are used
+ for the IP Address field of the Type 3 TLVs.
+
+ Additional processing related to unnumbered links is described in
+ Sections 3 ("Processing the IF_ID RSVP_HOP object") and 4.1
+ ("Unnumbered Forwarding Adjacencies") of RFC 3477 [RFC3477].
+
+ When an ingress CE originates a Path message to establish an LSP from
+ a particular port on that CE to a particular target port, the CE uses
+ the CPI of its port in the Sender Template object. If the CPI of the
+ target port is an IP address, then the CE uses it in the Session
+ object. And if the CPI of the target port is a <port index, IP
+ address> tuple, then the CE uses the IP address part of the tuple in
+ the Session object, and the whole tuple as the Unnumbered Interface
+ ID subobject in the Explicit Route Object (ERO).
+
+ There are two options for RSVP-TE sessions. One option is to have a
+ single RSVP-TE session end to end where the addresses of the customer
+ and the provider are swapped at the PE; this is termed shuffling.
+ The other option is when stitching or hierarchy is used to create two
+ LSP sessions, one between the provider PE(s) and another end-to-end
+ session between the CEs.
+
+4.3.1.1. Shuffling Sessions
+
+ Shuffling sessions are used when the desire is to have a single LSP
+ originating at the CE and terminating at the far end CE. The
+ customer addresses are shuffled to provider addresses at the ingress
+ PE, and back to customer addresses at the egress PE by using the
+ mapping provided by the PIT.
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 16]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ When the Path message arrives at the ingress PE, the PE selects the
+ PIT associated with the L1VPN, and then uses this PIT to map CPIs
+ carried in the Session and the Sender Template objects to the
+ appropriate PPIs. Once the mapping is done, the ingress PE replaces
+ CPIs with these PPIs. As a result, the Session and the Sender
+ Template objects that are carried in the GMPLS signaling within the
+ service provider network carry PPIs, and not CPIs.
+
+ At the egress PE, the reverse mapping operation is performed. The PE
+ extracts the ingress/egress PPI values carried in the Sender Template
+ and Session objects (respectively). The egress PE identifies the
+ appropriate PIT to find the appropriate CPI associated with the PPI
+ of the egress CE. Once the mapping is retrieved, the egress PE
+ replaces the ingress/egress PPI values with the corresponding CPI
+ values. As a result, the Session and the Sender Template objects
+ (included in the GMPLS RSVP-TE Path message sent from the egress PE
+ to the egress CE) carry CPIs, and not PPIs.
+
+ Here also, for the GMPLS RSVP-TE Path messages sent from the egress
+ PE to CE, the source IP address (of the IP packet carrying this
+ message) is set to the appropriate PE-CC-Addr, and the destination IP
+ address (of the IP packet carrying this message) is set to the
+ appropriate CE-CC-Addr.
+
+ At this point, the CE's view is a single LSP that is point-to-point
+ between the two CEs with a virtual link between the PE nodes:
+ CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP
+ segment in all its detail. The PEs MAY filter the RSVP-TE signaling,
+ i.e., remove information about the provider topology and replace it
+ with a view of a virtual link.
+
+ This translation of addresses and session IDs is termed shuffling and
+ is driven by the L1VPN Port Information Tables (see Section 4). This
+ MUST be performed for all RSVP-TE messages at the PE edges. In this
+ case, there is one CE-to-CE session.
+
+4.3.1.2. Stitched or Nested Sessions
+
+ Stitching or Nesting options are dependent on the LSP switching
+ types. If the CE-to-CE and PE-to-PE LSPs are identical in switching
+ type and capacity, the LSP MAY be stitched together and the
+ procedures in [RFC5150] apply. If the CE-to-CE LSPs and the PE-to-PE
+ LSPs are of not the same switching type, or are of different but
+ compatible capacity, the LSPs MAY be Nested and the procedures for
+ [RFC4206] apply. As both Stitched and Nested LSP signaling
+ procedures involve a PE-to-PE session establishment compatible with
+ CE session parameters, they are described together.
+
+
+
+
+Fedyk, et al. Standards Track [Page 17]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ When the Path Message arrives at the ingress PE, the PE selects the
+ PIT associated with the L1VPN, and then uses this PIT to map CPIs
+ carried in the Session and the Sender Template objects to the
+ appropriate PPIs. Once the mapping is done, a new PE-to-PE session
+ is established with the parameters compatible with the CE session.
+ Upon successful establishment of the PE-to-PE session, the CE
+ signaling request is sent to the egress PE.
+
+ At the ingress PE, when stitching and nesting are used, a PE-to-PE
+ session is established. This could be achieved by several means:
+
+ - Associating an already established PE-to-PE LSP or Forwarding
+ Adjacency LSP (FA-LSP) to the destination that meets the
+ requested parameters.
+
+ - Establishing a compliant PE-to-PE LSP segment.
+
+ At this point, the CE's view is a single LSP that is point-to-point
+ between the two CEs with a virtual node between the PE nodes:
+ CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP
+ segment in all its detail. The PEs do not have to filter the RSVP-TE
+ signaling by removing information about the provider topology because
+ the PE-to-PE signaling is not visible to the CE nodes.
+
+4.3.1.3 Other Signaling
+
+ An ingress PE may receive and potentially reject a Path message that
+ contains an Explicit Route Object and so cause the switched
+ connection setup to fail. However, the ingress PE may accept EROs,
+ which include a sequence of {<ingress PE (strict), egress CE CPI
+ (loose)>}.
+
+ - Path message without ERO: when an ingress PE receives a Path
+ message from an ingress CE that contains no ERO, it MUST calculate
+ a route to the destination for the PE-to-PE LSP and include that
+ route in an ERO, before forwarding the Path message. One exception
+ would be if the egress core node were also adjacent to this core
+ node.
+
+ - Path message with ERO: when an ingress PE receives a Path message
+ from an ingress CE that contains an ERO (of the form detailed
+ above), the former computes a path to reach the egress PE. It then
+ inserts this path as part of the ERO before forwarding the Path
+ message.
+
+ In the case of shuffling, the overlay rules for notification and RRO
+ processing are identical to the User-Network Intercase (UNI) or
+ Overlay Model [RFC4208], which state that Edge PE MAY remove/edit
+
+
+
+Fedyk, et al. Standards Track [Page 18]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+ Provider Notification and RRO objects when passing the messages to
+ the CEs.
+
+4.4. Recovery Procedures
+
+ Signaling:
+
+ A CE requests a network-protected LSP (i.e., an LSP that is protected
+ from PE-to-PE) by using the technique described in [RFC4873].
+ Dynamic identification of merge nodes is supported via the LSP
+ Segment Recovery Flags carried in the Protection object (see Section
+ 6.2 of [RFC4873]).
+
+ Notification:
+
+ A Notify Request object MAY be inserted in Path or Resv messages to
+ indicate the address of a CE that should be notified of an LSP
+ failure. Notifications MAY be requested in both the upstream and
+ downstream directions:
+
+ - Upstream notification is indicated via the inclusion of a Notify
+ Request object in the corresponding Path message.
+
+ - Downstream notification is indicated via the inclusion of a
+ Notify Request object in the corresponding Resv message.
+
+ A PE receiving a message containing a Notify Request object SHOULD
+ store the Notify Node Address in the corresponding RSVP state block.
+ The PE SHOULD also include a Notify Request object in the outgoing
+ Path or Resv message. The outgoing Notify Node Address MAY be
+ updated based on local policy. This means that a PE, upon receipt of
+ this object from the CE, MAY update the value of the Notify Node
+ Address.
+
+ If the ingress CE includes a Notify Request object into the Path
+ message, the ingress PE MAY replace the received 'Notify Node
+ Address' by its own selected 'Notify Node Address', and in particular
+ the local TE Router_ID. The Notify Request object MAY be carried in
+ Path or Resv messages (Section 7 of [RFC3473]). The format of the
+ Notify Request object is defined in [RFC3473]. Per Section 4.2.1 of
+ [RFC3473], Notify Node Addresses SHALL be set to either IPv4 or IPv6.
+
+ Inclusion of a Notify Request object is used to request the
+ generation of notifications upon failure occurrence but does not
+ guarantee that a Notify message will be generated.
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 19]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+5. Security Considerations
+
+ Security for L1VPNs is covered in [RFC4847] and [RFC5253]. In this
+ document, we discuss the security aspects with respect to the control
+ plane.
+
+ The association of a particular port with a particular L1VPN (or to
+ be more precise, with a particular PIT) is a configuration operation,
+ generally done manually by the service provider as part of the
+ service provisioning process. Thus, it cannot be altered via
+ signaling between CE and PE. This means that the signaling cannot be
+ used to deliver L1VPN traffic to the wrong customer. The operator
+ should apply appropriate security mechanisms to the management and
+ configuration process, and should consider data plane verification
+ techniques to protect against accidental misconfiguration. The
+ customer may also apply end-to-end (i.e., CE-to-CE) data plane
+ connectivity tests over the L1VPN connection to detect misconnection.
+ Data plane connectivity testing can be performed using the Link
+ Management Protocol (LMP) [RFC4204].
+
+ Note that it is also possible to populate the local part of a PIT
+ using auto-discovery through LMP. LMP may be secured as described in
+ [RFC4204]. Signaling between CE and PE is assumed to be over a
+ private link (for example, in-band or in-fiber) or a private network.
+ Use of a private link makes the CE-to-PE connection secure at the
+ same level as the data link described in the previous paragraphs.
+ The use of a private network assumes that entities outside the
+ network cannot spoof or modify control plane communications between
+ CE and PE. Furthermore, all entities in the private network are
+ assumed to be trusted. Thus, no security mechanisms are required by
+ the protocol exchanges described in this document.
+
+ However, an operator that is concerned about the security of their
+ private control plane network may use the authentication and
+ integrity functions available in RSVP-TE [RFC3473] or utilize IPsec
+ ([RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]) for the
+ point-to-point signaling between PE and CE. See [MPLS-SEC] for a
+ full discussion of the security options available for the GMPLS
+ control plane.
+
+ Note further that a private network (e.g., Layer 2 VPN or Layer 3
+ VPN) might be used to provide control plane connectivity between a PE
+ and more than one CE. In this scenario, it is RECOMMENDED that each
+ L1 VPN customer have its own such private network. Then, the
+ security mechanisms provided by the private network SHOULD be used to
+ ensure security of the control plane communication between a customer
+ and a service provider.
+
+
+
+
+Fedyk, et al. Standards Track [Page 20]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+ [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
+ in Resource ReSerVation Protocol - Traffic Engineering
+ (RSVP-TE)", RFC 3477, January 2003.
+
+ [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
+ Extensions in Support of Generalized Multi-Protocol Label
+ Switching (GMPLS)", RFC 4202, October 2005.
+
+ [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.
+
+ [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.
+
+ [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
+ "GMPLS Segment Recovery", RFC 4873, May 2007.
+
+ [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+ "Label Switched Path Stitching with Generalized
+ Multiprotocol Label Switching Traffic Engineering (GMPLS
+ TE)", RFC 5150, February 2008.
+
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 21]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+6.2. Informative References
+
+ [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
+ October 1994.
+
+ [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+ [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
+ in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
+
+ [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
+ Virtual Private Networks", RFC 4847, April 2007.
+
+ [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
+ Document Roadmap", RFC 2411, November 1998.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
+ 2005.
+
+ [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+ Protocol", RFC 4306, December 2005.
+
+ [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
+ Requirements for Encapsulating Security Payload (ESP) and
+ Authentication Header (AH)", RFC 4835, April 2007.
+
+ [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
+ Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
+
+ [RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-
+ Discovery", RFC 5252, July 2008.
+
+ [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
+ Virtual Private Network (L1VPN) Basic Mode", RFC 5253,
+ July 2008.
+
+ [MPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS
+ Networks", Work in Progress, February 2008.
+
+
+
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 22]
+
+RFC 5251 L1VPN Basic Mode July 2008
+
+
+7. Acknowledgments
+
+ The authors would like to thank Adrian Farrel, Hamid Ould-Brahim, and
+ Tomonori Takeda for their valuable comments.
+
+ Sandy Murphy, Charlie Kaufman, Pasi Eronen, Russ Housley, Tim Polk,
+ and Ron Bonica provided input during the IESG review process.
+
+Authors' Addresses
+
+ Don Fedyk
+ Nortel Networks
+ 600 Technology Park
+ Billerica, MA 01821
+ Phone: +1 (978) 288 3041
+ EMail: dwfedyk@nortel.com
+
+ Yakov Rekhter
+ Juniper Networks
+ 1194 N. Mathilda Avenue
+ Sunnyvale, CA 94089
+ EMail: yakov@juniper.net
+
+ Dimitri Papadimitriou
+ Alcatel-Lucent
+ Fr. Wellesplein 1,
+ B-2018 Antwerpen, Belgium
+ Phone: +32 3 240-8491
+ EMail: Dimitri.Papadimitriou@alcatel-lucent.be
+
+ Richard Rabbat
+ Google Inc.
+ 1600 Amphitheatre Pky
+ Mountain View, CA 95054
+ EMail: rabbat@alum.mit.edu
+
+ Lou Berger
+ LabN Consulting, LLC
+ Phone: +1 301-468-9228
+ EMail: lberger@labn.net
+
+
+
+
+
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 23]
+
+RFC 5251 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Fedyk, et al. Standards Track [Page 24]
+