Provider Provisioned VPN Working Group Vach Kompella
Internet Draft Sunil Khandekar
Expiration Date: January 2002 Nick Tingle
TiMetra Networks
Giles Heron
PacketExchange
Juha Heinanen
Song Networks
Tom S. C. Soon
SBC Communications
Rick Wilder
Masergy
Luca Martini
Level3 Communications
Virtual Private Switched Network Services over an MPLS Network
draft-vkompella-ppvpn-vpsn-mpls-00.txt
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.
Abstract
This document describes how to establish a Virtual Private Switched
Network Service for Ethernet over an MPLS network.
Kompella, et al Expires January 2002 [Page 1]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
1. Placement of this Memo in Sub-IP Area...........................2
2. Introduction....................................................3
3. Virtual Private Switched Network................................3
4. Tunneled VPSN...................................................3
4.1. MAC Address Learning..........................................4
4.1.1. MAC Address Learning with Ethernet Encapsulation............5
4.1.2. MAC Address Learning with Ethernet VLAN Encapsulation.......5
5. MAC Address Management..........................................5
5.1. Aging MAC Addresses...........................................5
5.2. MAC Address Signaling.........................................6
5.2.1. MAC TLV.....................................................6
5.2.2. Address Message Containing MAC TLV..........................8
5.2.3. Address Withdraw Message Containing MAC TLV.................8
5.2.4. LDP Session Failure or Termination..........................9
5.3. Discussion on MAC TLVs........................................9
5.3.1. Physical Network Reorganization.............................9
5.3.2. Spanning Tree Action........................................9
6. Signaling a VPSN...............................................10
6.1. Adjacency and Session Management.............................10
7. Security Considerations........................................11
8. Intellectual Property Disclaimer...............................11
9. References.....................................................11
10. Authors' Addresses............................................11
1. Placement of this Memo in Sub-IP Area
RELATED DOCUMENTS
draft-heron-ppvpn-vpsn-reqmts-00.txt
WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK
This fits in the PPVPN box.
WHY IS IT TARGETTED AT THIS WG
This work fits in the PPVPN working group charter. It describes a
service that uses an emulation of a Layer 2 medium to create a
provider provisioned virtual private network [1], specifically, a
Transparent LAN service.
JUSTIFICATION
We believe the WG should consider this draft because it specifies
signaling for a class of layer 2 VPN that has up to now not been
sufficiently addressed in this WG.
Kompella, et al Expires January 2002 [Page 2]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
2. Introduction
This document describes how to signal a Virtual Private Switched
Network (VPSN), which, in the context of Ethernet, is very similar
to a Transparent LAN Service (TLS). The VPSN operates over a packet
switched network that has tunneling capabilities. The requirements
for a VPSN are given in [2].
A VPSN provides the ability to mimic the behavior of an Ethernet
LAN. Several proposals exist to create a tunneled Ethernet service
[3][4], but they address point-to-point tunneling of Ethernet
frames. Simply using point-to-point tunneling of Ethernet frames,
it is possible to create a multi-point service, but it is extremely
inefficient. By adding the ability to learn MAC addresses and
associate them with tunnel endpoints, it is possible to create a
more efficient VPSN.
3. Virtual Private Switched Network
In a VPSN, packets are carried across a transit network so that the
source and destination networks operate as if inter-connected by a
LAN. In the past, ATM has been used to provide TLS. Rather than
overlay a TLS-like service over ATM, this document describes how a
VPSN can be created over a tunneled network, where the tunneling
technology is not hardware-specific. This document describes
extensions to [3] to provide VPSN service. The encapsulation of the
packets will follow the Ethernet or the Ethernet VLAN specifications
given in [5]. All nodes of a VPSN MUST use the same encapsulation.
Throughout this document, we will use LDP as the signaling protocol
for the VPSN. Targeted LDP between the PEs is all that is assumed.
A future document addresses signaling using Multi-protocol
extensions to BGP. We make no assumption about the nature of the
transport tunnels that actually carry the traffic between PEs. For
example, they may be traffic engineered tunnels set up with RSVP-TE,
LDP, GRE or MPLS/IP tunnels.
4. Tunneled VPSN
Consider the following provider network, over which a VPSN service
is to be provisioned. Customer A has three sites, with three local
area networks, A1, A2, and A3, that need to be connected. CEs
represent customer edge routers and PEs represent provider edge
routers.
Kompella, et al Expires January 2002 [Page 3]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
_____
/ A1 \
____ ____CE1 |
/ \ -------- ------- / | |
| A2 CE2- / \ / PE1 \_____/
\____/ \ / \___/ \
---PE2 |
| Service Provider Network |
| ___ |
\ / \ /
_____ PE3 / \ /
|Agg|_/ -------- -------
____ / |___| ____
/ \/ \ / \ CE = Customer Edge Router
| A3 CE3 --C4 A4 | PE = Provider Edge Router
\____/ \____/ Agg = Layer 2 Aggregation
The general problem is MAC address discovery. If it is not known
where the destination MAC addresses for a certain location are, then
the only way for a packet sourced, say at A1, to reach one of the
nodes in A2 or A3, is to broadcast (or multicast) the packet.
Broadcasts and multicasts are hard to do over a tunneled network,
where the efficiencies of sending single packets are lost. However,
this is not unlike the problem of interconnecting multiple LANs at a
single location. The problem is solved using learning bridges which
learn MAC addresses and are able to squelch the transmission of
packets to a MAC address on a particular subnet because they know
that MAC address is not there.
Using the network below as an example setup, we describe two
different methods for making VPSN services possible. Then we
describe the signaling required to make it all work.
4.1. MAC Address Learning
Initially, the VPSN is set up so that PE1, PE2 and PE3 have a full-
mesh of tunnels between them for carrying tunneled traffic. The
VPSN service is assigned a VCID (a 32-bit quantity that is unique
across the provider network across all VPSNs). The VC Type for
VPSNs, the Ethernet VLAN VC type, is associated with the VCID.
Unlike [3], a VCID is unique within a provider domain. Allocation
of domain-wide unique VCIDs is outside the scope of this draft.
For the above example, say PE1 signals VC Label 102 to PE2 and 103
to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3.
Assume a packet from A1 is bound for A2. When it leaves CE1, say it
has a source MAC address of M1 and a destination MAC of M2. If PE1
does not know where M2 is, it will multicast the packet to PE2 and
Kompella, et al Expires January 2002 [Page 4]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
PE3. When PE2 receives the packet, it will have an inner label of
201. PE2 can conclude that the source MAC address M1 is behind PE1,
since it distributed the label 201 to PE1. It can therefore
associate MAC address M1 with VC Label 102.
Note that the two different encapsulations, Ethernet and Ethernet
VLAN, lead to two slightly different learning algorithms. We
describe them below.
4.1.1. MAC Address Learning with Ethernet Encapsulation
When the Ethernet encapsulation is used, the PE is service unaware,
i.e., it does not distinguish between frames that have 802.1q tags
and those that do not. The model is one that allows overlaying
multiple VLANs over a single VPSN. In this model, a PE MUST learn
based on both the 802.1q tag and the MAC address. This is to take
care of unfortunate duplicate MAC addresses used in different
customer VLANs.
4.1.2. MAC Address Learning with Ethernet VLAN Encapsulation
When the Ethernet VLAN encapsulation is used, the PE is service
aware, i.e., it associates that particular VLAN with the VPSN. The
PE can safely learn based on the MAC address alone.
5. MAC Address Management
From the above description, it is clear that MAC addresses are being
learned at multiple locations. For example, the CEs may learn MAC
addresses through ARP (for IPv4 traffic), since the VPSN service
behaves like a LAN. CEs can be out of sync with PEs that also have
to learn MAC addresses and associate them with VC Labels. (This is
one reason why a CE may know the MAC address of another CE router,
but the PE routers may need to relearn them).
5.1. Aging MAC Addresses
PEs that learn remote MAC addresses need to have an aging mechanism
to remove unused entries associated with a VC Label. This is
important both for conservation of memory as well as for
administrative purposes. For example, if customer site A1 has
another CE connected to PE1, and CE1 is shut down, eventually, the
other PEs should unlearn CE1's MAC address.
As with existing LAN bridges, two aging timers SHOULD be implemented
on a PE. First, a local aging of MAC addresses learned from the
customer-facing network SHOULD be implemented with a shorter value
of the timer. Second, a remote aging of MAC addresses learned
Kompella, et al Expires January 2002 [Page 5]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
during the operation of the VPSN SHOULD be implemented with a
considerably longer timer value. The remote aging timer keeps
entries around longer, since the loss of an entry entails a
broadcast across the VPSN to discover the MAC address location.
As packets arrive from the customer-facing network, local MAC
addresses SHOULD be remembered, along with aging. The aging timer
for MAC address M SHOULD be reset when a packet is received from the
customer-facing with source MAC address M.
As packets arrive from the remote PEs, remote MAC addresses SHOULD
be learned. The aging timer for a remote MAC address M SHOULD be
reset when a packet arrives from a remote PE with source MAC address
M.
5.2. MAC Address Signaling
There should be a more proactive manner of installing MAC address
associations and removing them for faster convergence. We introduce
a MAC TLV that is used to specify a list of MAC addresses that can
be added or removed using the Address Message and the Address
Withdraw Message, respectively.
The Address Withdraw message with MAC TLVs SHOULD be supported in
order to uninstall learned MAC addresses that have moved or gone
away more quickly. It is not quite as essential that the Address
message with MAC TLVs be supported. Once a MAC address is
unlearned, re-learning occurs through flooding, so the Address
message only prevents flooding. The Address message MAY be
supported.
5.2.1. MAC TLV
MAC addresses can be signaled using an LDP Address Message. We
define a new TLV, the MAC TLV. Its format is described below. The
encoding of a MAC TLV address is a 2-byte 802.1q tag, followed by
the 6-byte MAC address encoding specified by IEEE 802 documents [6].
The 802.1q tag and the MAC address MUST appear in pairs. If no tag
is required, the value of the tag field MUST be zero.
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| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | 802.1q Tag #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 802.1q Tag #n |
Kompella, et al Expires January 2002 [Page 6]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit
Unknown bit. This bit MUST be set to 0. If the MAC address
format is not understood, then the TLV is not understood, and MUST
be ignored.
F bit
Forward bit. This bit MUST be set to 0. Since the LDP
mechanism used here is Targeted, the TLV MUST NOT be forwarded.
Type
Type field. This field MUST be set to 0x0404 (subject to
IANA approval). This identifies the TLV type as MAC TLV.
Length
Length field. This field specifies the total length of the
TLV, including the Type and Length fields.
S bit
Static bit. In an Address Message, this bit indicates
whether the MAC addresses specified in the TLV are static or
dynamic. If the bit is set, the addresses are static, and MUST NOT
be aged out. If it is clear, the addresses are dynamic, and SHOULD
be aged. The S bit has no significance in an Address Withdraw
Message, and MUST be zero.
Reserved
Reserved bits. They MUST NOT be interpreted at the
receiver, and MUST be set to zero by the sender.
802.1q Tag
The 802.1q Tag. The value MUST be zero if the Ethernet VLAN
encapsulation is used. If the Ethernet encapsulation is used, and
the Ethernet address is associated with a VLAN, it MUST be set to
the VLAN tag. If the Ethernet encapsulation is used, and the MAC
address is not associated with a VLAN, it MUST be set to zero.
Since an 802.1q tag is 12-bits, the high 4 bits of the field MUST be
set to zero.
MAC Address
The MAC address being signaled.
The LDP Address Message contains a FEC TLV (to identify the VPSN in
consideration), a MAC Address TLV and optional parameters. No
optional parameters have been defined for MAC Address signaling.
The LDP Address Withdraw Message contains a FEC TLV (to identify the
VPSN in consideration), a MAC Address TLV and optional parameters.
Kompella, et al Expires January 2002 [Page 7]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
No optional parameters have been defined for the MAC Address
Withdraw signaling.
5.2.2. Address Message Containing MAC TLV
The processing for MAC TLVs received in an Address Message is:
For each (q-tag, MAC address) pair in the MAC TLV:
- If a mapping between the (q-tag, MAC address) pair and a VC
label exists, then, remove the existing mapping, and replace
it with the new association. If the S bit is on in the TLV,
then each (q-tag, MAC address) is not aged. Otherwise, an
aging timer with the remote aging timer value SHOULD be
started.
- If a mapping does not exist, then install a new mapping
between (q-tag, MAC Address) pair and VC label. If the S
bit is on in the TLV, then each the mapping is not aged.
Otherwise, an aging timer with the remote aging timer value
SHOULD be started.
The scope of a MAC TLV is the VPSN specified in the FEC TLV in the
Address Message.
Note that each MAC TLV contains a number of (q-tag, MAC address)
pairs with the same property, i.e., either static or dynamic. A
single Address Message MAY contain multiple MAC TLVs. The number of
MAC addresses can be deduced from the length field in the TLV.
5.2.3. Address Withdraw Message Containing MAC TLV
When MAC addresses are being removed explicitly, e.g., an adjacent
CE router has been disconnected, an Address Withdraw Message can be
sent with the list of MAC addresses to be withdrawn.
The processing for MAC TLVs received in an Address Withdraw Message
is:
For each (q-tag, MAC address) pair in the TLV:
- Remove the association between the (q-tag, MAC address) pair
and VC label. It does not matter whether the MAC address
was installed as a static or dynamic address.
The scope of a MAC TLV is the VPSN specified in the FEC TLV in the
Address Withdraw Message.
The number of MAC addresses can be deduced from the length field in
the TLV. The address list MAY be empty. In this case, the S bit
and the 15-bit Reserved field are not sent, i.e., the length field
would be set to 4. This tells the receiving LSR to delete any MAC
Kompella, et al Expires January 2002 [Page 8]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
addresses learned from the sending LSR for the VPSN specified by the
FEC TLV.
5.2.4. LDP Session Failure or Termination
When a targeted LDP session is torn down or terminated, all
associated MAC address mappings MUST be removed.
5.3. Discussion on MAC TLVs
Several standard bridging issues can be handled with MAC Address
registrations and withdrawals without having to resort to a spanning
tree protocol. They arise from topology changes that move a MAC
address from one PE to another either because of a physical
reorganization, or because of a spanning tree action on the
customer-facing network. These TLVs MAY be triggered by some
conditions that can be vendor-specific, depending on the types of
CE-PE interactions the vendor supports.
For example, suppose a CE router connects in to a VPSN at PE1. All
the PEs participating in the VPSN learn of its MAC address and that
it is served by PE1. If the CE router disconnects from PE1 and
connects to PE2, all the PE routers need to re-learn its new
position. If the other PEs wait until a packet from PE2 is sent
carrying M as the source MAC, then only those PEs who receive such
packets will be able to update their MAC mapping tables. Instead, a
PE SHOULD send an LDP Address Withdraw message with a MAC TLV to
flush out entries. There are two cases where it is advisable to
send MAC TLVs.
5.3.1. Physical Network Reorganization
When a CE router, CE1, connects in to a different PE than it used
to, the PEs participating in the VPSN should all discover this
change as soon as possible. Suppose CE1 connects in to PE1
initially. All PEs in the VPSN learn of CE1's MAC address. At some
point, CE1 is disconnected from PE1, and reconnected at PE2. PE2
locally learns that CE1 is behind it. Since it already has CE1's
MAC address in its table, registered as being served by PE1, PE2
SHOULD send out an Address Withdraw message with CE1's MAC address.
5.3.2. Spanning Tree Action
A CE router, CE1, may be multi-homed into the provider network at
PE1 and PE2. If spanning tree is run on the customer-facing
network, then one of the links CE1-PE1 or CE1-PE2 will be blocked.
Kompella, et al Expires January 2002 [Page 9]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
Suppose CE1-PE1 is active and CE1-PE2 is blocked. Now, if CE1-PE1
goes down, CE1-PE2 is unblocked, and CE1's MAC address appears to be
served by PE2. PE2 SHOULD send out an Address Withdraw message with
CE1's MAC address.
6. Signaling a VPSN
As described in [3], LDP will be used in Downstream Unsolicited mode
to distribute VC labels. LDP will be used with targeted peers. The
FEC TLV is defined as in [3].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC tlv |C| VC Type |VC info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VC, C, VC Type, VC Info Length, Group ID, Interface parameters
As defined in [3].
VCID
The VCID is defined much as in [3]. The only difference is
that it is globally unique within a provider domain, independently
of the VC Type.
6.1. Adjacency and Session Management
As in normal LDP Downstream Unsolicited operation, when a PE is
configured as part of a VPSN, it issues a Targeted Hello to each
other PE in the VPSN. The actual discovery of those other PEs that
are part of the VPSN will be addressed in companion drafts, using
BGP advertisements and LDP signaling, respectively.
When a Targeted Hello is received, if the receiving PE is not
configured to be part of the VPSN, it MAY send back a Label Release.
However, the Liberal Label Retention SHOULD be used [3], wherein a
PE that does not participate in a VPSN may still retain a received
VC label. The VC would be set up only when the PE is configured to
be a member of the VPSN, and reciprocates with its own VC label
mapping.
Note that the act of instantiating a VPSN on a PE triggers LDP
session setup and VC label exchange, and since VC label exchange
Kompella, et al Expires January 2002 [Page 10]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
occurs in both directions, Liberal Label Retention Mode is not
necessary.
7. Security Considerations
No new security issues result from this draft. It is recommended in
[2] that LDP security (authentication) methods [7] be applied. This
would prevent unauthorized participation by a PE in a VPSN. Traffic
separation for VPSNs is maintained using VC labels. However, for
additional levels of security, the customer MAY deploy end-to-end
security, which is out of the scope of this draft.
8. Intellectual Property Disclaimer
This document is being submitted for use in IETF standards
discussions.
9. References
[1] "Service Requirements for Provider Provisioned Virtual
Private Networks", M. Carugi, et al. June 2001. draft-ietf-
ppvpn-requirements-01.txt. Work in progress.
[2] "Requirements for Virtual Private Switched Networks", G.
Heron, et al. July 2001. draft-heron-ppvpn-vpsn-reqmts-
00.txt. Work in progress.
[3] "Transport of Layer 2 Frames Over MPLS", L. Martini, et al.
May 2001. draft-martini-l2circuit-trans-mpls-06.txt. Work
in progress.
[4] "MPLS-Based Layer 2 VPNs", K. Kompella, et al. draft-
kompella-ppvpn-l2vpn-00.txt. June 2001. Work in progress.
[5] "Encapsulation Methods for Transport of Layer 2 Frames Over
MPLS", L. Martini, et al. draft-martini-l2circuit-encap-
mpls-02.txt. February 2001. Work in progress.
[6] IEEE STD 802.3-2000. October 2000.
[7] "LDP Specification", L. Andersson, et al. RFC 3036. January
2001.
[8] IEEE STD 802.1Q-1998. December 1998.
10. Authors' Addresses
Kompella, et al Expires January 2002 [Page 11]
Internet Draft draft-vkompella-ppvpn-vpsn-mpls-00.txt July 2001
Vach Kompella
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Email: vkompella@timetra.com
Nick Tingle
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Email: ntingle@timetra.com
Sunil Khandekar
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
Email: sunil@timetra.com
Giles Heron
PacketExchange Ltd.
The Truman Brewery
91 Brick Lane
LONDON E1 6QL
United Kingdom
Email: giles@packetexchange.net
Juha Heinanen
Song Networks, Inc.
Tom S. C. Soon
SBC Technology Resources Inc.
4698 Willow Road
Pleasanton, CA 94588
sxsoon@tri.sbc.com
Rick Wilder
Masergy Inc.
2901 Telestar Ct.
Falls Church, VA 22042
Luca Martini
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
Email: luca@level3.net
Kompella, et al Expires January 2002 [Page 12]