Internet Working Group Don Fedyk
Internet Draft Nortel
Expiration Date: March 2006 Yakov Rekhter
Juniper Networks
(Editors)
October 2005
Layer 1 VPN Basic Mode
draft-fedyk-l1vpn-basic-mode-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or
she becomes aware will be disclosed, in accordance with Section
6 of BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Abstract
This draft describes the basic mode of Layer 1 VPNs (L1VPN BM)
that is port based VPNs. In L1VPN BM, the basic unit of service
is a Label Switched Path (LSP) between a pair of customer ports
within a given VPN port-topology. This draft defines the
operational model using either provisioning or a VPN auto-
discovery mechanism and the signaling extensions for the L1VPN
BM. This draft uses BGP as an example of the auto-discovery
mechanism.
Fedyk, Rekhter [Page 1]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
Table of Contents
1. Introduction..................................................2
2. Layer 1 VPN Services..........................................3
3. Addressing, Ports, Links and Control Channels.................5
3.1 Service Provider Realm.......................................6
3.2 Layer 1 Ports and Index......................................6
3.3 Port and Index Mapping.......................................7
4. Port Based L1VPN Basic Mode...................................8
4.1 L1VPN Port Information Tables................................9
4.2 CE to CE LSP Establishment..................................10
4.3 Signaling...................................................11
4.3.1 Signaling Procedures......................................12
5. Security Considerations......................................14
6. IANA Considerations..........................................14
7. Intellectual Property Considerations.........................14
8. References...................................................15
8.1 Normative References........................................15
8.2 Informative References......................................15
9. Author's Addresses...........................................16
10. Disclaimer of Validity......................................17
11. Full Copyright Statement....................................17
1. Introduction
In this document, we consider a service provider network that
consists of devices that support GMPLS (e.g., Lambda Switch
Capable devices, Optical Cross Connect, SDH Cross Connect,
etc.). We partition these devices into P (provider) and PE
(provider edge) devices. In the context of this document we'll
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 provider network (either Ps, or PEs),
as well as to the devices outside of the provider network.
We'll refer to such other devices as Client Edge Devices (CEs).
An example of a CE would be a router, an SDH cross-connect, or
an Ethernet switch.
The [GMPLS-OVERLAY] draft is the basis for signaling from the
CE to the PE. In the [GMPLS-OVERLAY] draft the terms Core Node
(CN) and Edge Node (EN) correspond to PE and CE respectively.
Fedyk & Rekhter. [Page 2]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
+---+ +---+
| P | | P |
+---+ +---+
PE / \ PE
+-----+ +-----+ +--+
| | | |----| |
+--+ | | | | |CE|
|CE|----+-----+ | |----| |
+--+\ | | | +--+
\ +-----+ | |
\ | | | | +--+
\| | | |----|CE|
+-----+ +-----+ +--+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Generalized Layer 1 VPN Reference Model
This draft specifies how the L1VPN Basic Mode (BM) service can
be realized using VPN auto-discovery and Generalized Multi-
Protocol Label Switching (GMPLS)Signaling [GMPLS-RSVP-TE],
Routing [GMPLS-Routing] and LMP [GMPLS-LMP] mechanisms. The
L1VPN auto-discovery has similar requirements to the L3VPNs
auto-discovery [L3VPN-REQ]. As with L3VPNs there are protocol
options to be made with auto-discovery. For illustration
purposes BGP is used as a protocol example but other protocols
or methods of VPN distribution may be equally well suited.
GMPLS routing and signaling are used without extensions within
the provider network to establish and maintain Lambda Switch
Capable (LSC) or SONET/SDH (TDM) connections between provider
nodes. This follows the model in [GMPLS-Overlay]. LMP can be
used to automate link discovery and augment routing as well as
failure handling capabilities.
2. Layer 1 VPN Services
Layer 1 services on the interfaces of customer and provider
ports could be any of the L1 interfaces supported by GMPLS.
Since the mechanisms specified here use GMPLS as the signaling
mechanism, and since GMPLS applies to both SONET/SDH (TDM) and
Lambda Switch Capable (LSC) interfaces, it results that L1VPN
services includes but is not restricted to Lambda Switch
Capable or TDM based equipment. Note that this document
describes Basic Mode L1 VPNs and as such assumes that (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 RSVP-TE is used not
just as a signaling mechanism, but also as a routing mechanism
within the provider network. Basic Mode L1 VPNs do not assume
Fedyk & Rekhter. [Page 3]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
for GMPLS Routing on the CE-PE link since outside the scope of
a basic mode of operation.
A CE is connected to a PE via one or more links. In the context
of this document a link is the same as a GMPLS Traffic
Engineering (TE) link construct, as defined in [GMPLS-ROUTING].
In the context of this document a 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 could be any of the interfaces that are
supported by GMPLS. Likewise, CEs and PEs could be any devices
that are supported by GMPLS (e.g., optical cross connects, SDH
cross-connects, LSRs, etc).
Each 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 we assume that all the channels
within a given link have shared similar characteristics (e.g.,
switching capabilities, encoding, type, etc_), and can 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 link between a given CE PE pair. A
CE may be connected to more than one PE (with at least one port
per each PE). And, of course, a PE may have more than one CE
from different VPNs connected to it.
If a CE is connected to a PE via multiple links and all these
links belong to the same VPN, then for the purpose of this
document these links could be treated as a single link using
the link bundling constructs [LINK-BUNDLING].
A link may have only data bearing channels, or only control
bearing channels, or both. For the purpose of this discussion
we assume 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 there is IP reachbility
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. In the context of this document we'll refer 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 (e.g., capabilities, encoding,
etc_), and can be interchanged from the CEs point of view. Just
like links, in the context of this document, ports are logical
construct that are used to represent grouping of physical
Fedyk & Rekhter. [Page 4]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
resources on a per L1VPN basis that are used to connect a CE to
a PE.
At any given 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 defined by
provisioning the relationship on the provider devices. In other
words the context of a VPN membership in Basic mode is enforced
by service provider control.
This document assumes that the interface between the CE and PE
used for the purpose of signaling is capable to
initiate/process GMPLS protocols messages [GMPLS-RSVP-TE] and
follows the procedures described in [GMPLS-OVERLAY].
An important goal of L1VPN services (particularly with respect
to basic mode services) is the ability to support what is known
as "single end provisioning", where the addition of a new port
to a given L1VPN would involve 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. In L1VPN BM a CE
device could be provisioned with the corresponding port
information in much the same manner an overlay service is
provisioned today.
Another important goal in the L1VPN service is the ability to
establish/terminate an LSP between a pair of (existing) ports
within a L1VPN from the CE devices without involving
configuration changes in any of the provider's devices. In
other words, the VPN topology is under the CE device control.
The mechanisms outlined in this document aim at achieving these
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, (2) enable a CE to establish the actual LSP to a
subset of ports. Finally, the mechanisms allow arbitrary L1VPN
topologies to be supported ranging from hub-and-spoke to full
mesh point to point connections. Other more advanced service and
topology support such as point to multi point (P2MP) services
etc. is for further study.
The L1VPN BM draft does not specify the exchange of CE routing
or topology information to the provider. This type of
information is not precluded from the architecture but is
beyond the scope of this document.
3. Addressing, Ports, Links and Control Channels
Fedyk & Rekhter. [Page 5]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
GMPLS established conventions for Addressing and link numbering
are discussed in the [GMPLS-Arch] documents. This section
builds on those definitions for the L1VPN case where we now
have Customer and Provider addresses in a Layer 1 Context.
3.1 Service Provider Realm
This document assumes 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.
This document further assumes that each L1VPN customer has its
own addressing realm. We will refer to such realms as the
customer addressing realms. Customer addressing realms may
overlap with each other, and may also overlap with the service
provider addressing 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
assigned 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 not limited
to IPv4, IPv6, and NSAP. Note that NSAP addresses may be
carried in IPv6 Fields as specified in [NSAP-IPv6]. This
identifier is part of the 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 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 IP address> as a port identifier within the provider
network. Another way to construct such an identifier is to
assign an IP address that is unique within the service provider
addressing realm to each such port. Either way, this IP address
is internal to the service provider network and is used for
GMPLS signaling within the service provider network.
Fedyk & Rekhter. [Page 6]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
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 assumes 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.
For L1VPNs it is a requirement that provider operations are
independent of the VPN customers addressing realm and the
provider addressing realm is hidden from the customer. To
achieve this we have created two identifies, one customer
facing and the other 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 provider's addressing realm and the latter
from a VPN customer's addressing realm). If for a given port on
a PE, the PPI and the VPN-PPI are both 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.
+----+ +----+
| |<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, IPv6 or NSAP addresses.
Fedyk & Rekhter. [Page 7]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
For a given link connecting a CE to a PE, if the CPI is an IP
address, then the VPN-PPI has to be an IP address as well. And
if the CPI is an <port index, CPI IP address>, then the VPN-PPI
must be a <port index, PE IP address>. However, for a given
port on PE, whether the VPN-PPI of that port is an IP address
or a <port index, PE IP address> is independent of whether the
PPI of that port is an IP address or a <port index, PE IP
address>.
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 . 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 could assign such addresses on its
own, without any coordination with other L1VPNs. This document
also assumes that there is an IP control channel between the CE
and the PE. This channel could be either a single IP hop, or a
tunnel (GRE or IP-in-IP) or an IP private network, or even an
IP VPN for example. 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 are 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
over this single port.
In the L1VPN, the service provider does not initiate the
creation of an LSP between a pair of PE ports. This is done
Fedyk & Rekhter. [Page 8]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
rather by the CEs, which attach to the ports. However, the SP,
by using the mechanisms/toolkit outlined in this document,
restricts the set of other PE 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
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. A PIT 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 || BGP route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| 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
A PIT may be populated entirely by provisioning. This allows
the PE to PE ports to be connected on demand. This means that
the table entries are provisioned either on each PE box for
each corresponding L1VPN or on a provisioning system in the
provider control. This may or may not mean that CE addresses
are entered multiple times on multiple PEs. As the network
grows some form of automation is desirable.
Fedyk & Rekhter. [Page 9]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
The PIT is by nature VPN-specific in that entries for a L1VPN
are only required on a PE if that PE locally supports that
L1VPN by having CEs belonging to that VPN attached to the PE.
However, the full set of PITs with all L1VPN entries for
multiple VPNs may also be available to all PEs.
Another option is to have an auto-discovery mechanism; for
example BGP Auto-discovery could be modified for L1VPN. L1VPN
auto-discovery has the advantage of reducing the configuration
for L1VPNs which could be desirable in large VPNs.
A PIT on a given PE is populated from two sources:
1. The information related to the CEs' ports attached to the
ports on that PE (this information could be optionally
received from the CEs, however in Basic Mode we assume
this information is provisioned.) Beyond Basic Mode this
information could be discovered by several mechanism such
as LMP, IGPs or BGP.
2. The information received from other PEs. This is the
information that is auto-discovered within the Provider
Network.
We'll refer to the former as the "local" information, and to
the latter as the "remote" information.
A way to propagate this local information to other PEs is by
using BGP VPN auto-discovery procedures, as specified in [BGP-
VPN-AUTODISCOVERY]. In this case to restrict the flow of this
information to only the PITs within a given L1VPN, we use BGP
route filtering based on the Route Target Extended Community
[BGP-COMM], as follows:
Each PIT on a PE is configured with one or more Route Target
Communities, called "Export Route Targets" that are used to tag
the local information when it is exported into provider's BGP.
The granularity of such tagging could be as fine as a single
<CPI, PPI> pair. In addition, each PIT on a PE is configured
with one or more Route Target Communities, called "Import Route
Targets". Import Route Targets restrict the set of routes that
could be imported from the provider's BGP into the PIT to only
those routes that include at least one of these Communities.
When a service provider adds a new L1VPN port to a particular
PE, this port is associated at provisioning time with a PIT on
that PE, and this PIT is associated (again at provisioning
time) with that L1VPN.
For the purpose of L1VPN BM the CE only knows the local CPI
addresses and the remote CPI Addresses.
4.2 CE to CE LSP Establishment
Fedyk & Rekhter. [Page 10]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
In order to establish an LSP, a CE needs to identify all other
CEs in the CE's L1VPN 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-PE link, in addition to their
CPI and PPI may also have other information 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 RSOH 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 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 request originated by the CE
contains the CPI of the port on the CE that CE 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 need not establish an LSP to every target port
that CE knows about - it is a local CE matter to select a
Fedyk & Rekhter. [Page 11]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
subset of target ports to which the 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. [GMPLS-OVERLAY]
4.3.1 Signaling Procedures
When a CE sends an RSVP Path message to a 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 PE sends
back to the 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 a PE sends an RSVP Path message to a 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 CE sends back to the PE the corresponding Resv
message, the 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.
When a 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 ERO. When the Path
message arrives at the ingress PE, the PE selects the PIT
Fedyk & Rekhter. [Page 12]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
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 PE performs the reverse mapping - it maps
PPIs carried in the Session and the Sender Template object into
the appropriate CPIs, and then sends the Path message to the CE
that has the target port.
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 out 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.
When the Path message reaches the egress CE, and gets
processed, the latter initiates towards the egress PE the
exchange of the Resv message. Here, the FILTER_SPEC object is
process similarly to the SENDER_TEMPLATE object. Both egress
and ingress PE (in sequence), performs the same mapping
operation as with the corresponding Path message. Once the Resv
message reaches the ingress CE, the switched connection is
established.
An ingress PE may receive and potentially reject a Path message
that contains ERO (Explicit Route Object), or ERO 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 a 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 to reach
the egress PE. It then inserts this path as part of the ERO
before forwarding the Path message.
Fedyk & Rekhter. [Page 13]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
An ingress or an egress PE may include an RECORD_ROUTE object
and remove/filter the RRO from the received Path message before
forwarding it. Further an egress or an ingress PE may
remove/filter the RRO from a Resv message before forwarding it.
Filtering a RRO consist in editing its content and include only
the subobjects based on a local or global policy. This allows
the ingress/egress CE to be aware of the selected link and
labels on the egress/ingress CE side, respectively, for the
switched connections constituting this L1VPN.
The exact format of the extensions is TBD in a future revision.
5. Security Considerations
Since association of a particular port with a particular L1VPN
(or to be more precise with a particular PIT) is done by the
service provider as part of the service provisioning process
(and thus can't be altered via signaling between CE and PE),
and since signaling between CE and PE is assumed to be over a
private network (and thus can't be spoofed by entities outside
the private network), the solution described in this document
doesn't require authentication in signaling.
6. IANA Considerations
This document makes no requests for IANA action.
7. Intellectual Property Considerations
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
Fedyk & Rekhter. [Page 14]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
8. References
8.1 Normative References
[L1VPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service
Requirements for Optical Virtual Private Networks", work in
progress.
[GMPLS-OVERLAY] Swallow, G., et al., "Generalized Multiprotocol
Label Switching(GMPLS)User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) Support
for the Overlay Model", work in progress.
8.2 Informative References
[GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS -
Signaling Functional Description", January 2003, RFC3471.
[GMPLS-RSVP-TE] Berger, L. (editor), "Generalized MPLS
Signaling - RSVP-TE Extensions", RFC3473, January 2003.
[GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions
in Support of Generalized MPLS", work in progress
[GMPLS-HIERARCHY] Kompella, K., Rekhter, Y., "LSP Hierarchy
with Generalized MPLS TE", work in progress.
[GMPLS-ARCH] Mannie, E. (Editor), "Generalized Multi-protocol
Label Switching Architecture," RFC3945, October 2004.
[LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link
Bundling in MPLS Traffic Engineering", work in progress.
[BGP-VPN-AUTODISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter,
Y., "Using BGP as an Auto-Discovery Mechanism for Layer-3
and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt,
work in progress
[GMPLS-LMP] J.P.Lang (Editor), "Link Management Protocol,"
draft-ietf-ccamp-lmp-10.txt, October 2003.
[NSAP-IPV6] Carpenter, B. et al., "OSI NSAPs and IPv6", RFC
1888, August 1996.
[L3VPN-REQ] A. Nagarajan, "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)" RFC 3809, June
2004.
Fedyk & Rekhter. [Page 15]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
9. Acknowledgments
The authors would like to thank Adrian Farrel, Hamid Ould-
Brahim for their valuable comments.
9. Author's Addresses
Don Fedyk
Nortel Networks
600 Technology Park
Billerica, Massachusetts
01821 U.S.A
Phone: +1 (978) 288 3041
Email: dwfedyk2nortelnetworks.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
Email: yakov@juniper.net
Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Richard Rabbat
Fujitsu
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
Email: richard@us.fujitsu.com
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
Email: lberger@movaz.com
Fedyk & Rekhter. [Page 16]
Internet Draft draft-fedyk-l1vpn-basic-mode-00.txt Oct. 2005
10. Disclaimer of Validity
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 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.
11. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Fedyk & Rekhter. [Page 17]