Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
Internet Draft Marc Lasserre
Document: draft-lasserre-tls-mpls-00.txt Nick Slabakov
Rob Nath
Riverstone Networks
Pascal Menezes Loa Andersson
Terabeam Networks Utfors
Andrew Smith Shahid Akhtar
Consultant Ciena
Tissa Sevenirathne Pierre Lin
Force10 Networks Yipes Communication
Lewis Eatherton Vasile Radoaca
Excite@Home Nortel Networks
Ivy Hsu
Foundry Networks
Expires: February 2002 August 2001
Transparent VLAN Services over MPLS
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Lasserre et al. [Page 1]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
Abstract
This document describes a transparent virtual LAN service (VLS)
solution over MPLS, sometimes known as Transparent LAN Services
(TLS). VLS simulates an Ethernet virtual 802.1d bridge [6] [7] for a
given set of users. It delivers a layer 2 broadcast domain that is
fully capable of learning and forwarding on Ethernet MAC addresses
that is closed to a given set of users. Many VLS services can be
supported from a single PE node.
Conventions
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
Placement of this Memo in Sub-IP Area
RELATED DOCUMENTS
http:// search.ietf.org/internet-drafts/draft-martini-l2circuit-
trans-mpls-06.txt
http://search.ietf.org/internet-drafts/draft-martini-l2circuit-
encap-mpls-02.txt
WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK
PPVPN
WHY IS IT TARGETTED AT THIS WG
The charter of the PPVPN WG includes L2 VPN services and this draft
specifies a model for Ethernet L2 VPN services over MPLS.
JUSTIFICATION
Existing Internet drafts specify how to provide point-to-point
Ethernet L2 VPN services over MPLS. This draft defines how
multipoint Ethernet services can be provided.
Lasserre et al. [Page 2]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
Table of Contents
Status of this Memo................................................1
Abstract...........................................................2
Conventions........................................................2
Table of Contents..................................................3
1. Overview........................................................4
2. Bridging Model for MPLS.........................................4
2.1 Flooding and Forwarding........................................5
2.2 Address Learning...............................................6
2.3 LSP Topology...................................................6
2.4 Loop free L2 VPN...............................................6
2.5 L2 VPN Provisioning............................................7
2.6 LDP Based Discovery............................................7
3. Security Considerations.........................................8
4. References......................................................9
5. Author's Addresses.............................................10
Lasserre et al. [Page 3]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
1. Overview
The following discussion applies to devices that serve as Label Edge
Routers (LERs) on a MPLS network that is VLS capable. It will not
discuss the behavior of transit Label Switch Routers (LSRs) that are
considered a part of MPLS network. The MPLS network provides a
number of Label Switch Paths (LSPs) that form the basis for
connections between LERs attached to the same MPLS network. The
resulting set of interconnected LERs forms a private MPLS VPN where
each LSP is uniquely identified at each MPLS interface by a label.
Ethernet has become a predominant technology initially for Local
Area Networks (LANs) and now as an access technology, specifically
in metropolitan networks. Ethernet ports or IEEE VLANs are dedicated
to customers on Provider Edge (PE) routers acting as LERs. Customer
traffic gets mapped to a specific MPLS L2 VPN by configuring L2 FECs
based upon the input port and/or VLAN.
Broadcast and multicast services are available over traditional
LANs. MPLS does not support such services currently. Sites that
belong to the same broadcast domain and that are connected via an
MPLS network expect broadcast, multicast and unicast traffic to be
forwarded to the proper location(s). This requires MAC address
learning/aging on a per LSP basis, packet replication across LSPs
for multicast/broadcast traffic and for flooding of unknown unicast
destination traffic.
[1] defines how to carry L2 PDUs over point-to-point MPLS LSPs. This
document describes extensions to [1] for transporting Ethernet/802.3
and VLAN [8] traffic across multiple sites that belong to the same
L2 broadcast domain. Note that the same model can be applied to
other 802.1 technologies. It describes a simple and scalable way to
offer Virtual LAN services, including the appropriate flooding of
Broadcast, Multicast and unknown unicast destination traffic over
MPLS, without the need for address resolution servers or other
external servers, as discussed in [10].
2. Bridging Model for MPLS
An MPLS interface acting as a bridge must be able to flood, forward,
and filter bridged frames.
Lasserre et al. [Page 4]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
+----+ +----+
+ C1 +---+ +---| C1 |
+----+ | .................................. | +----+
Site A | .+----+ +----+. | Site B
+--.| PE |---- MPLS Cloud ----| PE |.--+
.+----+ | +----+.
. | .
. | .
. +----+ .
. | PE | .
. +----+ .
..................................
| ^
+----+ |
| C1 | +-- Logical bridge
+----+
Site C
The set of PE devices interconnected via MPLS appears as a single
802.1d bridge/switch to customer C1. Each PE device will learn
remote MAC addresses on LSPs (and keeps learning directly attached
MAC addresses on customer facing ports).
2.1 Flooding and Forwarding
Flooding is performed by sending unknown unicast and multicast
frames to all possible appropriate destinations. In the MPLS
environment this means sending the PDU through each relevant VC LSP.
This is accomplished by explicitly copying it to each VC LSP that is
part of the corresponding VPN.
Note that multicast frames do not necessarily have to be sent to all
VPN members. For simplicity, the default approach of broadcasting
multicast frames can be used. Extensions explaining how to interact
with 802.1 GMRP protocol, IGMP snooping and static MAC multicast
filters will be discussed in a future revision.
To forward a frame, a bridge must be able to associate a destination
MAC address with a VC LSP. It is unreasonable and perhaps impossible
to require bridges to statically configure an association of every
possible destination MAC address with a VC LSP. Therefore, MPLS
bridges must provide enough information to allow an MPLS interface
to dynamically learn about foreign destinations beyond the set of
LSRs. To accomplish dynamic learning, a bridged PDU MUST conform to
the encapsulation described within [1].
Lasserre et al. [Page 5]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
2.2 Address Learning
Unlike BGP VPNs [8], reachability information does not need to be
advertised and distributed via a control plane. Reachability is
obtained by standard learning bridge functions in the data plane.
Since VC LSPs are uni-directional, two LSPs of opposite directions
are required to form a logical bi-directional link. When a new MAC
address is learned on an inbound LSP, it needs to be associated with
the outbound LSP that is part of the same pair. The state of this
logical link can be considered as up as soon as both incoming and
outgoing LSPs are established. Similarly, it can be considered as
down as soon as one of these two LSPs is torn down.
2.3 LSP Topology
PE routers run either an IGP or an EGP between them. Tunnel LSPs
between PE routers are therefore established along routed paths.
Note that tunnel LSPs can also be explicitly routed. Such tunnels
form a full mesh. Partial mesh of tunnel LSPs will be discussed in a
future revision. VC LSPs are then mapped onto these tunnel LSPs. The
resulting VC LSP mesh for the corresponding VPN instance has to be
loop free.
In a Ethernet based topology, since VC LSPs are not terminated at
the CE boundary, unlike Frame Relay or ATM, it is the responsibility
of the Service Providers to offer a loop free topology. With Frame
Relay or ATM, it is the customers' responsibility to run STP or a
routing protocol to prevent loops. With Ethernet as the access
medium, a port and/or a VLAN is used per customer. Customer facing
ports can be used to tunnel untagged or 802.1q tagged traffic. The
VC LSPs connected to each site in the corresponding VPN are only
visible to the PE device.
2.4 Loop free L2 VPN
In order to avoid running a STP instance per VPN, which would not
scale, partial mesh configurations of VC LSPs are not allowed. Note
that customers are allowed to run STP such as when a customer has a
back door link used for backup. In such a case STP BPDUs are simply
tunneled through the MPLS cloud.
Each PE MUST create a rooted tree to every other PE router that
serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme
in order to prevent loops, that is, a PE MUST NOT forward traffic
from one VC LSP to another in the same VPN (since each PE has direct
connectivity to all other PEs in the same VPN).
Lasserre et al. [Page 6]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
2.5 L2 VPN Provisioning
Provisioning of a full mesh can be automatic with a discovery
protocol where each PE advertizes which VPN(s) it serves to other
PEs in the same domain, reducing the provisioning complexity to O(1)
PE to configure when a new site is added, and O(n) new LSPs to be
set up.
The number of sites per VPN and the number of VPNs per PE router
define the total number of VC LSPs to be managed. Let's consider for
example that each VPN has an average of 4 sites and that 1000
customers are supported in a PE, 4000 VC LSPs need to be established
and maintained. Since VC LSPs are set up via LDP, there is no need
to refresh LSP states like in the RSVP case. Tunnel LSPs can be
either be established via LDP or via RSVP.
Since LDP is required for establishing VC LSPs, LDP is a logical
choice to exchange VPN membership between PE routers. BGP offers the
advantage of being able to set up inter-provider VPNs. However, BGP
is typically not enabled on PE routers, but only on core routers.
The signaling of VPN membership via BGP will be discussed in a
future revision. A possible method for exchanging VPN membership via
BGP can be based on [5].
2.6 LDP Based Discovery
Once an LDP adjacency has been formed between two PEs, all VC LSPs
get established over this single TCP session.
Directly connected PEs multicast LDP hellos periodically. Non-
directly connected PEs exchanged unicast targeted hellos to each
desired peer. Once a hello adjacency is formed, a LDP TCP connection
is established. A LDP session is established over this connection by
exchanging LDP initialization messages.
IGP extensions to automatically discover VLS capable PEs can be
used, such as defined in [4]. This will allow a TLS capable PE node
to automatically setup a LDP adjacency to the discovered node and
automate provisioning for VC LSPs. If LDP is used to create tunnel
LSPs, then this will be automated once the newly discovered TLS PE
node has an IP entry in the IGP (this assumes that a loopback
address is used to represent the newly discovered TLS capable PE
node). However if RSVP-TE is used for the tunnel LSP, then it is
important that the two PE nodes have a tunnel LSP between them (the
means of doing this is beyond the scope of this document).
In [2], the L2 VPN information is carried in a Label Mapping message
sent in downstream unsolicited mode. This document defines a new
Lasserre et al. [Page 7]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
parameter id, a 7-byte VPN Id as defined in [9], to the interface
parameters field in the VC FEC described in [2].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The parameter ID is defined as follows:
Parameter ID Length Description
0x01 4 Interface MTU in octets.
0x02 4 Maximum Number of concatenated ATM
cells.
0x03 up to 82 Optional Interface Description string.
0x04 4 CEM [8] Payload Bytes.
0x05 4 CEM options.
0x06 7 VPN Id.
The first five parameters are as described in [2].
The VPN Id field is a unique 7-byte number that identifies a
specific L2 VPN instance in a service provider network. All VLS
capable PE nodes MUST use the same VPN ID for a given L2 VPN. PE
nodes belonging to the same VLS must be capable of mapping Ethernet
ports and/or VLANs to the corresponding VPN Id.
3. Security Considerations
This document does not affect the underlying security issues of
MPLS.
Lasserre et al. [Page 8]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
4. References
[1] "Encapsulation Methods for Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-encap-mpls-02.txt (Work in progress)
[2] "Transport of Layer 2 Frames Over MPLS", draft-martini-
l2circuit-trans-mpls-06.txt (Work in progress)
[3] "LAN Emulation over ATM version 1.0", af-lane-0021.0000 (ATM
Forum)
[4] "Distribution of 802.1Q VLAN information using Opaque LSA",
draft-tsenevir-8021qospf-00.txt (Work in progress)
[5] "Use of BGP-MP for Layer 2 VPN Membership discovery", draft-
tsenevir-bgp-l2vpn-00.txt (Work in progress)
[6] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC
Bridges".
[7] 802.1D - "Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area
networks - Common specifications - Part 3: Media Access Control
(MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993,
802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and
P802.12e." ISO/IEC 15802-3: 1998.
[8] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards
for Local and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", July 1998.
[9] Fox, Gleeson, "Virtual Private Networks Identifier", RFC2685
[10] "Requirements for Network Based Layer 2 VPN", draft-tsenevir-
l2-req-00.txt (Work in progress)
Lasserre et al. [Page 9]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
5. Author's Addresses
Marc Lasserre
Riverstone Networks
5200 Great America Pkwy Phone: 1-408-878-6550
Santa Clara, CA 95054 Email: marc@riverstonenet.com
Nick Slabakov
Riverstone Networks
5200 Great America Pkwy Phone: 1-303-471-6926
Santa Clara, CA 95054 Email: nslabakov@riverstonenet.com
Rob Nath
Riverstone Networks
5200 Great America Pkwy Phone: 1-408-878-6742
Santa Clara, CA 95054 Email: rnath@riverstonenet.com
Loa Andersson
Utfors Bredband AB Phone: +46 8 5270 50 38
Rasundavagen 12 169 29 Solna Email: loa.andersson@utfors.se
Pascal Menezes
TeraBeam Networks
2300 Seventh Ave
Seattle, WA 98121 Email: Pascal.Menezes@Terabeam.com
Andrew Smith Fax: +1 415 345 1827
Consultant Email: ah_smith@pacbell.net
Tissa Senevirathne
Force10 Networks
1440 McCarthy Blvd Phone: 408-865-5103
Milpitas, CA Email: tsenevir@hotmail.com
Pierre Lin
Yipes Communication
114 Sansome St Phone: 415-218-9520
San Francisco, CA 94104 Email: pierre.lin@yipes.com
Lewis Eatherton
Excite@Home
450 Broadway Street Phone: 650-556-5022
Redwood City, CA 94063 Email: leathert@excitehome.net
Vasile Radoaca
Nortel Networks
600 Technology Park Phone: 978-288-6097
Billerica MA 01821 Email: vasile@nortelnetworks.com
Ivy Hsu
Lasserre et al. [Page 10]
Internet Draft draft-lasserre-tls-mpls-00.txt August 2001
Foundry Networks
2100 Gold Street
PO Box 649100 Phone: 408-586-1795
San Jose, CA 95164 Email: ihsu@foundrynet.com
Lasserre et al. [Page 11]