Internet DRAFT - draft-cao-l2vpn-vpls-etree
draft-cao-l2vpn-vpls-etree
Network Working Group Yuqun Cao
Internet Draft Ruijie Networks
Intended status: Standard Track January 29, 2012
Expires: July 2012
Extension to VPLS for E-Tree
draft-cao-l2vpn-vpls-etree-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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."
Cao Expires July 29, 2012 [Page 1]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
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
This Internet-Draft will expire on July 29, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.
Abstract
This document proposes an approach to support Metro Ethernet Forum
(MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service [RFC4761]
[RFC4762]. The proposed solution is characterized by breaking
pseudowire setup between Leaf endpoints in E-Tree instance to fulfill
the specific E-Tree requirement: Leaf cannot communicate with Leaf.
Backward compatibility is also considered in this document.
Table of Contents
1. Introduction................................................3
2. Conventions used in this document............................5
3. Terminology.................................................5
4. Reference Model.............................................6
5. Extension to VPLS for E-Tree.................................9
5.1. Assumptions............................................9
5.2. PW setup Matrix.........................................9
5.3. Endpoint type..........................................9
5.4. Endpoint identifier designation........................10
5.4.1. Endpoint identifier designation using LDP FEC 128..10
5.4.2. Endpoint identifier designation using LDP FEC 129..10
5.4.3. Endpoint identifier designation using BGP..........10
5.5. Signaling procedures...................................11
5.5.1. Signaling endpoint type using LDP.................11
5.5.1.1. Extension to Interface Parameters Sub-TLV.....11
Cao Expires July 29, 2012 [Page 2]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
5.5.1.2. Extension to the Generalized FEC 129..........12
5.5.2. Signaling endpoint type using BGP.................12
5.6. PW setup and teardown..................................13
5.6.1. Signaling procedures using LDP FEC 128............13
5.6.2. Signaling procedures using the Generalized FEC 129.14
5.6.3. Signaling using BGP...............................15
5.6.3.1. Originated from Root endpoint................15
5.6.3.2. Originated from Leaf endpoint................16
5.7. Backward Compatibility.................................16
6. Extension to Data Plane for E-Tree..........................16
7. Compliance with Requirements................................17
8. Security Considerations.....................................17
9. IANA Considerations........................................17
10. References................................................17
10.1. Normative References..................................17
10.2. Informative References................................18
11. Acknowledgments...........................................18
1. Introduction
A specific Rooted-multipoint service, Ethernet Tree (E-Tree), has
been defined by Metro Ethernet Forum [MEF6.1]. Unlike MEF Ethernet
LAN (E-LAN) service where there is no communication restriction
between its attachment circuits, each attachment circuit of an E-Tree
instance is designated as either a Root or a Leaf. A Root-AC can
communicate with all other attachment circuit in an E-Tree instance,
however a Leaf-AC can only communicate with Root-ACs but not Leafs.
In VPLS application [RFC4761] [RFC4762], the attachment circuits can
be thought as LAN interfaces that attach to "virtual LAN switches",
and each attachment circuit in a VPLS instance is equivalent to the
others, therefore the VPLS instance requires that a single pseudowire
is established between each pair of PES in VPLS domain. [RFC6074]
proposed Partial Mesh with a set of "import RTs" and "export RTs",
but cannot fully meet the functional requirements in [Draft VPLS
ETree Req]. In an E-Tree, the attachment circuits SHOULD be
distinguished between Roots and Leafs.
An E-Tree instance MAY have several Roots and several Leafs. Figure 1
below shows scenario for Leaf-to-Leaf communication restriction
between a pair of PEs which have both Root and Leaf in an E-Tree:
Cao Expires July 29, 2012 [Page 3]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
|<----------E-Tree-------->|
| |
V V
+-------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ |Ethernet| +---+ | +---+
|CE1+----AC1---+-+ +-+--PW1---+--+ +--+---AC3----+CE3|
+---+ (Root AC)| | V | | | | V | |(Root AC) +---+
| | S +-+--PW2---+--+ S | |
+---+ | | I | | | | I | | +---+
|CE2+----AC2---+-+ +-+--PW3---+--+ +--+---AC4----+CE4|
+---+ (Leaf AC)| +---+ | | +---+ | (Leaf AC)+---+
+-------+ +---------+
Figure 1 Leaf-to-Leaf communication restriction in E-Tree
- Like A. 8 in [Draft ETree Frwk], a VSI on PE1 or PE2 in an E-Tree
has two members, one is composed of all Root attachment circuits
and called as Root endpoint; another is composed of all Leaf
attachment circuits and called as Leaf endpoint.
- 3 Ethernet pseudowires are established between the VSI of PE1 and
the VSI of PE2 in Figure 1, where Ethernet PW1 is established for
communication between Root AC(s) of PE1 and Root AC(s) of PE2,
Ethernet PW2 is established for communication between Root AC(s)
of PE1 and Leaf AC(s) of PE2, and Ethernet PW3 is established for
communication between Leaf AC(s) of PE1 and Root AC(s) of PE2.
There is no pseudowire between Leaf AC(s).
- If PE2 transmits a frame from AC3, if it is unicast known, it will
forward to the corresponding PW upon MAC address learning; If PE2
transmits an unicast unknown or broadcast from AC3, it will
transmit it via PW2 and PW3. In this case PE1 will receive two
copies and forward them to Root AC and Leaf AC respectively.
- If PE2 receives a frame from PW2, for example, it will forward it
to its Root AC directly; if PE2 receives one frame from PW3, it
will forward to its Leaf AC directly since the frame comes from
Root AC of PE1. There is no communication between AC2 and AC4 of
PE2 since there is no bound pseudowire for them.
The functional requirements for MEF E-Tree support in VPLS can be
found in [Draft VPLS ETree Req].
This document presents a minimal extension to the current VPLS
standard [RFC4761] [RFC4762] to break the ''communication channel''
between Leaf attachment circuits.
Cao Expires July 29, 2012 [Page 4]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Terminology
There are two potential solutions to restrict Leaf-to-Leaf
communication:
1. Extension to data forwarding: Each frame carries additional
information to indicate that it is originated from a Leaf AC
or Root AC on the ingress PE, egress PE will know forward
behavior of the frame: if it comes from Leaf, it will NOT be
forwarded to its local Leaf ACs. [Draft Ext VPLS for ETree]
proposes this solution.
2. Extension on control plane: Leaf-to-Leaf communication
restriction includes two cases,
o Restriction between local Leafs. If two leafs are bound to a
PE in a VSI and that PE receives a frame from one local Leaf,
it does not forward it to the other local Leafs. This
restriction is local behavior and out of the scope of this
document.
o Restriction between local Leafs and remote Leafs, say AC2 of
PE1 and AC4 of PE2 in Figure 1. If AC2 and AC4 are not bound to
any pseudowire, communication between AC2 and AC4 is natively
forbidden.
The purposed solution in this document prefers to the second one and
extends signaling for BGP-VPLS [RFC4761] and LDP-VPLS [RFC4762].
Herein introduces two terms,
- Root-endpoint. Root endpoint is bound to a set of Root-ACs. In a
VSI on any PE has no or only 1 Root-endpoint.
- Leaf-endpoint. Leaf endpoint is bound to a set of Leaf-ACs. In a
VSI on any PE has no or only 1 Leaf-endpoint.
Cao Expires July 29, 2012 [Page 5]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
There is no endpoint which is bound to both Root-ACs and Leaf-ACs in
this document. Each endpoint is designated endpoint identifier. As a
simple example, two endpoint identifiers are designated for PE1 in
Figure 1, say r for Root AC AC1 and l for Leaf AC AC2, but r and l
belong to the same E-Tree instance.
4. Reference Model
Figure 2 shows E-Tree reference model which has 3 PEs: Root-Leaf-
Mixed PE (PE1), Leaf-only PE (PE2) and Root-only PE (PE3). PE1, PE2
and PE3 are in one E-Tree instance. In Figure 2, Root ACs {AC1, AC5,
AC6} can communicate with all other Ethernet ACs in the E-Tree, Leaf
ACs {AC2, AC3, AC4} only can communicate with Root ACs {AC1, AC5,
AC6}, but Leaf ACs can not communicate with each other.
In most use cases, an E-Tree has only several Root ACs but many Leaf-
ACs. The procedures for creating an E-Tree instance are given below:
- Root-Leaf-Mixed PE. Some connected to VSI are Root ACs and some
are Leaf ACs, say AC1 and AC2 of PE1 in Figure 2. Here two
endpoint identifiers are designated to PE1, one is called Root-
endpoint r1, and one is called Leaf-endpoint l1. Both r1 and l1
belong to one VSI;
- Leaf-AC-only PE. All ACs connected to VSI are Leaf ACs, say AC3
and AC4 of PE2 in Figure 2. One endpoint identifier l2 is
designated to PE2 and two Leaf-ACs (AC3 and AC4) are bound to l2.
- Root-AC-only PE. All ACs connected to VSI are Root ACs, say AC5
and AC6 of PE3 in Figure 2. One endpoint identifier r3 which is
designated to PE3 and two Root-ACs (AC5 and AC6) are bound to r3.
Cao Expires July 29, 2012 [Page 6]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
|<--------E-Tree------------>|
| |
V V
+-----------+ +---------+ Leaf endpoint
Root endpoint | PE1 | | PE2 | /
+---+ \ | +-----+ | | +---+ | /\ +---+
| | /\ | | | | | | | | | | | |
|CE1+-|-----AC1---+--+ V | | | | V +--+-|--- --AC3----+CE3|
| | \/(Root AC)| | | | | | | | | | | |
+---+ | | +--+-PW12-+--+ S | | | |(Leaf AC) +---+
Leaf endpoint | | S | | | | | | | |
+---+ \ | | | | | | I | | | | +---+
| | /\ | | | | | | | | | | | |
|CE2+-|-----AC2---+--+ I | | | | +--+-|------AC4----+CE4|
| | \/(Leaf AC)| | | | | | | | | | | |
+---+ | ++---++ | | +-+-+ | \/ (Leaf AC) +---+
+---+---+---+ +----+----+
^ | | |
| | |PW23
| | | +----+----+ Root endpoint
PW13-1| |PW13-2 | PE3 | /
| | | | +-+-+ | /\ +---+
| | | | | +--+-|--------AC5-+CE5|
| | +----------+--+ V | | | |(Root AC)+---+
| | | | | | | | +---+
| | | | S +--+-|------AC6---+CE6|
| +--------------+--+ | | \/ (Root AC)+---+
| | | I | |
| | +---+ |
| | PE3 |
| +---------+
| ^
| <---------E-Tree---------->|
Figure 2 E-Tree typical Reference Model
Within an E-Tree,
- For BGP-VPLS the endpoint identifier is VE ID carried in NLRI, and
it is global unique in E-Tree domain; For LDP-VPLS it can be taken
as attachment identifier (AI) or PW ID.
- All attachment circuits of a Root endpoint can receive frames from
or transmit frames to ACs of any other endpoints in an E-Tree upon
MAC address learning.
Cao Expires July 29, 2012 [Page 7]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
- Any attachment circuit of a Root endpoint can receive frames from
and transmit frames to other Root-ACs in its own domain upon MAC
address learning;
- All attachment circuits of a Leaf endpoint can receive frames from
and transmit frames to ACs of any Root endpoints in an E-Tree upon
MAC address learning.
- Any attachment circuit of a Leaf endpoint cannot receive frames
from and transmit frames to any attachment circuit of other Leaf
endpoints in the E-Tree since there is no communication channel.
- Any attachment of a Leaf endpoint cannot receive frames from and
transmit frames to any other attachment circuit in its domain;
Therefore in Figure 2,
- All endpoint identifiers are designated by network administrator:
1. r1 for PE1's Root endpoint which AC1 (Root AC) is bound to;
l1 for PE1's Leaf endpoint which AC2 (Leaf AC) is bound to;
2. l2 for PE2's Leaf endpoint which is AC3 and AC4 (Leaf ACs)
are bound to.
3. r3 for PE3's Root endpoint which AC5 and AC6 (Root ACs) are
bound to;
- PE1 establishes one pseudowire (PW12) between r1 and l2, but does
not establish any pseudowire between l1 and l2;
- PE1 establishes two pseudowires with PE3 where PW13-1 between r1
and r3, PW13-2 between l1 and r3;
- PE2 has one Leaf endpoint, so PE2 establish one pseudowire (PW12)
between l2 and r1 with PE1, and one pseudowire (PW23) between l2
and r3 with PE3;
- PE3 establishes two pseudowires with PE1 where PW13-1 between r3
and r1, and PW13-2 between r3 and l1;
- On Root-Leaf-Mixed PE, say on PE1, Leaf AC and Root AC belong to
different endpoints where AC1 belongs to r1 and AC2 belongs to l1,
but all belongs to same E-Tree instance. Any attachment circuit of
Leaf endpoint can receive frame from or transmit frame to any
attachment circuit of local Root endpoint, and vice versa.
Cao Expires July 29, 2012 [Page 8]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
- On Leaf-only PE, say PE2, communication between local Leafs of
Leaf endpoint, l2, is forbidden.
- On Root-only PE, say PE3, communication between local Root-ACs of
Root endpoint, r2, is allowed.
This applies to all traffic, including Unicast Known, Unicast Unknown,
Broadcast or Multicast.
5. Extension to VPLS for E-Tree
5.1. Assumptions
In current VPLS application [RFC4761] [RFC4762], the PEs are assumed
to be logically fully meshed with tunnels over which packets that
belong to a service (such as VPLS) are encapsulated and forwarded,
therefore one single Bidirectional Pseudowire is sufficient between
every two PEs in one VPLS. In an E-Tree, 0, 1 or more pseudowires are
created between every two PEs since one PE MAY have 1 or 2 endpoints
with proposed solution in this document.
Any E-Tree endpoint comprises only one AC type. If a PE in a VPLS has
both Root ACs and Leaf ACs, it SHOULD be configured with at least two
endpoints, one is only composed of Root ACs, and another is only
composed of Leaf ACs. It is illegal for any endpoint to have both at
same time.
5.2. PW setup Matrix
Just as mentioned in Section 3, there is no PW between Leaf-endpoints.
Table 1 describes PW setup matrix,
+---------------+------------------+------------------+
| Endpoint type + Destination Root + Destination Leaf +
+---------------+------------------+------------------+
|Originated Root+ Setup + Setup +
+---------------+------------------+------------------+
|Originated Leaf+ Setup + n/a +
+---------------+------------------+------------------+
Table 1 PW setup Matrix
5.3. Endpoint type
Each endpoint in an E-Tree on PE MUST have an attribute, Root
endpoint or Leaf endpoint. For backward compatibility, the default
endpoint type MUST be Root for current VPLS standard [RFC4761]
[RFC4762].
Cao Expires July 29, 2012 [Page 9]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
- Root endpoint. One of its attachment circuits can communicate with
other attachment circuits in its domain or attachment circuits of
other endpoints in E-Tree.
- Leaf endpoint. Its attachment circuits only can communicate with
all attachment circuits of Root endpoints in a VPLS or E-Tree.
5.4. Endpoint identifier designation
5.4.1. Endpoint identifier designation using LDP FEC 128
Endpoint identifier is designated by network administrator. Endpoint
identifier can be thought as PW ID. Endpoint identifier and endpoint
type are exchanged via signaling.
5.4.2. Endpoint identifier designation using LDP FEC 129
Endpoint identifier is designated by network administrator. Endpoint
identifier is thought as AII. Endpoint identifier and type are
exchanged among PEs via signaling.
5.4.3. Endpoint identifier designation using BGP
Section 3.2.2 in [RFC4761] defines VPLS BGP NLRI with a new AFI and
SAFI to exchange VPLS membership and demultiplexors.
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
Figure 3 BGP NLRI for VPLS Information
Endpoint identifier is global unique identifier in E-Tree domain, and
has same signification as VE ID in Figure 3. A PE participating in an
E-Tree must have at least one endpoint identifier, but for a VSI on a
PE which has both Root-ACs and Leaf-ACs, at least two endpoint
Cao Expires July 29, 2012 [Page 10]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
identifiers are designated. Each endpoint has its attribute, Root or
Leaf. Default type is Root.
The whole VE ID set is divided into two parts, one is Root VE ID set
R, one is Leaf VE ID set L and whole VE ID set is V.
L = {l1, l2, ......, ln},
R = { r1, r2,......, rm},
V = { VBO, VBO+1,......, VBO+VBS-1},
Where,
- L and R is subset of V;
- Intersection of two sets L and R is empty set;
- Union of two sets L and R is V;
VE ID is typically assigned by the network administrator.
The endpoint which is in L set only can establish PW with the
endpoint in R set, but the endpoint in R set can establish PW with
all VPLS endpoint in RUL.
5.5. Signaling procedures
5.5.1. Signaling endpoint type using LDP
5.5.1.1. Extension to Interface Parameters Sub-TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 5.5 in [RFC4447] describes interface parameters Sub-TLV which
is used to provide interface-specific parameters. Here we use this to
carry endpoint type information.
Initial Pseudowire Interface Parameter Sub-TLV type allocations are
specified in [RFC4446], and prefer parameter ID is given below,
Cao Expires July 29, 2012 [Page 11]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
Parameter Length Description Reference
ID
=====================================================================
0x0D 4 Endpoint type
The parameter field is defined below,
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |R|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where R is expected remote endpoint type, and L is local endpoint
type. R and L will take the following value,
0 - - Root endpoint
1 - - Leaf endpoint
5.5.1.2. Extension to the Generalized FEC 129
Generalized PWid FEC Element uses Attachment Identifiers (AI) to
indicate forwarders, and an Attachment Identifier would consist of an
Attachment Group Identifier (AGI) plus an Attachment Individual
Identifier (AII). An Attachment Individual Identifier may be thought
of as endpoint identifier in this document.
5.5.2. Signaling endpoint type using BGP
The extended attribute defined in Section [RFC4761] 3.2.4, the
"Layer2 Info Extended Community", is used to signal control
information about the pseudowires to be setup for a VPLS, where
Control Flags (control information regarding the pseudowires) is used
to carry endpoint type information.
Cao Expires July 29, 2012 [Page 12]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
Figure 4 Layer2 Info Extended Community
With reference to Figure 5, the following bit in the control flags is
defined in this document. Bits C, S have been defined in [RFC4761].
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |L|C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 5 Control Flags Bit Vector
Name Meaning
L Carries the E-Tree endpoint information, Leaf endpoint or Root
endpoint, depending on whether L is 1 or 0, respectively. If
L is 1, the endpoint is Leaf type; otherwise the endpoint is
Root type. Default type is Root.
5.6. PW setup and teardown
5.6.1. Signaling procedures using LDP FEC 128
Using the PW id FEC, each of the two pseudowire endpoints
independently initiates the setup of a unidirectional LSP. On Root-
Leaf-Mixed PE, both root Endpoint identifier and Leaf Endpoint
identifier are PW ID.
Suppose PE-a and PE-b are parts of E-Tree foo. PE-a must know the
address of remote PE-b and vice versa.
Cao Expires July 29, 2012 [Page 13]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
1. PE-a initiates the setup by sending a Label Mapping Message to PE-
b. The Label Mapping message contains the FEC TLV, carrying the PW
ID FEC Element (type 0x80). The PW ID FEC element contains the PW
ID (endpoint identifier), local endpoint type and expected remote
endpoint type carried in interface parameters TLV. If PE-a is
Root-Leaf-Mixed PE, it will send two Label Mapping Messages for
those endpoints respectively, and expected remote endpoint type is
Root.
2. When PE-b receives such a Label Mapping message, PE-b interprets
the message as a request to set up a PW whose identifier is PW ID.
If PE-b can not meet PW setup Matrix in 5.2. , then PE2 sends a
Label Release message to PE1, with a Status Code of "Mismatch
endpoint type", then processing of the Label Mapping message is
complete.
3. If PE-b decides to accept the Label Mapping message, then it has
to make sure that a PW LSP is set up in the opposite (PE-a-->PE-b)
direction. If it has already signaled for the corresponding PW LSP
in that direction, pseudowire setup is done. Otherwise, it must
take it as Label Request Message, and initiate such signaling by
sending a Label Mapping message to PE-a carrying PE-a's local
endpoint type as expected remote endpoint type. Normally, PE-a's
local endpoint type is Leaf in this case. A bidirectional
pseudowire is created.
PW teardown process complies with [RFC4447].
5.6.2. Signaling procedures using the Generalized FEC 129
Suppose PE-a and PE-b are parts of E-Tree foo. PE-a must know the
address of remote PE-b and vice versa. This information may be
configured at PE1 and PE2, or may have been learned via autodiscovery
mentioned in [RFC6074].
1. PE-a initiates the setup by sending a Label Mapping Message to PE-
b. The Label Mapping message contains the FEC TLV, carrying the
Generalized PWid FEC Element (type 0x81). The Generalized PWid
FEC element contains the AGI, SAII which is local endpoint
identifier, TAII which is expected remote endpoint identifier,
local endpoint type and expected remote endpoint type carried in
interface parameters TLV.
Cao Expires July 29, 2012 [Page 14]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
2. When PE-b receives such a Label Mapping message, PE-b interprets
the message as a request to set up a PW whose endpoint (at PE-b)
is the Forwarder identified by the TAI, and the AGI could be a
VPN-id identifying a particular E-Tree instance. If PE-b can not
meet PW setup Matrix in 5.2. , then PE2 sends a Label Release
message to PE1, with a Status Code of "Mismatch endpoint type",
then processing of the Label Mapping message is complete.
3. If PE-b decides to accept the Label Mapping message, then it has
to make sure that a PW LSP is set up in the opposite (PE-a-->PE-b)
direction. If it has already signaled for the corresponding PW LSP
in that direction, bidirectional pseudowire is created. Otherwise,
it must take it as Label Request Message, initiate such signaling
by sending a Label Mapping message to PE-a carrying PE-a's local
endpoint type as expected remote endpoint type. This is similar to
the Label Mapping message PE-b received, but the SAI and TAI,
local endpoint type and expected endpoint type, are reversed. Thus,
a bidirectional PW is established.
PW teardown process complies with [RFC4447].
5.6.3. Signaling using BGP
Suppose PE-a and PE-b are parts of E-Tree foo, where PE-a has both
Root endpoint and Leaf endpoint. For Leaf endpoint, it is assigned
with VE ID l which is in Leaf VE ID set, VE block offset VBO, VE
Block Size VBS, and label base lLB; For Root endpoint, it is assigned
with VE ID r which is in Root VE ID set, VE Block Offset VBO, VE
Block Size VBS, and label base rLB. If PE-b is assigned with VE ID w
and gets NLRI advertisement from PE-a, it will do the following
according to [RFC4761] section 3.2.3,
5.6.3.1. Originated from Root endpoint
Supposed PW setup is originated from Root endpoint r. Checks if w is
part of PE-a's 'remote VE set': if VBO <= w < VBO+ VBS, then w is
part of PE-a's remote VE set. If not, PE-b ignores this message, and
skips the rest of this procedure;
1. Since remote endpoint is Root, PW establishment is allowed and
sets up a PW to PE-a: the demultiplexor label to send traffic from
PE-b to PE-a is computed as (rLB + w - VBO).
2. Checks if r is part of any 'remote VE set' that PE-b announced,
i.e., checks if r belongs to some remote VE set that PE-b
announced, say with VE Block Offset VBO', VE Block Size VBS', and
label base LB'. If not, PE-b MUST make a new announcement.
Cao Expires July 29, 2012 [Page 15]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
3. Sets up a PW from PE-a: the demultiplexor label over which PE-b
should expect traffic from PE-a is computed as: (LB' + r - VBO').
If PE-a withdraws an NLRI for r that PE-b was using, then PE-b MUST
tear down its ends of the pseudowire between r of PE-a and w of PE-b.
5.6.3.2. Originated from Leaf endpoint
1. Checks if w is Leaf endpoint with local "Layer2 Info Extended
Community". If it is, PE-b ignores this message since remote
endpoint l is Leaf, and skips the rest of this procedure.
2. Checks if w is part of PE-a's 'remote VE set' if w is Root type:
if VBO <= w < VBO+ VBS, then w is part of PE-a's remote Root VE
set. If not, PE-b ignores this message, and skips the rest of
this procedure.
3. Sets up a PW to PE-a: the demultiplexor label to send traffic from
PE-b to PE-a is computed as (lLB + w - VBO).
4. Checks if l is part of any 'remote VE set' that PE-b announced,
i.e., PE-b checks if l belongs to some remote VE set that PE-b
announced, say with VE Block Offset VBO', VE Block Size VBS', and
label base LB'. If not, PE-b MUST make a new announcement.
5. Sets up a PW from PE-a: the demultiplexor label over which PE-b
should expect traffic from PE-a is computed as: (LB' + l - VBO').
If PE-a withdraws an NLRI for l that PE-b was using, then PE-b MUST
tear down its ends of the pseudowire between PE-a and PE-b.
5.7. Backward Compatibility
Root endpoints and Leaf endpoints are used only in cases where PEs
support E-Tree and have no impact on VPLS PEs already in operation.
In a case where a common VPLS is composed of both PEs supporting the
solution and PEs not supporting it, ACs attached to PEs which don't
support E-Tree are taken as attachment circuits of Root endpoints.
The Leaf-to-Leaf communication restriction will be implemented within
the scope of the compliant PEs.
6. Extension to Data Plane for E-Tree
This solution has no extension requirements on data forwarding.
Cao Expires July 29, 2012 [Page 16]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
Refer to Figure 1, there are 3 bidirectional PWs between PE1 and PE2.
In this way, if one broadcast received from AC 3, PE2 needs to
replicate it into two copies and transmit them via PW 1 and PW 3.
Forwarding performance improvement is outside the scope of this
document.
On any Root-Leaf-Mixed PE, say PE1 in Figure 1, if one broadcast
received from AC 1, it transmits to AC 2 which belongs to another
endpoint of the VSI. This is local behavior and outside the scope of
this document.
7. Compliance with Requirements
The proposed solution in this document meets the requirements
mentioned in [Draft VPLS ETree Req] Section 5.
The solution prohibits communication between any two Leaf endpoints
in an E-Tree domain.
The solution allows multiple Root-ACs or multiple Leaf-ACs in an E-
Tree instance.
The solution allows Root-Leaf-Mixed on any PE in an E-Tree.
The solution is applicable to BGP-VPLS [RFC4761] and LDP-VPLS
[RFC4762].
The solution is applicable to Case 1: Single technology "VPLS-only".
8. Security Considerations
This will be added in later version.
9. IANA Considerations
IANA is requested to allocate new interface parameter sub-TLV type
for E-Tree.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - Phase
2, April 2008
Cao Expires July 29, 2012 [Page 17]
Internet-Draft Extension to signaling in VPLS for E-Tree January 2012
[RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling, January 2007
[RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling, January
2007
[RFC6074] E. Rosen, B. Davie, V. Radoaca & W. Luo, Provisioning,
Auto-Discovery, and Signaling in Layer 2 Virtual Private
Networks (L2VPNs), January 2011
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
10.2. Informative References
[Draft VPLS ETree Req] Key, et al., Requirements for MEF E-Tree
Support in VPLS, draft-key-l2vpn-vpls-etree-reqt-02.txt,
October 2010
[Draft Ext VPLS for ETree] Key, et al., Extension to VPLS for E-Tree,
draft-key-l2vpn-vpls-etree-04.txt,October 2010
[Draft ETree Frwk] Key, et al., A Framework for E-Tree Service over
MPLS Network, draft-key-l2vpn-etree-frwk-04.txt, October
2010
11. Acknowledgments
The author would like to thank Raymond Key, Josh Rogers and Neil
McGill for their insightful comments on initial version.
Authors' Addresses
Yuqun (Sam) Cao
Ruijie Networks
618 Jinshan Road, Fuzhou 350002, China
Email: yuqun.cao@gmail.com
Cao Expires July 29, 2012 [Page 18]
