Virtual Private LAN Service (VPLS) Using IS-IS
draft-xu-l2vpn-vpls-isis-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Himanshu C. Shah , Xiaohu Xu | ||
| Last updated | 2011-10-13 (Latest revision 2011-09-06) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xu-l2vpn-vpls-isis-02
Network working group X. Xu
Internet Draft Huawei Technologies
Category: Standard Track H. Shah
Ciena Corp
Expires: April 2012 October 13, 2011
Virtual Private LAN Service (VPLS) Using IS-IS
draft-xu-l2vpn-vpls-isis-02
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/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 April 13, 2012.
Copyright Notice
Copyright (c) 2009 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.
Xu & Shah Expires April 13, 2012 [Page 1]
Internet-Draft VPLS Using IS-IS October 2011
Abstract
This document describes a light-weight Virtual Private LAN Service
(VPLS) which uses IS-IS for auto-discovery and signaling.
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].
Table of Contents
1. Introduction ................................................ 3
2. Terminology ................................................. 4
3. Control Plane ............................................... 4
3.1. Extended IS-IS TLV for VPLS............................. 4
3.2. Auto-Discovery ......................................... 5
3.3. Signaling .............................................. 5
4. Data Plane .................................................. 6
4.1. Data Encapsulation and Forwarding .......................6
4.1.1. Unicast ........................................... 6
4.1.2. Multicast/Broadcast................................ 6
4.2. MAC Address Learning.................................... 8
4.2.1. MAC Address Reachability Announcement ..............8
5. Security Considerations...................................... 9
6. IANA Considerations ......................................... 9
7. Acknowledgements ............................................ 9
8. References .................................................. 9
8.1. Normative References.................................... 9
8.2. Informative References................................. 10
Authors' Addresses ............................................ 10
Xu & Shah Expires April 13, 2012 [Page 2]
Internet-Draft VPLS Using IS-IS October 2011
1. Introduction
To support virtual machine (VM) mobility and cluster services at
scale in a cloud data center which accommodates multiple tenants
over a shared physical infrastructure, a scalable L2VPN solution is
essential for interconnecting those millions of servers/VMs while
isolating tens of thousands of tenants within that virtualized data
center environment. Such L2VPN solution SHOULD be able to support
the shortest path forwarding and the Equal Cost Multi-Path (ECMP)
forwarding capabilities so as to maximize the bandwidth capacity
between servers. Besides, it SHOULD be able to provide enough VPN
instances in order to securely isolate a large number of tenants
from each other. VPLS seems as a good L2VPN solution for cloud data
centers since it can almost meet all of the above requirements.
However, the existing VPLS solutions including BGP VPLS [RFC4761]
and LDP VPLS [RFC4762] are a bit heavy-weight for cloud data center
operators due to the following reasons: first, the existing VPLS
solutions require one or more separate protocols dedicated for VPLS
auto-discovery and signaling to be deployed besides IGP which has
been already deployed in data centers; second, full-meshed pseudo-
wires(PWs)associated with the existing VPLS solutions introduce much
burden and complexity for maintenance; third, head-end replication
for multicast and broadcast that is used by the existing VPLS
solutions is sub-optimal from the bandwidth utilization perspective.
Hence, this document describes a IS-IS [IS-IS][RFC1195] based light-
weight VPLS solution which retains the scalability features while
overcoming the shortages of the existing VPLS solutions as mentioned
above. In IS-IS VPLS, the IS-IS routing protocol which has been
already deployed within the data center is extended to realize VPLS,
in addition, there is no full-meshed PWs anymore between PE routers.
To achieve better bandwidth utilization, PIM multicast trees could
be used for delivering multicast, broadcast, and even unknown
unicast traffic.
Note that, in IS-IS VPLS, the VPLS label contained in the L2VPN data
packets (e.g., MAC-in-MPLS-in-IP) is only used for identifying a
particular VPLS instance, rather than identifying both a particular
VPLS instance and a particular ingress PE router as the PW label
does. Therefore, IP-based tunnel is required to be used as the PE-
to-PE tunnel technology in IS-IS VPLS so that the egress PE router
could determine the ingress PE routers of the received L2VPN data
packets from the source address of the tunnel header when performing
MAC address learning.
Xu & Shah Expires April 13, 2012 [Page 3]
Internet-Draft VPLS Using IS-IS October 2011
2. Terminology
This memo makes use of the terms defined in [RFC4664], [VPLS-MCAST],
[RFC4761] and [RFC4762].
3. Control Plane
There are two primary functions of the VPLS control plane: auto-
discovery and signaling. In IS-IS VPLS, these two functions are
accomplished simultaneously by using a single IS-IS TLV
advertisement. One concern of using IS-IS to distribute the VPLS
membership information is that the VPLS membership information would
be exposed to P routers unnecessarily. However, in today's cloud
data center networks which are becoming more and more flat, the
number of P routers within a data center network would not be too
large, furthermore, the extended IS-IS TLV for VPLS is partially
transparent to P routers, that is to say, P routers don't need to
process the VPLS membership information contained in that IS-IS TLV,
but only need to synchronize the Link State PDUs (LSP) with their
adjacent IS-IS neighbors.
3.1. Extended IS-IS TLV for VPLS
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
+-+-+-+-+-+-+-+-+
| Type=VPLS |
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PE's IPv4 or IPv6 Address |
| (128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv (12 bits) | VPLS ID (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv (12 bits) | VPLS Label (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv (12 bits) | VPLS ID (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv (12 bits) | VPLS Label (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Xu & Shah Expires April 13, 2012 [Page 4]
Internet-Draft VPLS Using IS-IS October 2011
Type
TLV Type code for VPLS: TBD.
Length
Total number of bytes contained in the value field.
PE's IPv4 or IPv6 Address
This 128-bit field is filled with one of the PE router's IP
addresses which are reachable across the backbone. The
address filled in this field SHOULD be used as tunnel
destination addresses by remote PE routers when sending a
customer packet to such PE router. If the IP address is IPv4,
the last four octets of this field are filled with the IPv4
address while the remaining part is set to zero. In other
words, it is filled with an IPv4-mapped IPv6 address.
VPLS ID
This field is filled with a 20-bit globally unique VPLS ID
for a particular attached VPLS instance. In case that a
larger VPLS ID space is required, the leftmost 12-bit
reserved field could be used together with the VPLS ID field
as an extended VPLS ID filed. That is to say, the whole 32
bits are filled with a 32-bit long VPLS ID value.
VPLS Label
This field is filled with a 20-bit MPLS label corresponding
to the VPLS instance which is identified by the VPLS ID.
3.2. Auto-Discovery
In IS-IS VPLS, each PE router could automatically discover which
other PE routers are part of a given VPLS instance that is
identified by the globally unique VPLS ID. This allows each PE
router's configuration to consist only of the identity of the VPLS
instance established on this PE router, not the identity of every
other PE router in that VPLS instance.
3.3. Signaling
In IS-IS VPLS, it is REQUIRED that a PE router SHOULD assign the
same MPLS label for a given VPLS instance to any other PE router. In
other words, this VPLS label is used for identifying a particular
Xu & Shah Expires April 13, 2012 [Page 5]
Internet-Draft VPLS Using IS-IS October 2011
VPLS instance, rather than identifying both a particular VPLS
instance and the corresponding ingress PE router as the PW label
does.
The VPLS label in IS-IS VPLS just needs to be locally unique, rather
than globally unique for most cases except the aggregate P-Multicast
tree based VPLS multicast case where a single P-Multicast tree is
shared by more than one VPLS instance and the ability to use
upstream-assigned labels [RFC5331] is not available. For example, in
unicast and ingress-replication multicast cases [VPLS-MCAST], it is
no necessary for the VPLS label to be globally unique. Besides, in
the non-aggregative P-Multicast tree [VPLS-MCAST] based VPLS
multicast case where a single P-Multicast tree is exclusively used
by no more than one VPLS instance, the MAC-in-IP encapsulation is
used since the multicast address itself in the IP based tunnel
header is enough for identifying a particular VPLS instance.
Therefore, it doesn't require the VPLS label to be globally unique
either.
In the aggregate P-Multicast tree [VPLS-MCAST] based VPLS multicast
mode, the globally unique labels could be used if the ability to use
upstream-assigned labels is not available. In this case, the VPLS
label for a given VPLS instance directly equals the VPLS ID of that
VPLS instance.
4. Data Plane
4.1. Data Encapsulation and Forwarding
4.1.1. Unicast
MAC-in-MPLS-in-IP encapsulation [RFC4448][RFC4023] SHOULD be used
for unicast. The IP here means any of IP based encapsulations, such
as MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). There
is almost no difference from BGP VPLS and LDP VPLS from the aspect
of data forwarding.
For unknown unicast, the encapsulation and forwarding is the same as
that for multicast/broadcast described in the following section.
4.1.2. Multicast/Broadcast
There are two major multicast modes for IS-IS VPLS: ingress
replication mode and P-Multicast tree mode.
The encapsulation corresponding to each mode is described in the
following sub-sections.
Xu & Shah Expires April 13, 2012 [Page 6]
Internet-Draft VPLS Using IS-IS October 2011
4.1.2.1. Ingress Replication Mode
In the ingress replication mode, an ingress PE router forward the CE
multicast/broadcast frames received via its attachment circuits
towards each remote PE router of the same VPLS instance in the
separate IP based tunnels destined for each remote PE router. Hence,
the encapsulation in this mode has no difference from that for
unicast.
4.1.2.2. Non-aggregative P-Multicast Tree Mode
In the non-aggregative P-Multicast tree mode where a single P-
Multicast distribution tree in the backbone is exclusively used by
one VPLS instance, the MAC-in-IP encapsulation is used directly
since the destination IP address (i.e., multicast address) contained
in the IP-based tunnel header is enough for the egress PE routers to
determine which VPLS instance the encapsulated customer packets
received from a remote PE router belongs to.
4.1.2.3. Aggregative P-Multicast Tree Mode
For aggregative P-Multicast tree mode in which a single P-Multicast
tree is shared by more than one VPLS instance, MAC-in-MPLS-IP
encapsulation SHOULD be used. The upstream-assigned MPLS label
contained in the inner MPLS header would be used by the egress PE
routers to identify the particular VPLS instance that the received
customer packets belong to. The locally unique VPLS labels which are
advertised in the IS-IS TLVs for VPLS could actually be used as
upstream labels in this mode as well besides being used for known
unicast forwarding. For example, assume PE-1 advertises a locally
unique label L for VPLS instance X with that IS-IS TLV, PE-1 could
send a multicast packet for VPLS X containing label L as an
upstream-assigned label. The egress PE routers could distinguish
whether the MPLS label contained in the encapsulated VPLS packet is
an upstream-assigned label or a downstream-assigned label according
to the "MPLS label type" information contained in the encapsulated
VPLS packets, taken the MPLS-in-GRE encapsulation as an example, the
protocol type field in the GRE header would be set to 0x8847 for
MPLS unicast and 0x8848 for multicast.
Alternatively, to avoid using the complex upstream MPLS label
assignment mechanism [RFC5331], operators could also use the
globally unique VPLS labels provided this usage is doable in such
particular network environment (i.e., a relatively close data center
network environment). Thus, the VPN ID value for a given VPLS
instance would be equal to its corresponding VPLS Label value.
Xu & Shah Expires April 13, 2012 [Page 7]
Internet-Draft VPLS Using IS-IS October 2011
More details about the aggregative P-Multicast tree mode are for
further study.
4.2. MAC Address Learning
MAC addresses of local CE hosts can be learnt by a PE router as a
normal bridge does.
As for learning MAC addresses of remote CE hosts, data-driven MAC
learning is still available in IS-IS VPLS. For example, upon
receiving an encapsulated customer packet from a remote PE router,
the MPLS label contained in the MPLS header of the data packet (or
the destination multicast IP address contained in the IP-based
tunnel header in the case of using non-aggregative P-Multicast trees
for delivering unknown unicast packets)is used to determine the
particular VPLS instance that the data packet belongs to, while the
source IP address contained in the IP-based tunnel header is used to
tell from which ingress PE router the data packet is sent.
Besides, MAC addresses of remote CE hosts can also be learnt on the
control plane by using IS-IS for MAC address reachability
announcement. The following sub-section describes the basic idea of
such alternative.
4.2.1. MAC Address Reachability Announcement
To alleviate the impact on the control plane of P routers, CE MAC
address reachability information SHOULD be fully transparent to P
routers as if the packets containing that information were
encapsulated customer packets. Furthermore, the CE MAC address
reachability information of a given VPLS instance SHOULD only be
distributed to those PE routers of that VPLS instance.
Upon learning the MAC addresses of their local CE hosts, PE routers
would immediately advertise these MAC addresses to other PE routers
of the same VPN instance by using the MAC-Reachability TLV defined
in [RFC6165]. One or more MAC-Reachability TLVs are carried in a LSP
which in turn is encapsulated with an Ethernet header. The source
MAC address is the originating PE router's MAC address whereas the
destination MAC address is a to-be-defined multicast MAC address
specifically identifying IS-IS VPLS PE routers. Such LSPs are
forwarded towards remote PE routers as customer packets by ingress
PE routers. Egress PE routers receiving the above packets SHOULD
intercept them and accordingly process them. It is obvious that
these ISPs are fully transparent to P routers because they are
forwarded by P routers as if they were encapsulated customer packets.
The next-hop information associated with these MAC routes could be
Xu & Shah Expires April 13, 2012 [Page 8]
Internet-Draft VPLS Using IS-IS October 2011
derived from the "IP Interface Address" field contained in the
corresponding LSPs.
More details about how to learn remote CE MAC addresses on the
control plane are for further study.
5. Security Considerations
This document doesn't introduce additional security risk to IS-IS
and VPLS, nor does it provide any additional security feature for
IS-IS and VPLS.
6. IANA Considerations
The IS-IS TLV code for VPLS is required to be defined by IANA.
7. Acknowledgements
Thanks to Tony Li, Peter Ashwood-Smith, Phil Bedard, Kris Price,
Shahram Davari, Adrian Farrel, Giles Heron and other people for
their valuable comments on this proposal.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System
Intra-Domain Routing Exchange Protocol for use in
Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2005.
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", 2008.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
Xu & Shah Expires April 13, 2012 [Page 9]
Internet-Draft VPLS Using IS-IS October 2011
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
4023, March 2005.
[RFC6165] A. Banerjee., D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC6165, February 2011.
[VPLS-MCAST] R. Aggarwal., Y. Kamite., L. Fang, "Multicast in VPLS",
draft-ietf-l2vpn-vpls-mcast-08 (work in progress), October
2010.
[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
Assignment and Context-Specific Label Space", RFC 5331,
August 2008.
8.2. Informative References
[RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
Authors' Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085, P.R. China
Phone: +86 10 82882573
Email: xuxh@huawei.com
Himanshu Shah
Ciena Corp
Email: hshah@ciena.com
Xu & Shah Expires April 13, 2012 [Page 10]