draft-ietf-l2vpn-signaling-03.txt   draft-ietf-l2vpn-signaling-04.txt 
Network Working Group E. Rosen Network Working Group E. Rosen
Internet-Draft W. Luo Internet-Draft W. Luo
Expires: August 23, 2005 B. Davie Expires: January 19, 2006 B. Davie
Cisco Systems, Inc. Cisco Systems, Inc.
V. Radoaca V. Radoaca
Nortel Networks Nortel Networks
February 19, 2005 July 18, 2005
Provisioning Models and Endpoint Identifiers in L2VPN Signaling Provisioning Models and Endpoint Identifiers in L2VPN Signaling
draft-ietf-l2vpn-signaling-03.txt draft-ietf-l2vpn-signaling-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
There are a number of different kinds of "Provider Provisioned Layer There are a number of different kinds of "Provider Provisioned Layer
2 VPNs" (L2VPNs). The different kinds of L2VPN may have different 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different
"provisioning models", i.e., different models for what information "provisioning models", i.e., different models for what information
skipping to change at page 3, line 7 skipping to change at page 3, line 7
required by each provisioning model. It discusses the way in which required by each provisioning model. It discusses the way in which
the endpoint identifiers are distributed by the discovery process, the endpoint identifiers are distributed by the discovery process,
especially when the discovery process is based upon the Border especially when the discovery process is based upon the Border
Gateway Protocol (BGP). It then specifies how the endpoint Gateway Protocol (BGP). It then specifies how the endpoint
identifiers are carried in the two signaling protocols that are used identifiers are carried in the two signaling protocols that are used
to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2
Tunneling Protocol (L2TPv3). Tunneling Protocol (L2TPv3).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 6 2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 7
2.1 Endpoint Identification . . . . . . . . . . . . . . . . . 6 2.1 Endpoint Identification . . . . . . . . . . . . . . . . . 7
2.2 Creating a Single Bidirectional Pseudowire . . . . . . . . 7 2.2 Creating a Single Bidirectional Pseudowire . . . . . . . . 8
2.3 Attachment Identifiers and Forwarders . . . . . . . . . . 8 2.3 Attachment Identifiers and Forwarders . . . . . . . . . . 9
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Individual Point-to-Point VCs . . . . . . . . . . . . . . 10 3.1 Individual Point-to-Point VCs . . . . . . . . . . . . . . 11
3.1.1 Provisioning Models . . . . . . . . . . . . . . . . . 10 3.1.1 Provisioning Models . . . . . . . . . . . . . . . . . 11
3.1.1.1 Double Sided Provisioning . . . . . . . . . . . . 10 3.1.1.1 Double Sided Provisioning . . . . . . . . . . . . 11
3.1.1.2 Single Sided Provisioning with Discovery . . . . . 10 3.1.1.2 Single Sided Provisioning with Discovery . . . . . 11
3.1.2 Signaling . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2 Signaling . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Virtual Private LAN Service . . . . . . . . . . . . . . . 12 3.2 Virtual Private LAN Service . . . . . . . . . . . . . . . 13
3.2.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 12 3.2.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 13
3.2.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 12 3.2.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 14
3.2.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 15
3.2.4 Pseudowires as VPLS Attachment Circuits . . . . . . . 14 3.2.4 Pseudowires as VPLS Attachment Circuits . . . . . . . 16
3.3 Colored Pools: Full Mesh of Point-to-Point VCs . . . . . . 14 3.3 Colored Pools: Full Mesh of Point-to-Point VCs . . . . . . 16
3.3.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 15 3.3.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 16
3.3.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 15 3.3.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17
3.3.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 15 3.3.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 17
3.3.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 16 3.3.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 17 3.4 Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 19
3.5 Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 17 3.5 Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 19
3.5.1 Signaling . . . . . . . . . . . . . . . . . . . . . . 18 3.5.1 Signaling . . . . . . . . . . . . . . . . . . . . . . 21
3.5.2 Provisioning and Discovery . . . . . . . . . . . . . . 20 3.5.2 Provisioning and Discovery . . . . . . . . . . . . . . 23
3.5.3 Non-distributed VPLS as a sub-case . . . . . . . . . . 20 3.5.3 Non-distributed VPLS as a sub-case . . . . . . . . . . 23
3.5.4 Splicing and the Data Plane . . . . . . . . . . . . . 21 3.5.4 Splicing and the Data Plane . . . . . . . . . . . . . 23
4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 22 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 22 4.1 Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 25
4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire 4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire
Switching . . . . . . . . . . . . . . . . . . . . . . . . 22 Switching . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Inter-Provider Application of Dist. VPLS Signaling . . . . 23 4.3 Inter-Provider Application of Dist. VPLS Signaling . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 8. Normative References . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 29 9. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 35
1. Introduction 1. Introduction
[L2VPN-FW] describes a number of different ways in which sets of [L2VPN-FW] describes a number of different ways in which sets of
pseudowires may be combined together into "Provider Provisioned Layer pseudowires may be combined together into "Provider Provisioned Layer
2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different
kinds of L2VPN. Different kinds of L2VPN may have different kinds of L2VPN. Different kinds of L2VPN may have different
"provisioning models", i.e., different models for what information "provisioning models", i.e., different models for what information
needs to be configured in what entities. Once configured, the needs to be configured in what entities. Once configured, the
provisioning information is distributed by a "discovery process", and provisioning information is distributed by a "discovery process", and
skipping to change at page 4, line 25 skipping to change at page 5, line 25
automatically invoked to set up the required pseudowires. The automatically invoked to set up the required pseudowires. The
semantics of the endpoint identifiers which the signaling protocol semantics of the endpoint identifiers which the signaling protocol
uses for a particular type of L2VPN are determined by the uses for a particular type of L2VPN are determined by the
provisioning model. That is, different kinds of L2VPN, with provisioning model. That is, different kinds of L2VPN, with
different provisioning models, require different kinds of endpoint different provisioning models, require different kinds of endpoint
identifiers. This document specifies a number of PPVPN provisioning identifiers. This document specifies a number of PPVPN provisioning
models, and specifies the semantic structure of the endpoint models, and specifies the semantic structure of the endpoint
identifiers required for each provisioning model. identifiers required for each provisioning model.
Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or
L2TP version 3 (as specified in [L2TP-BASE] and extended in L2TP version 3 (as specified in [L2TP-BASE] and extended in [L2TP-
[L2TP-L2VPN]) can be used as signaling protocols to set up and L2VPN]) can be used as signaling protocols to set up and maintain
maintain pseudowires (PWs) [PWE3-ARCH]. Any protocol which sets up pseudowires (PWs) [PWE3-ARCH]. Any protocol which sets up
connections must provide a way for each endpoint of the connection to connections must provide a way for each endpoint of the connection to
identify the other; each PW signaling protocol thus provides a way to identify the other; each PW signaling protocol thus provides a way to
identify the PW endpoints. Since each signaling protocol needs to identify the PW endpoints. Since each signaling protocol needs to
support all the different kinds of L2VPN and provisioning models, the support all the different kinds of L2VPN and provisioning models, the
signaling protocol must have a very general way of representing signaling protocol must have a very general way of representing
endpoint identifiers, and it is necessary to specify rules for endpoint identifiers, and it is necessary to specify rules for
encoding each particular kind of endpoint identifier into the encoding each particular kind of endpoint identifier into the
relevant fields of each signaling protocol. This document specifies relevant fields of each signaling protocol. This document specifies
how to encode the endpoint identifiers of each provisioning model how to encode the endpoint identifiers of each provisioning model
into the LDP and L2TPv3 signaling protocols. into the LDP and L2TPv3 signaling protocols.
We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and
[PWE3-ARCH], in particular the terms "Attachment Circuit", [PWE3-ARCH], in particular the terms "Attachment Circuit",
"pseudowire", "PE", "CE". "pseudowire", "PE", "CE".
Section 2 provides an overview of the relevant aspects of Section 2 provides an overview of the relevant aspects of [PWE3-
[PWE3-CONTROL] and [L2TP-L2VPN]. CONTROL] and [L2TP-L2VPN].
Section 3 details various provisioning models and relates them to the Section 3 details various provisioning models and relates them to the
signaling process and to the discovery process. signaling process and to the discovery process.
Section 4 explains how the procedures for discovery and signaling can Section 4 explains how the procedures for discovery and signaling can
be applied in a multi-AS environment and outlines several options for be applied in a multi-AS environment and outlines several options for
the establishment of multi-AS L2VPNs. the establishment of multi-AS L2VPNs.
We do not specify an auto-discovery procedure in this draft, but we We do not specify an auto-discovery procedure in this draft, but we
do specify the information which needs to be obtained via do specify the information which needs to be obtained via auto-
auto-discovery in order for the signaling procedures to begin. The discovery in order for the signaling procedures to begin. The way in
way in which the signaling mechanisms can be integrated with which the signaling mechanisms can be integrated with BGP-based auto-
BGP-based auto-discovery is covered in some detail. discovery is covered in some detail.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 document are to be interpreted as described in RFC 2119
2. Signaling Protocol Framework 2. Signaling Protocol Framework
2.1 Endpoint Identification 2.1 Endpoint Identification
Per [L2VPN-FW], a pseudowire can be thought of as a relationship Per [L2VPN-FW], a pseudowire can be thought of as a relationship
skipping to change at page 6, line 30 skipping to change at page 7, line 30
scenarios. scenarios.
In simple VPWS, where a Forwarder binds exactly one PW to exactly one In simple VPWS, where a Forwarder binds exactly one PW to exactly one
Attachment Circuit, a Forwarder can be identified by identifying its Attachment Circuit, a Forwarder can be identified by identifying its
Attachment Circuit. In simple VPLS, a Forwarder can be identified by Attachment Circuit. In simple VPLS, a Forwarder can be identified by
identifying its PE device and its VPN. identifying its PE device and its VPN.
To set up a PW between a pair of Forwarders, the signaling protocol To set up a PW between a pair of Forwarders, the signaling protocol
must allow the Forwarder at one endpoint to identify the Forwarder at must allow the Forwarder at one endpoint to identify the Forwarder at
the other. In [PWE3-CONTROL], the term "Attachment Identifier", or the other. In [PWE3-CONTROL], the term "Attachment Identifier", or
"AI", to refer to a quantity whose purpose is to identify a "AI", is used to refer to a quantity whose purpose is to identify a
Forwarder. In [L2TP-L2VPN], the term "Forwarder Identifier" is used Forwarder. In [L2TP-L2VPN], the term "Forwarder Identifier" is used
for the same purpose. In the context of this document, "Attachment for the same purpose. In the context of this document, "Attachment
Identifier" and "Forwarder Identifier" are used interchangably. Identifier" and "Forwarder Identifier" are used interchangeably.
[PWE3-CONTROL] specifies two FEC elements which can be used for when [PWE3-CONTROL] specifies two FEC elements that can be used when
setting up pseudowires, the PWid FEC element, and the Generalized Id setting up pseudowires, the PWid FEC element, and the Generalized Id
FEC element. The PWid FEC element carries only one Forwarder FEC element. The PWid FEC element carries only one Forwarder
identifier; it can be thus be used only when both forwarders have the identifier; it can be thus be used only when both forwarders have the
same identifier, and when that identifier can be coded as a 32-bit same identifier, and when that identifier can be coded as a 32-bit
quantity. The Generalized Id FEC element carries two Forwarder quantity. The Generalized Id FEC element carries two Forwarder
identifiers, one for each of the two Forwarders being connected. identifiers, one for each of the two Forwarders being connected.
Each identifier is known as an Attachment Identifier, and a signaling Each identifier is known as an Attachment Identifier, and a signaling
message carries both a "Source Attachment Identifier" (SAI) and a message carries both a "Source Attachment Identifier" (SAI) and a
"Target Attachment Identifier" (TAI). "Target Attachment Identifier" (TAI).
skipping to change at page 7, line 37 skipping to change at page 8, line 37
It should be noted that while different forwarders support different It should be noted that while different forwarders support different
applications, the type of application (e.g., VPLS vs. VPWS) cannot applications, the type of application (e.g., VPLS vs. VPWS) cannot
necessarily be inferred from the forwarders' identifiers. A router necessarily be inferred from the forwarders' identifiers. A router
receiving a signaling message with a particular TAI will have to be receiving a signaling message with a particular TAI will have to be
able to determine which of its local forwarders is identified by that able to determine which of its local forwarders is identified by that
TAI, and to determine the application provided by that forwarder. TAI, and to determine the application provided by that forwarder.
But other nodes may not be able to infer the application simply by But other nodes may not be able to infer the application simply by
inspection of the signaling messages. inspection of the signaling messages.
In this document some further structure of the AGI and AII is
proposed for certain L2VPN applications. We note that an operator
who chooses to use the AII structure defined here would not be at
liberty to use a completely different structure for these identifiers
for some other application. For example, it would be unwise to use
ASCII strings for AII values when setting up individual pseudowires
and at the same time to use the <RT:PE_address> structure for AII
values in VPLS signaling.
2.2 Creating a Single Bidirectional Pseudowire 2.2 Creating a Single Bidirectional Pseudowire
In any form of LDP-based signaling, each PW endpoint must initiate In any form of LDP-based signaling, each PW endpoint must initiate
the creation of a unidirectional LSP. A PW is a pair of such LSPs. the creation of a unidirectional LSP. A PW is a pair of such LSPs.
In most of the PPVPN provisioning models, the two endpoints of a In most of the PPVPN provisioning models, the two endpoints of a
given PW can simultaneously initiate the signaling for it. They must given PW can simultaneously initiate the signaling for it. They must
therefore have some way of determining when a given pair of LSPs are therefore have some way of determining when a given pair of LSPs are
intended to be associated together as a single PW. intended to be associated together as a single PW.
The way in which this association is done is different for the The way in which this association is done is different for the
skipping to change at page 8, line 33 skipping to change at page 9, line 42
Forwarders relative to the group, so that an Attachment Identifier Forwarders relative to the group, so that an Attachment Identifier
would consist of an Attachment Group Identifier (AGI) plus an would consist of an Attachment Group Identifier (AGI) plus an
Attachment Individual Identifier (AII). Attachment Individual Identifier (AII).
IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING
WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN
[PWE3-CONTROL]. [PWE3-CONTROL].
An Attachment Group Identifier may be thought of as a VPN-id, or An Attachment Group Identifier may be thought of as a VPN-id, or
a VLAN identifier, some attribute which is shared by all the a VLAN identifier, some attribute which is shared by all the
Attachment VCs (or pools thereof) which are allowed to be connected. Attachment Circuits (or pools thereof) which are allowed to be
connected.
The details for how to construct the AGI and AII fields identifying The details for how to construct the AGI and AII fields identifying
the pseudowire endpoints in particular provisioning models are the pseudowire endpoints in particular provisioning models are
discussed later in this paper. discussed later in this paper.
We can now consider an LSP to be identified by: We can now consider an LSP to be identified by:
o <PE1, <AGI, AII1>, PE2, <AGI, AII2>> o <PE1, <AGI, AII1>, PE2, <AGI, AII2>>
and the LSP in the opposite direction will be identified by: and the LSP in the opposite direction will be identified by:
o <PE2, <AGI, AII2>, PE1, <AGI, AII1>> o <PE2, <AGI, AII2>, PE1, <AGI, AII1>>
A pseudowire is a pair of such LSPs. In the case of using L2TP A pseudowire is a pair of such LSPs. In the case of using L2TP
signaling, these refer to the two directions of an L2TP session. signaling, these refer to the two directions of an L2TP session.
When a signaling message is sent from PE1 to PE2, and PE1 needs to When a signaling message is sent from PE1 to PE2, and PE1 needs to
refer to an Attachment Identifier which has been configured on refer to an Attachment Identifier which has been configured on
one of its own Attachment VCs (or pools), the Attachment one of its own Attachment Circuits (or pools), the Attachment
Identifier is called a "Source Attachment Identifier". If PE1 Identifier is called a "Source Attachment Identifier". If PE1
needs to refer to an Attachment Identifier which has been needs to refer to an Attachment Identifier which has been
configured on one of PE2's Attachment VCs (or pools), the configured on one of PE2's Attachment Circuits (or pools), the
Attachment Identifier is called a "Target Attachment Identifier". Attachment Identifier is called a "Target Attachment Identifier".
(So an SAI at one endpoint is a TAI at the remote endpoint, and vice (So an SAI at one endpoint is a TAI at the remote endpoint, and vice
versa.) versa.)
In the signaling protocol, we define encodings for the following In the signaling protocol, we define encodings for the following
three fields: three fields:
o Attachment Group Identifier (AGI) o Attachment Group Identifier (AGI)
o Source Attachment Individual Identifier (SAII) o Source Attachment Individual Identifier (SAII)
skipping to change at page 9, line 29 skipping to change at page 10, line 41
o Target Attachment Individual Identifier (TAII) o Target Attachment Individual Identifier (TAII)
If the AGI is non-null, then the SAI consists of the AGI together If the AGI is non-null, then the SAI consists of the AGI together
with the SAII, and the TAI consists of the TAII together with the with the SAII, and the TAI consists of the TAII together with the
AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI
respectively. respectively.
The intention is that the PE which receives an LDP Label Mapping The intention is that the PE which receives an LDP Label Mapping
message or an L2TP Incoming Call Request (ICRQ) message containing a message or an L2TP Incoming Call Request (ICRQ) message containing a
TAI will be able to map that TAI uniquely to one of its Attachment 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 Circuits (or pools). The way in which a PE maps a TAI to an
VC (or pool) should be a local matter. So as far as the signaling Attachment Circuit (or pool) should be a local matter. So as far as
procedures are concerned, the TAI is really just an arbitrary string the signaling procedures are concerned, the TAI is really just an
of bytes, a "cookie". arbitrary string of bytes, a "cookie".
3. Applications 3. Applications
In this section, we specify the way in which the pseudowire signaling In this section, we specify the way in which the pseudowire signaling
using the notion of source and target Forwarder is applied for a using the notion of source and target Forwarder is applied for a
number of different applications. For some of the applications, we number of different applications. For some of the applications, we
specify the way in which different provisioning models can be used. specify the way in which different provisioning models can be used.
However, this is not meant to be an exhaustive list of the However, this is not meant to be an exhaustive list of the
applications, or an exhaustive list of the provisioning models that applications, or an exhaustive list of the provisioning models that
can be applied to each application. can be applied to each application.
skipping to change at page 11, line 20 skipping to change at page 12, line 20
the other PEs. If PE1 has a local <VPN-id, remote AII> pair with the other PEs. If PE1 has a local <VPN-id, remote AII> pair with
value <V, fred>, and PE2 has a local <VPN-id, local AII> pair with value <V, fred>, and PE2 has a local <VPN-id, local AII> pair with
value <V, fred>, PE1 will thus be able to discover that it needs to value <V, fred>, PE1 will thus be able to discover that it needs to
connect to PE2. When signaling, it will use "fred" as the TAII, and connect to PE2. When signaling, it will use "fred" as the TAII, and
will use V as he AGI. PE1's local name for the Attachment Circuit is will use V as he AGI. PE1's local name for the Attachment Circuit is
sent as the SAII. sent as the SAII.
The primary benefit of this provisioning model when compared to The primary benefit of this provisioning model when compared to
Double Sided Provisioning is that it enables one to move an Double Sided Provisioning is that it enables one to move an
Attachment Circuit from one PE to another without having to Attachment Circuit from one PE to another without having to
reconfigure the remote endpoint. reconfigure the remote endpoint. However, compared to the approach
described in Section 3.3 below, it imposes a greater burden on the
discovery mechanism, because each attachment circuit's name must be
advertised individually (i.e. there is no aggregation of AC names in
this simple scheme).
3.1.2 Signaling 3.1.2 Signaling
The LDP-based signaling is as specified in [PWE3-CONTROL], with the The LDP-based signaling follows the procedures specified in [PWE3-
addition of the following: CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to
another PE (PE2) to establish a pseudowire in one direction. If that
message is processed successfully, and there is not yet a pseudowire
in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping
Message to PE1.
When a PE receives a Label Mapping Message, and the TAI identifies a In addition to the procedures of [PWE3-CONTROL], when a PE receives a
particular Attachment Circuit which is configured to be bound to a Label Mapping Message, and the TAI identifies a particular Attachment
point-to-point PW, then the following checks must be made. Circuit which is configured to be bound to a point-to-point PW, then
the following checks must be made.
If the Attachment Circuit is already bound to a pseudowire (including If the Attachment Circuit is already bound to a pseudowire (including
the case where only one of the two LSPs currently exists), and the 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 remote endpoint is not PE1, then PE2 sends a Label Release message to
PE1, with a Status Code meaning "Attachment Circuit bound to PE1, with a Status Code meaning "Attachment Circuit bound to
different PE", and the processing of the Mapping message is complete. different PE", and the processing of the Mapping message is complete.
If the Attachment Circuit is already bound to a pseudowire (including If the Attachment Circuit is already bound to a pseudowire (including
the case where only one of the two LSPs currently exists), but the AI the case where only one of the two LSPs currently exists), but the AI
at PE1 is different than that specified in the AGI/SAII fields of the at PE1 is different than that specified in the AGI/SAII fields of the
skipping to change at page 12, line 23 skipping to change at page 13, line 32
the ICRQ message is complete. the ICRQ message is complete.
These errors could occur as the result of misconfigurations. These errors could occur as the result of misconfigurations.
3.2 Virtual Private LAN Service 3.2 Virtual Private LAN Service
In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits
can be though of as LAN interfaces which attach to "virtual LAN can be though of as LAN interfaces which attach to "virtual LAN
switches", or, in the terminology of [L2VPN-FW], "Virtual Switching switches", or, in the terminology of [L2VPN-FW], "Virtual Switching
Instances" (VSIs). Each Forwarder is a VSI that attaches to a number Instances" (VSIs). Each Forwarder is a VSI that attaches to a number
of PWs and a number of Attachment Circuits. The VPLS service of PWs and a number of Attachment Circuits. The VPLS service [L2VPN-
[L2VPN-REQ, VPLS] requires that a single pseudowire be created REQ, VPLS] requires that a single pseudowire be created between each
between each pair of VSIs that are in the same VPLS. Each PE device pair of VSIs that are in the same VPLS. Each PE device may have a
may have a multiple VSIs, where each VSI belongs to a different VPLS. multiple VSIs, where each VSI belongs to a different VPLS.
3.2.1 Provisioning 3.2.1 Provisioning
Each VPLS must have a globally unique identifier, which we call a Each VPLS must have a globally unique identifier, which we call a
VPN-id. Every VSI must be configured with the VPN-id of the VPLS to VPN-id. Every VSI must be configured with the VPN-id of the VPLS to
which it belongs. which it belongs.
Each VSI must also have a unique identifier, but this can be formed Each VSI must also have a unique identifier, but this can be formed
automatically by concatenating its VPN-id with the IP address of its automatically by concatenating its VPN-id with the IP address of its
PE router. PE router. (Note that the PE address here is used only as a form of
unique identifier; a service provider could choose to use some other
numbering scheme if that was desired.)
3.2.2 Auto-Discovery 3.2.2 Auto-Discovery
3.2.2.1 BGP-based auto-discovery 3.2.2.1 BGP-based auto-discovery
The framework for BGP-based auto-discovery for a VPLS service is as The framework for BGP-based auto-discovery for a VPLS service is as
specified in [BGP-AUTO], section 3.2. specified in [BGP-AUTO], section 3.2.
The AFI/SAFI used would be: The AFI/SAFI used would be:
skipping to change at page 13, line 17 skipping to change at page 14, line 30
the globally unique identifier associated with a VPLS must be the globally unique identifier associated with a VPLS must be
encodable as an 8-byte Route Distinguisher (RD). If the globally encodable as an 8-byte Route Distinguisher (RD). If the globally
unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded
as an RD as specified in [BGP-AUTO]. However, any other method of as an RD as specified in [BGP-AUTO]. However, any other method of
assigning a unique identifier to a VPLS and encoding it as an RD assigning a unique identifier to a VPLS and encoding it as an RD
(using the encoding techniques of [RFC2547bis]) will do. (using the encoding techniques of [RFC2547bis]) will do.
Each VSI needs to have a unique identifier, which can be encoded as a Each VSI needs to have a unique identifier, which can be encoded as a
BGP NLRI. This is formed by prepending the RD (from the previous BGP NLRI. This is formed by prepending the RD (from the previous
paragraph) to an IP address of the PE containing the virtual LAN paragraph) to an IP address of the PE containing the virtual LAN
switch. Note that the role of this address is simply a unique switch. Note that the role of this address is simply as a readily
identifier within the VPN; it does not need to be globally routable. available unique identifier for the VSIs within a VPN; it does not
need to be globally routable. An alternate numbering scheme (e.g.
numbering the VSIs of a single VPN from 1 to n) could be used if
desired.
(Note also that it is not strictly necessary for all the VSIs in the (Note also that it is not strictly necessary for all the VSIs in the
same VPLS to have the same RD, all that is really necessary is that same VPLS to have the same RD, all that is really necessary is that
the NLRI uniquely identify a virtual LAN switch.) the NLRI uniquely identify a virtual LAN switch.)
Each VSI needs to be associated with one or more Route Target (RT) Each VSI needs to be associated with one or more Route Target (RT)
Extended Communities, as discussed in [BGP-AUTO}. These control the Extended Communities, as discussed in [BGP-AUTO}. These control the
distribution of the NLRI, and hence will control the formation of the distribution of the NLRI, and hence will control the formation of the
overlay topology of pseudowires that constitutes a particular VPLS. overlay topology of pseudowires that constitutes a particular VPLS.
skipping to change at page 14, line 5 skipping to change at page 15, line 20
it need not be) an encoding of the VPN-id. If a particular VPLS it need not be) an encoding of the VPN-id. If a particular VPLS
consists of multiple VLANs, each VLAN must have its own unique RT. A consists of multiple VLANs, each VLAN must have its own unique RT. A
VSI can be placed in multiple VLANS (or even in multiple VPLSes) by VSI can be placed in multiple VLANS (or even in multiple VPLSes) by
assigning it multiple RTs. assigning it multiple RTs.
Note that hierarchical VPLS can be set up by assigning multiple RTs Note that hierarchical VPLS can be set up by assigning multiple RTs
to some of the virtual LAN switches; the RT mechanism allows one to to some of the virtual LAN switches; the RT mechanism allows one to
have complete control over the pseudowire overlay which constitutes have complete control over the pseudowire overlay which constitutes
the VPLS topology. the VPLS topology.
If Distributed VPLS (described in Section 3.5) is deployed, only the
N-PEs participate in BGP-based autodiscovery. This means that an
N-PE would need to advertise reachability to each of the VSIs that it
supports, including those located in U-PEs to which it is connected.
To create a unique identifier for each such VSI, an IP address of
each U-PE combined with the RD for the VPLS instance could be used.
In summary, the BGP advertisement for a particular VSI at a given PE In summary, the BGP advertisement for a particular VSI at a given PE
will contain: will contain:
o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:PE_addr o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:PE_addr
o a BGP next hop equal to the loopback address of the PE o a BGP next hop equal to the loopback address of the PE
o an extended community attribute containing one or more RTs o an extended community attribute containing one or more RTs
3.2.3 Signaling 3.2.3 Signaling
skipping to change at page 15, line 9 skipping to change at page 16, line 30
particular VPN. A PE may contain multiple pools per VPN, as each 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 pool may correspond to a particular CE device. It may be desired to
create one pseudowire between each pair of pools that are in the same create one pseudowire 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 result would be to create a full mesh of CE-CE VCs for each
VPN. VPN.
3.3.1 Provisioning 3.3.1 Provisioning
Each pool is configured, and associated with: Each pool is configured, and associated with:
o a set of Attachment Circuits; whether these Attachment Circuits o a set of Attachment Circuits;
must themselves be provisioned, or whether they can be
auto-allocated as needed, is independent of and orthogonal to the
procedures described in this document;
o a "color", which can be thought of as a VPN-id of some sort; o a "color", which can be thought of as a VPN-id of some sort;
o a relative pool identifier, which is unique relative to the color. o a relative pool identifier, which is unique relative to the color.
[Note: depending on the technology used for Attachment Circuits, it
may or may not be necessary to provision these circuits as well. For
example, if the ACs are frame relay circuits, there may be some
separate provisioning system to set up such circuits. Alternatively,
"provisioning" an AC may be as simple as allocating an unused VLAN ID
on an interface. This issue is independent of the procedures
described in this document.]
The pool identifier, and color, taken together, constitute a globally The pool identifier, and color, taken together, constitute a globally
unique identifier for the pool. Thus if there are n pools of a given unique identifier for the pool. Thus if there are n pools of a given
color, their pool identifiers can be (though they do not need to be) color, their pool identifiers can be (though they do not need to be)
the numbers 1-n. the numbers 1-n.
The semantics are that a pseudowire will be created between every The semantics are that a pseudowire will be created between every
pair of pools that have the same color, where each such pseudowire pair of pools that have the same color, where each such pseudowire
will be bound to one Attachment Circuit from each of the two pools. will be bound to one Attachment Circuit from each of the two pools.
If each pool is a set of Attachment Circuits leading to a single CE If each pool is a set of Attachment Circuits leading to a single CE
skipping to change at page 16, line 41 skipping to change at page 18, line 19
circuits at a given PE will contain: circuits at a given PE will contain:
o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:pool_num; o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:pool_num;
o a BGP next hop equal to the loopback address of the PE; o a BGP next hop equal to the loopback address of the PE;
o an extended community attribute containing one or more RTs. o an extended community attribute containing one or more RTs.
3.3.3 Signaling 3.3.3 Signaling
The LDP-based signaling follows the procedures specified in [PWE3-
CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to
another PE (PE2) to establish a pseudowire in one direction. If that
message is processed successfully, and there is not yet a pseudowire
in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping
Message to PE1. Similarly, the L2TPv3-based signaling follows the
procedures of [L2TP-BASE]. Additional details on the use of these
signaling protocols follow.
When a PE sends a Label Mapping message or an ICRQ message to set up When a PE sends a Label Mapping message or an ICRQ message to set up
a PW between two pools, it encodes the color as the AGI, the local a PW between two pools, it encodes the color as the AGI, the local
pool's relative identifier as the SAII, and the remote pool's pool's relative identifier as the SAII, and the remote pool's
relative identifier as the TAII. relative identifier as the TAII.
When PE2 receives a Label Mapping message or an ICRQ message from When PE2 receives a Label Mapping message or an ICRQ message from
PE1, and the TAI identifies to a pool, and there is already an PE1, and the TAI identifies to a pool, and there is already an
pseudowire connecting an Attachment Circuit in that pool to an pseudowire connecting an Attachment Circuit in that pool to an
Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is
the same as the SAI of the Label Mapping or ICRQ message, then PE2 the same as the SAI of the Label Mapping or ICRQ message, then PE2
skipping to change at page 17, line 27 skipping to change at page 19, line 17
The procedures for creating a partial mesh of pseudowires among a set The procedures for creating a partial mesh of pseudowires among a set
of colored pools are substantially the same as those for creating a of colored pools are substantially the same as those for creating a
full mesh, with the following exceptions: full mesh, with the following exceptions:
o Each pool is optionally configured with a set of "import RTs" and o Each pool is optionally configured with a set of "import RTs" and
"export RTs"; "export RTs";
o During BGP-based auto-discovery, the pool color is still encoded o During BGP-based auto-discovery, the pool color is still encoded
in the RD, but if the pool is configured with a set of "export in the RD, but if the pool is configured with a set of "export
RTs", these are are encoded in the RTs of the BGP Update messages, RTs", these are are encoded in the RTs of the BGP Update messages,
INSTEAD the color; INSTEAD of the color;
o If a pool has a particular "import RT" value X, it will create a o If a pool has a particular "import RT" value X, it will create a
PW to every other pool which has X as one of its "export RTs". PW to every other pool which has X as one of its "export RTs".
The signaling messages and procedures themselves are as in section The signaling messages and procedures themselves are as in section
3.3.3. 3.3.3.
As a simple example, consider the task of building a hub-and-spoke
topology. One pool, the "hub" pool, is configured with an export RT
of RT_hub and an import RT of RT_spoke. All other pools (the spokes)
are configured with an export RT of RT_spoke and an import RT of
RT_hub. Thus the Hub pool will connect to the spokes, and vice-
versa, but the spoke pools will not connect to each other.
3.5 Distributed VPLS 3.5 Distributed VPLS
In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS
functionality of a PE router is divided among two systems: a U-PE and functionality of a PE router is divided among two systems: a U-PE and
an N-PE. The U-PE sits between the user and the N-PE. VSI an N-PE. The U-PE sits between the user and the N-PE. VSI
functionality (e.g., MAC address learning and bridging) is performed functionality (e.g., MAC address learning and bridging) is performed
on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS
supported by a U-PE, the U-PE maintains a pseudowire to each other supported by a U-PE, the U-PE maintains a pseudowire to each other
U-PE in the same VPLS. However, the U-PEs do not maintain signaling U-PE in the same VPLS. However, the U-PEs do not maintain signaling
control connections with each other. Rather, each U-PE has only a control connections with each other. Rather, each U-PE has only a
single signaling connection, to its N-PE. In essence, each single signaling connection, to its N-PE. In essence, each U-PE-to-
U-PE-to-U-PE pseudowire is composed of three pseudowires spliced U-PE pseudowire is composed of three pseudowires spliced together:
together: one from U-PE to N-PE, one from N-PE to N-PE, and one from one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to
N-PE to U-PE. U-PE.
Consider for example the following topology: Consider for example the following topology:
U-PE A-----| |----U-PE C U-PE A-----| |----U-PE C
| | | |
| | | |
N-PE E--------N-PE F N-PE E--------N-PE F
| | | |
| | | |
U-PE B-----| |-----U-PE D U-PE B-----| |-----U-PE D
skipping to change at page 18, line 39 skipping to change at page 20, line 39
o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1. o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1.
It doesn't matter which PWs get spliced together, as long as the It doesn't matter which PWs get spliced together, as long as the
result is one from A to each of B, C, and D. result is one from A to each of B, C, and D.
Similarly, there are additional PWs which must get spliced together Similarly, there are additional PWs which must get spliced together
to properly interconnect U-PE B with U-PEs C and D, and to to properly interconnect U-PE B with U-PEs C and D, and to
interconnect U-PE C with U-PE D. interconnect U-PE C with U-PE D.
The following figure illustrates the PWs from A to C and from B to D.
For clarity of the figure, the other four PWs are not shown.
splicing points
| |
V V
A-C PW <-----><-----------><------>
U-PE A-----| |----U-PE C
| |
| |
N-PE E--------N-PE F
| |
| |
U-PE B-----| |-----U-PE D
B-D PW <-----><-----------><------>
^ ^
| |
splicing points
One can see that distributed VPLS does not reduce the number of One can see that distributed VPLS does not reduce the number of
pseudowires per U-PE, but it does reduce the number of control pseudowires per U-PE, but it does reduce the number of control
connections per U-PE. Whether this is worthwhile depends, of course, connections per U-PE. Whether this is worthwhile depends, of course,
on what the bottleneck is. on what the bottleneck is.
3.5.1 Signaling 3.5.1 Signaling
The signaling to support Distributed VPLS can be done with the The signaling to support Distributed VPLS can be done with the
mechanisms described in this paper. However, the procedures for VPLS mechanisms described in this paper. However, the procedures for VPLS
(section 3.2.3) need some additional machinery to ensure that the (section 3.2.3) need some additional machinery to ensure that the
skipping to change at page 19, line 48 skipping to change at page 22, line 35
be given the remote list: {<2, F>}. Since N-PE E has two U-PEs, be given the remote list: {<2, F>}. Since N-PE E has two U-PEs,
this tells it to set up 4 PWs to N-PE F, 2 for each of its E's this tells it to set up 4 PWs to N-PE F, 2 for each of its E's
U-PEs. U-PEs.
The signaling of a PW from N-PE to U-PE is based on the local list The signaling of a PW from N-PE to U-PE is based on the local list
and the local numbering of U-PEs. When signaling a particular PW and the local numbering of U-PEs. When signaling a particular PW
from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII
is set to null, and the TAII is set to the PW number (relative to is set to null, and the TAII is set to the PW number (relative to
that particular VPLS and U-PE). In the above example, when E signals that particular VPLS and U-PE). In the above example, when E signals
to A, it would set the TAII to be 1, 2, or 3, respectively, for the to A, it would set the TAII to be 1, 2, or 3, respectively, for the
three PWs it must set up to A. It would similarly signal three PWs three PWs it must set up to A. It would similarly signal three PWs to
to B. B.
The LSP signaled from U-PE to N-PE is associated with an LSP from The LSP signaled from U-PE to N-PE is associated with an LSP from
N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is
known as a "U-PW". known as a "U-PW".
The signaling of the appropriate set of PWs from N-PE to N-PE is The signaling of the appropriate set of PWs from N-PE to N-PE is
based on the remote list. The PWs between the N-PEs can all be based on the remote list. The PWs between the N-PEs can all be
considered equivalent. As long as the correct total number of PWs considered equivalent. As long as the correct total number of PWs
are established, the N-PEs can splice these PWs to appropriate U-PWs. are established, the N-PEs can splice these PWs to appropriate U-PWs.
The signaling of the correct number of PWs from N-PE to N-PE is based The signaling of the correct number of PWs from N-PE to N-PE is based
on the remote list. The remote list specifies the number of PWs to on the remote list. The remote list specifies the number of PWs to
set up, per local U-PE, to a particular remote N-PE. set up, per local U-PE, to a particular remote N-PE.
When signaling a particular PW from an N-PE to an N-PE, the AGI is When signaling a particular PW from an N-PE to an N-PE, the AGI is
set to the appropriate VPN-id. The TAII identifies the remote N-PE, set to the appropriate VPN-id. The TAII identifies the remote N-PE,
as in the non-distributed case, i.e. it contains an IP address of as in the non-distributed case, i.e. it contains an IP address of the
the remote N-PE. If there are n such PWs, they are distinguished by remote N-PE. If there are n such PWs, they are distinguished by the
the setting of the SAII, which will be a number from 1 to n setting of the SAII, which will be a number from 1 to n inclusive. A
inclusive. A PW between two N-PEs is known as an "N-PW". PW between two N-PEs is known as an "N-PW".
Each U-PW must be "spliced" to an N-PW. This is based on the remote Each U-PW must be "spliced" to an N-PW. This is based on the remote
list. If the remote list contains an element <i, F>, then i U-PWs list. If the remote list contains an element <i, F>, then i U-PWs
from each local U-PE must be spliced to i N-PWs from the remote N-PE from each local U-PE must be spliced to i N-PWs from the remote N-PE
F. It does not matter which U-PWs are spliced to which N-PWs, as F. It does not matter which U-PWs are spliced to which N-PWs, as long
long as this constraint is met. as this constraint is met.
If an N-PE has more than one local U-PE for a given VPLS, it must If an N-PE has more than one local U-PE for a given VPLS, it must
also ensure that a U-PW from each such U-PE is spliced to a U-PW also ensure that a U-PW from each such U-PE is spliced to a U-PW
from each of the other U-PEs. from each of the other U-PEs.
3.5.2 Provisioning and Discovery 3.5.2 Provisioning and Discovery
Every N-PE must be provisioned with the set of VPLS instances it Every N-PE must be provisioned with the set of VPLS instances it
supports, a VPN-id for each one, and a list of local U-PEs for each supports, a VPN-id for each one, and a list of local U-PEs for each
such VPLS. As part of the discovery procedure, the N-PE advertises such VPLS. As part of the discovery procedure, the N-PE advertises
the number of U-PEs for each VPLS. the number of U-PEs for each VPLS. See Section 3.2.2 for details.
Auto-discovery (e.g., BGP-based) can be used to discover all the Auto-discovery (e.g., BGP-based) can be used to discover all the
other N-PEs in the VPLS, and for each, the number of U-PEs local to other N-PEs in the VPLS, and for each, the number of U-PEs local to
that N-PE. From this, one can compute the total number of U-PEs in that N-PE. From this, one can compute the total number of U-PEs in
the VPLS. This information is sufficient to enable one to compute the VPLS. This information is sufficient to enable one to compute
the local list and the remote list for each N-PE. the local list and the remote list for each N-PE.
3.5.3 Non-distributed VPLS as a sub-case 3.5.3 Non-distributed VPLS as a sub-case
A PE which is providing "non-distributed VPLS" (i.e., a PE which A PE which is providing "non-distributed VPLS" (i.e., a PE which
performs both the U-PE and N-PE functions) can interoperate with performs both the U-PE and N-PE functions) can interoperate with
N-PE/U-PE pairs that are providing distributed VPLS. The N-PE/U-PE pairs that are providing distributed VPLS. The "non-
"non-distributed PE" simply advertises, in the discovery procedure, distributed PE" simply advertises, in the discovery procedure, that
that it has one local U-PE per VPLS. And of course, the it has one local U-PE per VPLS. And of course, the non-distributed
non-distributed PE does no splicing. PE does no splicing.
If every PE in a VPLS is providing non-distributed VPLS, and thus If every PE in a VPLS is providing non-distributed VPLS, and thus
every PE advertises itself as an N-PE with one local U-PE, the every PE advertises itself as an N-PE with one local U-PE, the
resultant signaling is exactly the same as that specified in section resultant signaling is exactly the same as that specified in section
3.2.3 above, except that an SAII value of 1 is used instead of null. 3.2.3 above, except that an SAII value of 1 is used instead of null.
(A PE providing non-distributed VPLS should therefore treat SAII (A PE providing non-distributed VPLS should therefore treat SAII
values of 1 the same as it treats SAII values of null.) values of 1 the same as it treats SAII values of null.)
3.5.4 Splicing and the Data Plane 3.5.4 Splicing and the Data Plane
Splicing two PWs together is quite straightforward in the MPLS data Splicing two PWs together is quite straightforward in the MPLS data
plane, as moving a packet from one PW directly to another is just a plane, as moving a packet from one PW directly to another is just a
label replace operation on the PW label. When a PW consists of two label replace operation on the PW label. When a PW consists of two
PWs spliced together, it is assumed that the data will go to the node or more PWs spliced together, it is assumed that the data will go to
where the splicing is being done, i.e., that the data path will the node where the splicing is being done, i.e., that the data path
include the control points. will pass through the nodes that participate in PW signaling.
In some cases, it may be desired to have the data go on a more direct
route from one "true endpoint" to another, without necessarily
passing through the splice points. This could be done by means of a
new LDP TLV carried in the LDP mapping message; call it the "direct
route" TLV. A direct route TLV would be placed in an LDP Label
Mapping message by the LSP's "true endpoint". The TLV would specify
the IP address of the true endpoint, and would also specify a label,
representing the pseudowire, which is assigned by that endpoint.
When PWs are spliced together at intermediate control points, this
TLV would simply be passed upstream. Then when a frame is first put
on the pseudowire, it can be given this pseudowire label, and routed
to the true endpoint, thereby possibly bypassing the intermediate
control points.
Further details on splicing are discussed in [PW-SWITCH]. Further details on splicing are discussed in [PW-SWITCH].
4. Inter-AS Operation 4. Inter-AS Operation
The provisioning, autodiscovery and signaling mechanisms described The provisioning, autodiscovery and signaling mechanisms described
above can all be applied in an inter-AS environment. As in [2547bis] above can all be applied in an inter-AS environment. As in [2547bis]
there are a number of options for inter-AS operation. there are a number of options for inter-AS operation.
4.1 Multihop EBGP redistribution of L2VPN NLRIs 4.1 Multihop EBGP redistribution of L2VPN NLRIs
skipping to change at page 22, line 26 skipping to change at page 25, line 26
from AS to neighboring AS. from AS to neighboring AS.
An ASBR must maintain labeled IPv4 /32 routes to the PE routers An ASBR must maintain labeled IPv4 /32 routes to the PE routers
within its AS. It uses EBGP to distribute these routes to other within its AS. It uses EBGP to distribute these routes to other
ASes. ASBRs in any transit ASes will also have to use EBGP to pass ASes. ASBRs in any transit ASes will also have to use EBGP to pass
along the labeled /32 routes. This results in the creation of a along the labeled /32 routes. This results in the creation of a
label switched path from the ingress PE router to the egress PE label switched path from the ingress PE router to the egress PE
router. Now PE routers in different ASes can establish multi-hop router. Now PE routers in different ASes can establish multi-hop
EBGP connections to each other, and can exchange L2VPN NLRIs over EBGP connections to each other, and can exchange L2VPN NLRIs over
those connections. Following such exchanges a pair of PEs in those connections. Following such exchanges a pair of PEs in
different ASs could establish an LDP session to signal PWs between different ASes could establish an LDP session to signal PWs between
each other. each other.
For VPLS, the BGP advertisement and PW signaling are exactly as For VPLS, the BGP advertisement and PW signaling are exactly as
described in Section 3.2. As a result of the multihop EBGP session described in Section 3.2. As a result of the multihop EBGP session
that exists between source and destination AS, the PEs in one AS that that exists between source and destination AS, the PEs in one AS that
have VSIs of a certain VPLS will discover the PEs in another AS that have VSIs of a certain VPLS will discover the PEs in another AS that
have VSIs of the same VPLS. These PEs will then be able to establish have VSIs of the same VPLS. These PEs will then be able to establish
the appropriate PW signaling protocol session and establish the full the appropriate PW signaling protocol session and establish the full
mesh of VSI-VSI pseudowires to build the VPLS as described in Section mesh of VSI-VSI pseudowires to build the VPLS as described in Section
3.2.3. 3.2.3.
skipping to change at page 23, line 48 skipping to change at page 26, line 48
that, when spliced together, connect the two PEs. that, when spliced together, connect the two PEs.
When this approach is used for VPLS, or for full-mesh VPWS, it leads When this approach is used for VPLS, or for full-mesh VPWS, it leads
to a full mesh of pseudowires among the PEs, just as in the previous to a full mesh of pseudowires among the PEs, just as in the previous
section, but it does not produce a full mesh of control connections section, but it does not produce a full mesh of control connections
(LDP or L2TPv3 sessions). Instead the control connections within a (LDP or L2TPv3 sessions). Instead the control connections within a
single AS run among all the PEs of that AS and the ASBRs of the AS. single AS run among all the PEs of that AS and the ASBRs of the AS.
A single control connection between the ASBRs of adjacent ASes can be A single control connection between the ASBRs of adjacent ASes can be
used to support however many AS-to-AS pseudowire segments are needed. used to support however many AS-to-AS pseudowire segments are needed.
Note that the procedures described here will result in the splicing
points being co-located with the ASBRs. It is of course possible to
have multiple ASBR-ASBR connections between a given pair of ASes. In
this case a given PE could choose among the available ASBRs based on
a range of criteria, such as IGP metric, local configuration, etc.,
analogous to choosing an exit point in normal IP routing. The use of
multiple ASBRs would lead to greater resiliency (at the timescale of
BGP routing convergence) since a PE could select a new ASBR in the
event of the failure of the one currently in use.
We note that, in order for this approach to work correctly, the two
ASes must use RTs and RDs consistently, just as in layer 3 VPNs
[RFC2547bis]. The structure of RTs and RDs is such that there is not
a great risk of accidental collisions. The main challenge is that it
is necessary for the operator of one AS to know what RT or RTs have
been chosen in another AS for any VPN that has sites in both ASes.
As in layer 3 VPNs, there are many ways to make this work, but all
require some co-operation among the providers. For example, provider
A may tag all the NLRI for a given VPN with a single RT, say RT_A,
and provider B can then configure the PEs that connect to sites of
that VPN to import NLRI that contains that RT. Provider B can choose
a different RT, RT_B, tag all NLRI for this VPN with that RT, and
then provider A can import NLRI with that RT at the appropriate PEs.
However this does require both providers to communicate their choice
of RTs for each VPN. Alternatively both providers could agree to use
a common RT for a given VPN. In any case communication of RTs
between the providers is essential.
4.3 Inter-Provider Application of Dist. VPLS Signaling 4.3 Inter-Provider Application of Dist. VPLS Signaling
An alternative approach to inter-provider VPLS can be derived from An alternative approach to inter-provider VPLS can be derived from
the Distributed VPLS approach described above. Consider the the Distributed VPLS approach described above. Consider the
following topology: following topology:
PE A ---- Network 1 ----- Border ----- Border ----- Network 2 ---- PE B PE A ---- Network 1 ----- Border ----- Border ----- Network 2 ---- PE B
Router 12 Router 21 | Router 12 Router 21 |
| |
PE C PE C
skipping to change at page 25, line 13 skipping to change at page 29, line 13
to that VPLS) within a given network. to that VPLS) within a given network.
5. Security Considerations 5. Security Considerations
This document describes a number of different L2VPN provisioning This document describes a number of different L2VPN provisioning
models, and specifies the endpoint identifiers that are required to models, and specifies the endpoint identifiers that are required to
support each of the provisioning models. It also specifies how those support each of the provisioning models. It also specifies how those
endpoint identifiers are mapped into fields of auto-discovery endpoint identifiers are mapped into fields of auto-discovery
protocols and signaling protocols. protocols and signaling protocols.
The security considerations related to the signaling and The security considerations related to the signaling and auto-
auto-discovery protocols are discussed in the relevant protocol discovery protocols are discussed in the relevant protocol
specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], [PWE3-
[PWE3-CONTROL]). CONTROL]).
The security considerations related to the particular kind of L2VPN The security considerations related to the particular kind of L2VPN
service being supported are discussed in [L2VPN-REQS], [L2VPN-FW], service being supported are discussed in [L2VPN-REQS], [L2VPN-FW],
and [VPLS]. and [VPLS].
The security consideration of inter-AS operation are similar to those The security consideration of inter-AS operation are similar to those
for inter-AS L3VPNs [2547bis]. for inter-AS L3VPNs [2547bis].
The way in which endpoint identifiers are mapped into protocol fields The way in which endpoint identifiers are mapped into protocol fields
does not create any additional security issues. does not create any additional security issues.
6. Acknowledgments 6. IANA Considerations
This document requires IANA to assign an AFI and a SAFI. The AFI
could be the same as that assigned for [BGP-VPLS]. The SAFI should
be assigned specifically for this draft.
7. Acknowledgments
Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini
and Francois LeFaucheur for their comments, criticisms, and helpful and Francois LeFaucheur for their comments, criticisms, and helpful
suggestions. suggestions.
Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for
discussing the auto-discovery issues. discussing the auto-discovery issues.
Thanks to Vach Kompella for a continuing discussion of the proper Thanks to Vach Kompella for a continuing discussion of the proper
semantics of the generalized identifiers. semantics of the generalized identifiers.
7. References 8. Normative References
[BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for [BRADNER] Bradner, S., "Key words for use in RFCs to Indicate
Network-based VPNs", Ould-Brahim et. al., Requirement Levels", BCP 14, RFC 2119, March 1997.
draft-ietf-l3vpn-bgpvpn-auto-05.txt, February 2005
[L2TP-BASE] "Layer Two Tunneling Protocol (Version 3)", Lau et. al., [MP-BGP] Bates, T., Rekhter, Y., Chandra, R. and D. Katz,
draft-ietf-l2tpext-l2tp-base-14.txt, June 2004 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[EXT-COMM] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended
Communities Attribute", Internet-Draft
draft-ietf-idr-bgp-ext-communities-09, July 2005.
[L2TP-BASE] Lau et. al., "Layer Two Tunneling Protocol (Version 3)",
RFC 3931, March 2005.
[LDP] Anderson et al., "LDP Specification", RFC 3036, Jan 2001.
[PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini,
et. al., draft-ietf-pwe3-control-protocol-17.txt, June 2005.
9. Informative References
[BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-
based VPNs", Ould-Brahim et. al.,
draft-ietf-l3vpn-bgpvpn-auto-05.txt, February 2005
[L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo,
draft-ietf-l2tpext-l2vpn-01.txt, Jul 2004 draft-ietf-l2tpext-l2vpn-05.txt, June 2005
[L2VPN-FW] "L2VPN Framework", Andersson et. al., [L2VPN-FW] "L2VPN Framework", Andersson et. al.,
draft-ietf-l2vpn-l2-framework-05.txt, June 2004 draft-ietf-l2vpn-l2-framework-05.txt, June 2004
[L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned
Virtual Private Network Services", Augustyn, Serbest, et. al., Virtual Private Network Services", Augustyn, Serbest, et. al.,
draft-ietf-l2vpn-requirements-02.txt, September 2004 draft-ietf-l2vpn-requirements-04.txt, February 2005
[L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen,
draft-ietf-l3vpn-ppvpn-terminology-04.txt, September 2004
[LDP] "LDP Specification", Andersson, et. al., RFC 3036, Jan 2001
[PWE3-ARCH] "PWE3 Architecture", Bryant, Pate, et. al., [L2VPN-TERM] Andersson, Madsen, "PPVPN Terminology", RFC 4026, March
draft-ietf-pwe3-arch-07.txt, March 2004 2005.
[PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, [PWE3-ARCH] Bryant, Pate, et. al., "PWE3 Architecture", RFC 3985,
et. al., draft-ietf-pwe3-control-protocol-14.txt, December 2004 March 2005.
[PW-SWITCH] "Pseudo Wire Switching", Martini, et. al., [PW-SWITCH] "Pseudo Wire Switching", Martini, et. al.,
draft-martini-pwe3-pw-switching-01.txt, October 2004 draft-martini-pwe3-pw-switching-03.txt, April 2005
[RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al.,
draft-ietf-l3vpn-rfc2547bis-02.txt, September 2004 draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004
[RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson,
September 1999 September 1999
[VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al.,
draft-ietf-l2vpn-vpls-ldp-05.txt, September 2004 draft-ietf-l2vpn-vpls-ldp-06.txt, February 2005
Authors' Addresses Authors' Addresses
Eric Rosen Eric Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Mass. Ave. 1414 Mass. Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: erosen@cisco.com Email: erosen@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/