Internet DRAFT - draft-cai-l2vpn-vpls-vlan-aware-bundling
draft-cai-l2vpn-vpls-vlan-aware-bundling
INTERNET-DRAFT Dennis Cai
Intended Status: Standard Track Sami Boutros
Samer Salam
Reshad Rahman
Expires: April 16, 2013 October 13, 2012
VLAN Aware VPLS services
draft-cai-l2vpn-vpls-vlan-aware-bundling-00.txt
Abstract
This document specifies VPLS extensions to support the new VLAN aware
bundling service interface type. The new service interface type
provides advantages in reducing the provisioning overhead, as well as
pseudowire scalability in environments where a large number of VLANs
need to be extended over an MPLS/IP network while maintaining traffic
segregation among those VLANs.
The VLAN aware bundling service interface can handle the high scale
requirements of today's Data Centers by bundling different VLANs over
a single WAN VPLS instance used to interconnect sites. Furthermore,
this document specifies an extension to the LDP MAC Withdrawal
mechanisms to allow per-VLAN MAC flushing for the new service
interface type.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Cai Expires April 16, 2013 [Page 1]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
Copyright and License 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. VLAN-aware-bundling PW . . . . . . . . . . . . . . . . . . . . 4
3. PW VLAN Vector TLV . . . . . . . . . . . . . . . . . . . . . . 4
4. LDP Capability Negotiation . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Packet forwarding, MAC learning, aging and flushing . . . . 7
5.2. Multicast Pruning . . . . . . . . . . . . . . . . . . . . . 7
5.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. VLAN translation . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . 8
8.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Cai Expires April 16, 2013 [Page 2]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
1 Introduction
The high scale requirements of Layer 2 data center interconnect
services mandate the signaling of a large number of WAN VPLS
instances. As such, network operators are looking for solutions
whereby they can extend multiple Ethernet VLANs over a WAN using a
single VPLS instance, while maintaining traffic segregation among
these VLANs in the data-plane. This gives rise to a requirement for
new service interface types: the VLAN aware bundling service
interfaces.
These new VLAN aware bundling service interfaces MUST:
- Provide the ability to bundle multiple customer VLANs
- Guarantee customer VLAN transparency end-to-end.
- Maintain data-plane separation between the customer VLANs by
creating a dedicated bridge-domain per VLAN.
- Support customer VLAN translation to handle the scenario where
different VLAN Identifiers (VIDs) are used on different sites to
designate the same customer VLAN.
As discussed in [EVPN-REQ], two new service interface types are
defined for VLAN aware bundling: with and without translation. The
new service interfaces maintain data-plane separation, per VLAN,
while sharing one L2VPN VPN instance. In this document, we focus on
the scenario where VPLS is the L2VPN technology. This document
defines a new PW VLAN Vector TLV to be included in the LDP PW FEC
label mapping messages for the VPLS service, using the mechanisms
specified in RFC 4762, as well as a new LDP capability by which a PE
can specify its ability to support this new VLAN aware bundling
service interface type. Furthermore, This document defines extension
to the PWE3 control protocol [RFC4447] to set up the new VLAN aware
bundling type service in MPLS networks. The document specifies as
well an extension to the MAC Withdrawal mechanisms to allow per VLAN
service MAC flushing for this new VLAN aware bundling service.
1.1 Terminology
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].
LDP: Label Distribution Protocol. MAC: Media Access Control MPLS:
Multi Protocol Label Switching. OAM: Operations, Administration and
Maintenance. PE: Provide Edge Node. PW: PseudoWire. TLV: Type,
Length, and Value. VPLS: Virtual Private LAN Services.
Cai Expires April 16, 2013 [Page 3]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
2. VLAN-aware-bundling PW
[RFC4447] uses LDP Label Mapping message [RFC5036] for advertising
the FEC-to-PW Label binding. Two types of PW FEC, FEC-128 and FEC-
129, can be used for this purpose. Both types of PW FEC contain a PW
type Field.
PW type port or raw mode will be used for the VLAN aware bundling
interface type service.
Use of control word is optional and frame encapsulation follows the
same rules as in [RFC4448].
A new PW VLAN vector TLV is defined, the new PW VLAN Vector TLV will
be included in LDP PW label mapping messages, as well it MAY be
included in the MAC flush message.
3. PW VLAN Vector TLV
The PW VLAN Vector TLV is described as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| VLAN Vector(TBD)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|first VLAN Value |NumberOfValues | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| VLANFlushBits[NumberOfValues] |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The U and F bits are set to forward if unknown so that potential
intermediate VPLS PEs unaware of the new TLV can just propagate it
transparently.
The MAC Flush VLAN Vector TLV type is to be assigned by IANA from
the LDP standard [RFC5036] "TLV type name space", as described in
section 7.
The TLV value field is of variable length. The first 12 bits encode
the starting VLAN value. The second 12 bits contain the number of
values. The VLANFlushBits is an array of bits of length =
NumberOfValues, each bit in the array represents a VLAN flush state
starting from the 1st VLAN value. A bit value of 1 means flush and a
bit value of 0 means don't flush
A Starting VLAN value of 0, SHOULD mean include all VLANs, in this
case the NumberOfValues SHOULD be 0.
Cai Expires April 16, 2013 [Page 4]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
The PW VLAN Vector TLV SHOULD be placed after the PW FEC TLV in the
label mapping message as specified in [RFC4447], and SHOULD be placed
after the existing TLVs in MAC Flush message as specified in
[RFC4762].
4. LDP Capability Negotiation
The capability of supporting VLAN Aware Bundling interface type
Service MUST be advertised to all LDP peers. This is achieved by
using the methods in [RFC5561] and advertising the LDP "VLAN aware
Bundling Capability" TLV. If an LDP peer supports the dynamic
capability advertisement, it can send a new Capability message with
the S bit set for the VLAN Aware Bundling capability TLV. If the peer
does not support dynamic capability advertisement, then the VLAN
aware Bundling Capability TLV MUST be included in the LDP
Initialization message during the session establishment. An LSR
having VLAN Aware Bundling capability MUST recognize the new PW VLAN
Vector TLV in LDP label messages.
In line with the requirements listed in [RFC5561], the following TLV
is defined to indicate the VLAN Aware Bundling capability:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| VLAN Aware Capability TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: TLV number pending IANA allocation.
* U-bit: SHOULD be 1 (ignore if not understood).
* F-bit: SHOULD be 0 (don't forward if not understood).
* VLAN Aware Bundling Capability TLV Code Point: The TLV type,
which identifies a specific capability. The VLAN Aware
capability code point is requested in the IANA allocation
section below.
* S-bit: The State Bit indicates whether the sender is
advertising or withdrawing the VLAN Aware capability. The State
bit is used as follows:
1 - The TLV is advertising the capability specified by the TLV
Code Point.
Cai Expires April 16, 2013 [Page 5]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
0 - The TLV is withdrawing the capability specified by the TLV
Code Point.
* Length: MUST be set to 2 (octet).
5. Operation
The following figure shows the VPLS PE model for supporting the VLAN
aware service interface.
+---------------------------------+
| VLAN aware VPLS PE1 |
| +---------------+ |
| | | |
| +------+ | | |
+--+ | | | | | |
|CE|-|---| BD ==== | | +------+
+--+ | | | 1 | | | | | |
| | +------+ | VLAN aware | | | PE2 | +----+
| | | PW Fwdr ===== PW ===| |---| CE |
| | | | | | | +----+
| | +------+ | | | +------+
+--+ | --| BD | | | |
|CE|-|---| 2 ==== | |
+--+ | | | | | |
| +------+ | | |
| +---------------+ |
| |
+---------------------------------+
One VPLS instance has been set up between two sites to extend
multiple customer VLANs. On each site, multiple CE devices could be
connected to the PE. The link between the CE and the PE could be
802.1q or 802.1ad, setup with multiple VLANs. Unlike a classic VPLS
solution that requires a dedicated VPLS instance for each customer
VLAN, only a single VPLS instance has been set up to carry customer
VLANs between the two sites. The use of two sites in the above figure
is for illustration; however, this could be extended to many sites.
In order to quantify the benefit of the approach, let's assume N data
center sites, with M customer VLANs. Classic VPLS full mesh solution
would require M VPLS instances and M*(N-1) PWs on each PE. While with
the new VLAN aware interface service type, the solution would require
one VPLS instance and will only require (N-1) PWs on each PE. To
maintain data-plane separation per customer VLAN, with the new VLAN
aware interface service, each PE will create a bridge-domain per
customer VLAN. As well, a customer VLAN on each CE port will
represent a unique bridge port in the customer bridge-domain. Only
one VPLS instance would be signaled in the core and will be used to
carry multiple customer bridge-domains (or customer VLANs) as long as
Cai Expires April 16, 2013 [Page 6]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
those customer VLANs need to be extended to the same set of sites.
Unlike classic VPLS, where the VPLS PW is presented as a bridge port,
the VFI and the customer VLAN would map to the customer bridge-
domain.
5.1. Packet forwarding, MAC learning, aging and flushing
Given the data-plane separation, packet forwarding in the scope of
one bridge-domain will remain unchanged. When sending traffic over
the PW, a qualifying VLAN tag MUST be present on the packet. This
VLAN tag has global significance across all sites connected to the
VPLS instance and is used to identify the customer bridge domain in
all sites. MAC learning, aging and flushing per bridge-domain will
remain un-changed. Extensions to MAC withdrawal mechanisms, as
described in section 4, would allow the MAC flushing to occur on a
subset of the customer bridge-domains.
5.2. Multicast Pruning
Efficient multicast replication in the core can be achieved via the
use of the new VLAN vector TLV, to prune the flooding on a per VLAN
basis. It is possible to only replicate traffic to PEs that have
advertised a given VLAN in their Vector TLV. Multicast snooping
protocols such as IGMP and PIM MAY be used to further prune the
replication scope for a given multicast group in one customer bridge-
domain.
5.3. OAM
Customer Ethernet OAM frames (e.g. CFM [802.1ag]) will be carried
transparently over the shared VPLS instance by the customers bridge-
domains. Current VCCV mechanisms can be used to verify PWs
connectivity in the VPLS instance shared by the customer bridge-
domains. VPLS OAM framework as defined in [RFC6136] applies to this
new service with no changes.
5.4. VLAN translation
As mentioned above, the VLAN tag carried across the PWs for the new
VLAN aware bundling VPLS instance MUST have network global
significance within the scope of the VPLS instance. As such, VLAN
translation can happen at each PE attached to the VPLS instance to
translate between the global VLAN tag identifying the customer
bridge-domain and the local VLAN tag used by the customer bridge-
domain on this PE.
6. Security Considerations
Cai Expires April 16, 2013 [Page 7]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
This document does not introduce any additional security constraints.
7. IANA Considerations
Two new types field for the VLAN Vector TLV type and VLAN aware
Bundling Capability TLV type are to be assigned by IANA from the LDP
standard [RFC5036] "TLV type name space".
8 References
8.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
8.2 Informative References
[RFC 4762] Mark Lassere, et. al, "Virtual Private LAN Service (LAN)
Using Label Distribution Protocol (LDP) Signaling",
RFC4762, January 2007.
[RFC 5036] Andersson, L., et al. "LDP Specification", RFC5036,
October 2007.
[RFC 4447] Martini. and et al., "Pseudowire Setup and Maintenance
Using Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[RFC 4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for
Ethernet VPN", draft-ietf-l2vpn-evpn-req-00.txt.
[RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, "LDP
Capabilities", RFC 5561, July 2009.
[RFC-6136] Layer 2 Virtual Private Network (L2VPN) Operations,
Administration, and Maintenance (OAM) Requirements and
Cai Expires April 16, 2013 [Page 8]
INTERNET DRAFT VLAN Aware VPLS Services October 13, 2012
Framework.
Authors' Addresses
Dennis Cai
Cisco Systems
EMail: dcai@cisco.com
Sami Boutros
Cisco Systems
EMail: sboutros@cisco.com
Samer Salam
Cisco Systems
EMail: ssalam@cisco.com
Reshad Rahman
Cisco Systems
EMail: rrahman@cisco.com
Cai Expires April 16, 2013 [Page 9]
