Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc.
Expiration Date: April 2002
October 2001
Single-Sided Signaling for L2VPNs
draft-rosen-ppvpn-l2-signaling-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
[MARTINISIG] contains a proposal for using LDP [RFC 3036] to signal
point-to-point VCs (sometimes also known as "pseudowires") across an
MPLS network. However, that draft requires that each endpoint have
apriori knowledge of the IP address other endpoint, and that both
endpoints have apriori knowledge of a common VC identifier. As a
consequence, each VC needs to be provisioned at both endpoints. In
this draft, we extend the [MARTINISIG] signaling technique so as to
eliminate the requirement for apriori knowledge of a common VC
identifier, and to eliminate the requirment that each endpoint be
known to the other. We then show the signaling can then be used for
setting up a Transparent LAN Service [TLS1, TLS2] or a full-mesh of
point-to-point VCs.
Rosen [Page 1]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
Table of Contents
1 Specification of Requirements .......................... 2
2 Introduction ........................................... 2
3 Attachment Identifiers ................................. 4
4 Signaling .............................................. 6
5 Individual Point-to-Point VCs .......................... 7
6 Transparent LAN Service ................................ 8
7 Mesh of Point-to-Point VCs ............................. 8
8 IETF Sub-IP Area Positioning ........................... 8
9 Security Considerations ................................ 9
10 Acknowledgments ........................................ 9
11 References ............................................. 9
12 Author's Information ................................... 9
1. Specification of Requirements
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 RFC 2119
2. Introduction
In this paper we will use some terminology drawn from [L2VPN].
- Attachment VC: A VC (virtual circuit) connecting a CE (customer
edge) device to a PE (provider edge) device.
- Emulated VC: Sometimes also called a "pseudowire", a VC
connecting two attachment VCs.
In [MARTINISIG], an emulated VC consists of two LSPs (Label Switched
Paths), one in each direction. Each endpoint initiates the setup of
the LSP that carries packets in the "incoming" direction.
In order for the signaling to proceed, each endpoint has apriori
knowledge of (a) the address of the other endpoint, and (b) a VCid.
On a given emulated VC, the same VCid must be used for both LSPs.
In this context, "apriori knowledge" simply means information that
must be known prior to the initiation of signaling.
Rosen [Page 2]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
Each LSP is uniquely identified by the triple <transmitter,
responder, vcid>. (The VCid must be unique in the context of a
single LDP session between PE1 and PE2.) An emulated VC is a pair
of LSPs:
<PE1, PE2, VCid_x, VC_type_y>, <PE2, PE1, VCid_x, VC_type_y>
Each endpoint must also have apriori knowledge, for each Emulated VC,
of the local Attachment VC to which that Emulated VC is to be bound.
Unfortunately, this requires that PE1 and PE2 be explicitly
provisioned with the elements of these tuples; there does not seem to
be any way to provide an auto-discovery mechanism which eliminates
the need to provision the VCid at both endpoints, or which eliminates
the need for each endpoint to have apriori knowledge of the other's
IP address. Essentially this means that each Emulated VC must be
individually provisioned in both of its endpoint PEs.
The purpose of this paper is to extend the signaling of [MARTINISIG]
so that the need for this provisioning is eliminated. In particular,
we would like to be able to set up an Emulated VC while requiring
that only ONE endpoint need have apriori knowledge of the IP address
of the other. (Note that if one endpoint has no apriori knowledge of
the other, it CANNOT have apriori knowledge of a VCid that the other
will use for a particular Emulated VC; if one doesn't know the other
endpoint, one cannot be sure that the VCid is unique in the context
of an LDP session to that endpoint.) There may be some identifier of
which both endpoints need to have apriori knowledge (e.g., a VPN-id,
or a VLAN identifier), but this will not be the identifier of any
individual VC.
The procedures described herein, together with an auto-discovery
procedure, will enable signaling to proceed without requiring either
endpoint to be provisioned even with the address of the other
endpoint, as the latter may be provided through the auto-discovery
procedure.
We do not specify an auto-discovery procedure in this draft, but we
do specify the information which needs to be obtained via auto-
discovery in order for the signaling procedures to begin.
(Note that although the need to provision each individual Emulated VC
at both endpoints is eliminated, it may still be necessary to
provision the Attachment VCs. If, e.g,. the Attachment VCs pass
through a switched network, elimination of the provisioning step for
them is impossible.)
We will still require that each endpoint have apriori knowledge, for
Rosen [Page 3]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
each of its Attachment VCs, that that circuit is to be bound to an
Emulated VC, but we will not require that there be apriori knowledge
of which Emulated VC is bound to which Attachment VC.
In [MARTINISIG], the VCid is used for two purposes:
- to indicate that a given Emulated VC is bound to a given
Attachment VC (i.e., the Attachment VC is configured with the
VCid and remote PE address);
- to indicate in LDP signaling that a given LSP in one direction is
part of the same VC as a given LSP in the other direction.
So it is necessary to have another means of achieving these
functions.
Note that although this draft is entitled "Single-sided signalling",
that is really something of a misnomer, as both endpoints do
participate in the signaling . A more accurate title would be
"Signalling Based on the Existence of Apriori Knowledge at only One
Endpoint".
3. Attachment Identifiers
We propose to extend [MARTINISIG] by adding a new FEC type which,
instead of having a VCid, has the following identification fields:
- Target Attachment Identifier (TAI);
- Source Attachment Identifier (SAI);
- Attachment Group Identifier (AGI).
Each Attachment VC will be configured with an Attachment Identifier
and/or with an Attachment Group Identifier.
An Attachment Identifier is unique in the context of a single
PE, but different PEs may use different AIs for different things.
An Attachment Identifier may be used, at a given PE, to identify:
- A single Attachment VC, e.g., corresponding to an ATM VPI/VCI.
This is how it would be used when setting up individual point-
to-point VCs, as is done in [MARTINISIG].
Rosen [Page 4]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
- A pool of Attachment VCs, e.g., corresponding to a set of
Attachment VCs which connect the PE to a particular CE. This is
how it would be used when one wants to have a VC going from CE1
(at PE1) to CE2 (at PE2), but one doesn't care which CE1-PE1
connection gets bound to which CE2-PE2 connection.
- A virtual Attachment VC, e.g., corresponding to an ethernet
switching function for a particular VLAN. This is how it would
be used when providing a transparent LAN service, in which a set
of Virtual Switches for a particular VLAN have to be meshed via
point-to-point VCs.
An Attachment Group Identifier may be thought of as a VPN-id, or
a VLAN identifier, some attribute which is shared by all the
Attachment VCs (or pools thereof) which are allowed to be connected.
The intention is that an LSP will now be identified by:
<PE1, AI1, PE2, AI2>,
the LSP in the opposite direction will be identified by:
<PE2, AI2, PE1, AI1>,
and an Emulated VC is a pair of such LSPs.
When a signaling message is sent from PE1 to PE2, and PE1 needs to
refer to an Attachment Identifier which has been configured on
one of its own Attachment VCs (or pools), the Attachment
Identifier is called a "Source Attachment Identifier". If PE1
needs to refer to an Attachment Identifier which has been
configured on one of PE2's Attachment VCs (or pools), the
Attachment Identifier is called a "Target Attachment Identifier".
(So an SAI at one endpoint is a TAI at the remote endpoint, and vice
versa.)
The intention is that the PE which receives a Label Mapping
Message containing a TAI will be able to map that TAI uniquely
to one of its Attachment VCs (or pools). The way in which a
PE maps a TAI to an Attachment VC (or pool) should be a
local matter. So as far as the signaling procedures are
concerned, the TAI is really just an arbitrary string of bytes, a
"cookie".
When an Attachment VC or pool is provisioned, it is configured
with an Attachment Identifier, or an Attachment Group Identifier, or
both.
Rosen [Page 5]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
4. Signaling
In order for PE1 to begin signaling PE2, PE1 must know the address
of the remote PE2, and a TAI. While this information may be
configured at PE1, it is expected that it would be learned
dynamically via some autodiscovery procedure. To PE1, the auto-
discovery process is a function which maps from an AGI to a set of
<PE, AI> pairs.
To begin the signaling procedure, a PE (PE1) that has knowledge of
the other endpoint (PE2) initiates the setup of the LSP in the
incoming (PE2-->PE1) direction by sending a Label Mapping message
containing the new FEC type. The FEC type includes the following:
- SAI
- AGI, if one has been configured.
- TAI (SAI at the remote PE).
What happens when PE2 receives such a Label Mapping message?
First, PE2 interprets the TAI. Exactly how PE2 does this mapping is
a local matter. The TAI might, e.g., be a string which
identifies a particular Attachment VC, such as "ATM3VPI4VCI5", or
it might, e.g., be a string such as "Fred" which is associated by
configuration with a particular Attachment VC.
If PE2 cannot map the TAI to anything, then PE2 sends a Label
Release message to PE1, with a Status Code meaning "invalid TAI", and
the processing of the Mapping message is complete.
If the TAI maps to an Attachment VC (or pool) which is NOT
configured with the same AGI that is specified in the Label Mapping
message, a corresponding Label Release message, with a Status Code
meaning "no AGI in common" is sent to PE1, and the processing of the
Mapping message is complete.
The AGI of an Attachment VC (or pool) and the Label Mapping
Message's AGI are considered to be the same if and only if:
- The Attachment VC or pool is configured with an AGI, and that
same AGI occurs in the message, and
- The Attachment VC or pool is not configured with an AGI, no AGI
occurs in the message.
If the TAI maps to a single Attachment VC, and that Attachment VC is
Rosen [Page 6]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
already bound to an Emulated VC (including the case where only one
of the two LSPs currently exists), and the remote endpoint is not
PE1, then PE2 sends a Label Release message to PE1, with a
Status Code meaning "Attachment VC bound to different PE", and
the processing of the Mapping message is complete.
If the TAI maps to a single Attachment VC, and that Attachment VC is
already bound to an Emulated VC (including the case where only one
of the two LSPs currently exists, but the AI at PE1 is different
than that specified in the SAI field of the Mapping message, then
PE2 sends a Label Release message to PE1, with a Status Code
meaning "Attachment VC bound to different remote Attachment VC",
and the processing of the Mapping message is complete.
If the TAI maps to a pool of Attachment VCs, and there is already an
Emulated VC connecting an Attachment VC in that pool to an Attachment
VC at PE1, and the AI at PE1 of that Emulated VC is the same as the
SAI of the Label Mapping message, then PE2 sends a Label Release
message to PE1, with a Status Code meaning "Attachment VC bound to
different remote Attachment VC", and the processing of the Mapping
message is complete.
If PE2 is still processing the Label Mapping message at this point,
then it accepts the label (provided of course that there are no
"standard" LDP errors). Then it has to make sure that an LSP is set
up in the opposite (PE1-->PE2) direction. If it has already signaled
for an LSP in that direction, nothing more need be done. Otherwise,
it must initiate such signaling by sending a Label Mapping message to
PE1. This is very similar to the Label Mapping message PE2 received,
but with the SAI and TAI reversed.
5. Individual Point-to-Point VCs
One model of operation which the above procedures can support is the
following. Each PE is configured with the necessary set of
Attachment VCs, and each Attachment VC is configured with a VPN-id, a
local name (which is unique relative to the VPN-id), and a remote
name. The intent is that the local Attachment VC is supposed to be
connected to the remote Attachment VC with the specified remote name.
As part of an auto-discovery procedure, each PE advertises its <VPN-
id, local name> pairs. Each PE compares its local <VPN-id, remote
name> pairs with the <VPN-id, local name> pairs advertised by the
other PEs. If PE1 has a local <VPN-id, remote name> pair with value
<V, fred>, and PE2 has a local <VPN-id, local name> pair with value
<V, fred>, PE1 will thus be able to discover that it needs to connect
to PE2, and will use "fred" as the TAI. The SAI is not used.
Rosen [Page 7]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
In this model of operation, the Attachment VCs and the Emulated VCs
are point-to-point. The primary benefit of this model of operation
is that it enables you to move an Attachment VC from one PE to
another without having to reconfigure the remote endpoint.
6. Transparent LAN Service
In another model of operation, the Attachment VCs can be though of as
VLAN interfaces which attach to "virtual LAN switches". In this
case, the AI identifies a virtual LAN switch, which would correspond
to a particular VLAN in a particular VPN. We allow a single Emulated
VC between any pair of Virtual LAN switches.
The auto-discovery procedure for this model of operation would have
each PE advertise a name for each of its virtual LAN switches.
Probably all the virtual LAN switches that correspond to the same
VLAN would have the same name, which might be constructed from a
VPN-id and a VLAN number. These names would be used as the AIs.
7. Mesh of Point-to-Point VCs
In a third model of operation, each PE may contain several
pools of Attachment VCs, each pool associated with a particular
VPN. A PE may contain multiple pools per VPN, as each pool may
correspond to a particular CE device. It may be desired to create
one Emulated VC between each pair of pools that are in the same VPN;
the result would be to create a full mesh of CE-CE VCs for each VPN.
The auto-discovery procedure for this model of operation would have
each PE advertise the set of pools it has, associating each with
a VPN-id and a name. When a PE sends a Label Mapping message to
set up a VC between two pools, the local pool name is carried as the
SAI and the remote pool name as the TAI. The AGI would be an
encoding of the VPN-id.
8. IETF Sub-IP Area Positioning
This draft is targeted at both the PPVPN WG and the MPLS WG. It
appears to be in the province of the PPVPN WG to consider the
requirements of signaling to support layer 2 VPNs. Specification in
detail of the actual extensions to LDP would appear to be the
province of the MPLS WG.
Rosen [Page 8]
Internet Draft draft-rosen-ppvpn-l2-signaling.txt-00.txt October 2001
9. Security Considerations
The signaling procedures specified herein require that a node
initiate and/or accept LDP sessions with entities that are not
necessarily directly connected to that node. It would be advisable
for a given node to use access control to restrict the set of nodes
that can set up LDP sessions with it, and it would be advisable to
use some form of authentication to guarantee that the remote endpoint
of an LDP session is the entity that it claims to be. Using the TCP
MD5 option may be adequate, or alternatively IPsec can be used.
10. Acknowledgments
Thanks to Dan Tappan and Ted Qian for their comments.
11. References
[L2VPN] "An Architecture for L2VPNs", Rosen et. al., draft-ietf-
ppvpn-l2vpn-00.txt, July 2001.
[MARTINISIG] "Transport of Layer 2 Frames Over MPLS", Martini et.
al., draft-martini-l2circuit-trans-mpls-07.txt, July 2001.
[RFC3036] "LDP Specification", Jaunuary 2001.
[TLS1] "Virtual Private Switched Network Services over an MPLS
Network", V. Kompella, et. al., draft-vkompella-ppvpn-vpsn-mpls-
00.txt, July 2001.
[TLS2] "Transparent VLAN Services over MPLS", Laserre, et. al.,
draft-lasserre-tls-mpls-00.txt, July 2001.
12. Author's Information
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com
Rosen [Page 9]