TRILL Working Group Radia Perlman
INTERNET-DRAFT Sun Microsystems
Intended status: Proposed Standard Dinesh Dutt
Cisco Systems
Donald Eastlake 3rd
Stellar Switches
Expires: July 2009 January 2009
RBridge VLAN Mapping
<draft-ietf-trill-rbridge-vlan-mapping-00.txt>
Status of This Document
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list.
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
Abstract
Some bridge products perform a feature known as "VLAN mapping", in
which a bridge translates a data frame's VLAN ID from one VLAN to
another when it forwards a frame from one port to another. This
feature facilitates scenarios such as combining two bridged LANs with
overlapping VLAN IDs into one bridged LAN without merging two
communities just because they have been given the same VLAN ID in the
original two clouds. This document describes how RBridges can achieve
the same functionality.
R. Perlman, et al. [Page 1]
INTERNET-DRAFT RBridge VLAN Mapping
Table of Contents
Status of This Document....................................1
Abstract...................................................1
1. Introduction............................................3
1.1 Terminology............................................4
2. Internal RBridges and VLAN Mapping......................5
3. Configuration of Cut Set VLAN Mapping RBridges..........5
4. Advertisement of VLAN Mappings..........................5
5. Translation of VLAN IDs by Cut Set RBridges.............6
6. Reporting Attached VLANs by Cut Set RBridges in LSPs....6
7. Advertising of Multicast Groups by Cut Set RBridges.....6
8. Endnode Advertisements by cut set RBridges..............7
9. IANA Considerations.....................................8
10. Security Considerations................................8
11. Normative References...................................9
12. Informative References.................................9
Authors' Addresses........................................10
Copyright, Disclaimer, and Additional IPR Provisions......11
R. Perlman, et al. [Page 2]
INTERNET-DRAFT RBridge VLAN Mapping
1. Introduction
Bridges perform a feature known as "VLAN mapping", in which two or
more layer 2 clouds are connected together using a set of bridges,
but in which the VLAN IDs are not consistent in the different clouds.
The set of bridges interconnecting the clouds are known as the "cut
set", meaning that if that set of bridges is removed, the clouds are
separated.
Bridges in the cut set are configured to translate some set of VLAN
IDs in one cloud to different VLAN IDs when forwarding from one cloud
to the other.
One reason to do this is to intentionally not merge VLAN-A endnodes
in one layer 2 cloud with the community of VLAN-A endnodes in the
other cloud.
Another reason to do this is to intentionally merge two communities,
marked with different VLAN IDs in the different clouds.
This feature is accomplished with bridges solely by configuring
bridges on the cut set.
This document explains how to accomplish the same functionality with
RBridges. In this document we will assume there are two clouds
"East" and "West", and RBridges RB1, RB2, and RB3 that interconnect
the two clouds.
. . . +-----+ . . .
. . . + - - - - + RB1 + - - - - + . . .
. W . +-----+ . . E .
. e . . . a .
. s . +-----+ . s . .
. t . .+ - - - - -+ RB2 + - - - - - - +. t .
. . . -+-+---+ . . .
. C . . / | _ _ _ _ _ _+. C . .
l . + - - - | / . l . .
. o . . +-+---+ . o . .
u . .+ - - - -+ RB3 + - - - - - - - +. u . .
. d . . +-----+ d . .
. . . . . . .
We will refer to RBridges other than the cut set of RBridges as
"internal RBridges".
General familiarity with the base TRILL protocol [RFCtrill] is
assumed in this document.
R. Perlman, et al. [Page 3]
INTERNET-DRAFT RBridge VLAN Mapping
1.1 Terminology
The same terminology and acronyms are used in this document as in
[RFCtrill].
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 [RFC2119].
R. Perlman, et al. [Page 4]
INTERNET-DRAFT RBridge VLAN Mapping
2. Internal RBridges and VLAN Mapping
Internal RBridges will not be aware that VLAN mapping is going on.
They will behave exactly as they would without VLAN mapping. The
only evidence they will have of VLAN mapping is the existence of an
optional TLV field that a cut set RBridge, RB1, MAY include in its
LSP, listing the VLAN mappings that RB1 is configured to be
performing.
Internal RBridges will ignore this TLV field. It is only there for
detection of misconfiguration.
3. Configuration of Cut Set VLAN Mapping RBridges
If VLAN A in cloud "East" is to be translated into VLAN B in cloud
"West", a cut set RBridge RB1 must be configured, for each port, as
to whether that port is in East or West, and configured with VLAN
mappings, such as:
"East/VLAN A <----> West/VLAN B"
That mapping means that when RB1 forwards a frame on a port
configured to be in East to a port configured to be in West, with the
VLAN tag of A, it replaces the VLAN tag "A" with "B" in the inner
encapsulated frame.
Note that mappings are always symmetric, meaning that if RB1 is
translating tag "VLAN A" to tag "VLAN B" when forwarding from East to
West, it will translate tag "VLAN B" to tag "VLAN A" when forwarding
from West to East.
4. Advertisement of VLAN Mappings
To detect misconfiguration, a cut set RBridge RB1 MAY advertise its
VLAN mappings. This would be done by assigning IDs to each of the
clouds. All cut set RBridges SHOULD be configured with the same IDs
for the clouds. So, in our example, if "East" is "1" and "West" is
"2", and VLAN A in East is mapped to VLAN B in West, the TLV would
report a set of mappings, including:
{(1:A,2:B)}
R. Perlman, et al. [Page 5]
INTERNET-DRAFT RBridge VLAN Mapping
5. Translation of VLAN IDs by Cut Set RBridges
If RB1 is configured to believe port a is in "East" and port b is in
"West", and RB1 is configured such that "East/VLAN A <----> West/VLAN
B", then when RB1 forwards data frames from port a to port b, if the
received frame from port a has (inner header VLAN ID) VLAN x , then
RB1 changes the VLAN tag from VLAN A to VLAN B as it forwards onto
port b.
Note: This is true whether RB1 is the appointed forwarder on port a
for VLAN x and the frame arrives unencapsulated, or whether the frame
has arrived already encapsulated as a VLAN A frame.
Likewise, RB1 performs the same VLAN translation whether the frame is
unicast or multicast.
6. Reporting Attached VLANs by Cut Set RBridges in LSPs
If RB1 is configured to translate VLAN A to VLAN B, then RB1 reports,
in its LSP, that it is connected to both VLAN A and VLAN B, even if
RB1 is not appointed forwarder for either or both VLAN A or VLAN B.
The reason RB1 must claim to be attached to VLAN A and VLAN B is so
that multi-destination data frames for VLAN A originating in West
will not get filtered before reaching RB1, and multi-destination data
frames for VLAN B originating in East will also not get prematurely
filtered.
7. Advertising of Multicast Groups by Cut Set RBridges
If RB1 is configured to translate VLAN A in East to VLAN B in West,
then RB1 MUST do one of the following, in order to ensure that a
multicast packet for group G in VLAN A will not be filtered inside
the West cloud, if there are receivers for (VLAN A, group G) in East.
If the cut set RBridges do nothing, then a multicast for VLAN B,
group G would be filtered inside the West cloud, since RBridges
inside the East cloud will only be requesting receipt of VLAN A,
group G.
Thus, RB1 MUST do one of the following for each mapped VLAN. It may
use different strategies for different VLANs.
a) for all IP-derived multicast addresses that have been requested by
any RBridges in East for VLAN A, RB1 reports connectivity to those
multicast addresses in VLAN B. Likewise, for all IP-derived
multicast addresses that have been requested by any RBridges in
R. Perlman, et al. [Page 6]
INTERNET-DRAFT RBridge VLAN Mapping
West for VLAN B, RB1 reports connectivity to those multicast
addresses in VLAN A.
b) RB1 reports connectivity to an IPv4 multicast router and an IPv6
multicast router.
8. Endnode Advertisements by cut set RBridges
TRILL allows RBridges to optionally advertise attached endnodes. This
endnode advertisement uses the TRILL ESADI (End System Address
Distribution Information) protocol.
If cut set RBridge RB1 is translating VLAN A (in East) to VLAN B (in
West), and RB1 is doing ESADI for its attached endnodes in VLAN A, it
should transmit the ESADI advertisement tagged with VLAN A when
forwarding onto ports labeled as "East", and transmit the same ESADI
advertisement when forwarding onto ports labeled as "West". An East
VLAN-A ESADI generated by any RBridge in East will automatically get
translated into a VLAN B ESADI when forwarding into West, because
ESADIs are handled just like ordinary encapsulated data frames, the
VLAN tag to which the ESADI belongs is the VLAN tag on the inner data
frame, and that VLAN tag will be translated by (properly configured)
cut set RBridges when forwarding between East and West.
R. Perlman, et al. [Page 7]
INTERNET-DRAFT RBridge VLAN Mapping
9. IANA Considerations
This document requires no IANA actions. This section should be
deleted by the RFC Editor before publication.
10. Security Considerations
See [RFCtrill] for general RBridge Security Considerations.
If cut set RBridges have misconfigured VLAN mappings, VLANs may be
inadvertently partitioned or inadvertently merged and frames may be
delivered in the wrong VLAN. However, misconfiguration of VLAN
mapping will not cause loops.
R. Perlman, et al. [Page 8]
INTERNET-DRAFT RBridge VLAN Mapping
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFCtrill] R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani,
draft-ietf-trill-rbridge-protocol-11.txt, work in progress.
12. Informative References
None.
R. Perlman, et al. [Page 9]
INTERNET-DRAFT RBridge VLAN Mapping
Authors' Addresses
Radia Perlman
Sun Microsystems
16 Network Circle
Menlo Park, CA 94025 USA
Phone: +1-650-960-1300
Email: Radia.Perlman@sun.com
Dinesh G. Dutt
Cisco Systems
170 Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1-408-527-0955
Email: ddutt@cisco.com
Donald Eastlake 3rd
Stellar Switches
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-634-2066
Email: d3e3e3@gmail.com
R. Perlman, et al. [Page 10]
INTERNET-DRAFT RBridge VLAN Mapping
Copyright, Disclaimer, and Additional IPR Provisions
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.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions. For
the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
R. Perlman, et al. [Page 11]
