One document matched: draft-ietf-trill-rbridge-vlan-mapping-03.txt
Differences from draft-ietf-trill-rbridge-vlan-mapping-02.txt
TRILL Working Group Radia Perlman
INTERNET-DRAFT Intel Labs
Intended status: Proposed Standard Dinesh Dutt
Ayan Banerjee
Cisco Systems
Donald Eastlake 3rd
Stellar Switches
Expires: March 29, 2010 September 30, 2010
RBridges: Campus VLAN and Priority Regions
<draft-ietf-trill-rbridge-vlan-mapping-03.txt>
Abstract
Within an RBridge campus, the VLAN and priority of TRILL encapsulated
frames is preserved. However, in some cases it may be desired that
data VLAN and/or priority be mapped at the boundary between regions
of such a campus. This document describes an optional RBridge feature
to provide this functionality.
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
R. Perlman, et al. [Page 1]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
Table of Contents
1. Introduction............................................3
1.1 RBridge Campus Regions.................................4
1.2 Terminology............................................5
2. Internal and Cut Set RBridge Configuration and Mappings.6
2.1 Multiple Crossings.....................................7
2.2 Native Frame Considerations............................8
2.3 More than Two Regions..................................8
2.4 Mapping Implementation.................................9
3. End Node Address Learning Between Regions..............10
4. Cut Set RBridge Attraction of VLANs and Multicast......11
5. Advertisement of VLAN and Priority Mappings............11
5.1 VLAN Advertisement TRILL Sub-TLV......................12
5.2 Priority Advertisement TRILL Sub-TLV..................13
6. TRILL GenApp TLV.......................................16
7. IANA Considerations....................................17
8. Security Considerations................................17
9. Normative References...................................18
10. Informative References................................18
Appendix Z: Change Summary and RFC Editor Notes...........19
Changes from -00 to -01...................................19
Changes from -01 to -02...................................19
Changes from -02 to -03...................................20
R. Perlman, et al. [Page 2]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
1. Introduction
The IETF TRILL protocol provides transparent forwarding, with a
number of additional features, by use of IS-IS routing and
encapsulation with a hop count as specified in [RFCtrill].
Devices implementing the TRILL protocol are called RBridges. An
RBridge campus is an area of RBridges and possibly bridges bounded by
and interconnecting end stations and Layer 3 routers, analogous to a
customer bridge LAN (which is an area of bridges interconnecting end
stations, routers, and RBridges). In an RBridge campus, native frames
(as defined in [RFCtrill]), when they arrive at their first or
ingress RBridge, are encapsulated, routed in encapsulated form via
zero or more transit RBridges, and finally decapsulated and delivered
by their egress RBridge.
The ports of RBridges are the same as the ports of IEEE [802.1Q-2005]
bridges, except as described in [RFCtrill] with TRILL being
implemented above those ports. Such ports provide for the association
of incoming frames with a particular frame priority and customer
VLAN. (See Appendix D of [RFCtrill].)
Bridge ports can map frame priorities, a process called "priority
regeneration" in IEEE 802.1. In addition, some bridge products
provide a feature to map the customer VLAN of incoming VLAN tagged
frames, a process of the type called "VLAN ID translation" in IEEE
802.1.
Using such port features, it is possible to configure RBridge ports
to map the priority and/or VLAN of native frames being received for
ingress or to map the priority and/or VLAN of the frame inside a
TRILL data frame (as defined in [RFCtrill]) after it has been
decapsulated for egress through an output port. But priority and/or
VLAN mapping of the outer priority and VLAN (Outer.VLAN) of an
encapsulated frame has no effect on the Inner.VLAN tag in the
encapsulated frame. In TRILL, the Inner.VLAN tag gives the real VLAN
and priority of the data and these are unaffected by any port
features that change only the Outer.VLAN priority or VLAN.
The default for TRILL is to provide connectivity between all end
stations and routers in the same VLAN. However, there are cases, such
as when combining existing RBridge campuses into a larger campus,
where it may be desirable to have the same VLAN in different regions
of an RBridge campus mean different things. In that case, it would be
necessary for end stations or Layer 3 routers in that VLAN not to be
connected if they are in different regions. It might also be
desirable to have end stations in different regions that are in
different VLANs to have connectivity if those different VLANs in
their different regions actually indicate membership in the same
Layer 2 community. Similar circumstances can arise for priority.
R. Perlman, et al. [Page 3]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
This document describes how to achieve this though an optional TRILL
feature.
1.1 RBridge Campus Regions
The set of RBridges interconnecting different regions of an RBridge
campus are known as the "cut set", meaning that if that set of
RBridges is removed, the regions are disconnected from each other.
RBridges in the cut set can be configured to translate some set of
VLAN IDs in one region to different VLAN IDs when forwarding from one
region to the other and/or to block encapsulated frames with certain
VLAN IDs. They can be similarly configured for priority.
This feature is accomplished solely by configuring RBridges in the
cut set. No other RBridges need even be aware that the feature is in
use. In particular, use of this feature has no effect on the path
followed by TRILL Data frames. The TRILL features of optimum routing
and of optional multi-pathing of both unicast and multi-destination
frames are unaffected.
This document explains how to implement this feature in RBridges. In
this document we usually will assume there are two regions, "East"
and "West", and RBridges RB1, RB2, and RB3 that interconnect the two
regions and constitute the cut set as shown in Figure 1. Extension to
more than two regions is straightforward and will also be briefly
described.
. . . +-----+ . . .
. . . + - - - - + RB1 + - - - - + . . .
. W . +-----+ . . E .
. e . . . a .
. s . +-----+ . s . .
. t . .+ - - - - -+ RB2 + - - - - - - +. t .
. . . -+-+---+ . . .
. R . . / | _ _ _ _ _ _+. R . .
e . + - - - | / . e . .
. g . . +-+---+ . g . .
. i . .+ - - - -+ RB3 + - - - - - - - +. i . .
. o . . +-----+ o . .
. n . . . n . .
Figure 1.
General familiarity with the TRILL base protocol standard [RFCtrill]
is assumed in this document.
R. Perlman, et al. [Page 4]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
1.2 Terminology
The same terminology and acronyms are used in this document as in
[RFCtrill]. "Cut set" is defined above. We will refer to RBridges
other than the cut set of RBridges as "internal RBridges".
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 5]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
2. Internal and Cut Set RBridge Configuration and Mappings
Internal RBridges will not be aware that VLAN and priority mapping is
going on and require no configuration. They will behave exactly as
they would without mapping. The only evidence they will have of VLAN
or priority mapping is the existence of an optional informational TLV
that a cut set RBridge, RB1, MAY include in its LSP, listing the
mappings that RB1 is configured to be performing. Internal RBridges
will ignore this information field. It is there for detection of
misconfiguration.
Cut set RBridges are configured as follows:
If VLAN A in region "East" is to be translated into VLAN B in region
"West", each cut set RBridge MUST be configured, for every 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 a TRILL Data frame with an Inner.VLAN of A
received by RB1 on a port configured to be in East and forwarded to a
port configured to be in West is forwarded with the Inner.VLAN
changed to B. It is possible to configure asymmetric mappings and
also to indicate that encapsulated frames in a particular VLAN are to
be dropped by showing them as mapped to the illegal VLAN zero;
however, such asymmetric or frame drop mappings may have negative
consequences as described below. For the above mapping to be
symmetrically configured, it would be necessary to also configure the
cut set RBridge in question so that frames arriving from West in VLAN
B would also be mapped to VLAN A if they are destined for East, that
is
"West/VLAN B <-----> East/VLAN A"
Figure 2.
Mappings of the priority of encapsulated frames are configured in the
same way except that, since priority values 0 to 7 are allm legal,
the non-existent priority value of 8 is permitted to indicate that
frames are dropped.
The requirement that every port of a cut set RBridge MUST be
configured as to which region it is in applies even to ports for a
link between cut set RBridges such as the link between RB2 and RB3 in
Figure 1. The TRILL encpasulated data frames on that link have a
normal Inner.VLAN with a VLAN ID and priority. In a campus with
multiple regions, a VLAN ID or priority is, in general, meaningless
unless you know the region in which it occurs. So some specific
region must be chosen for such a link.
R. Perlman, et al. [Page 6]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
All cut set RBridges between a pair of regions SHOULD be configured
similarly if, as is normally the case, it is desired that the mapping
of a TRILL Data frame going between those regions will be independent
of which cut set RBridge the frame traverses.
The default VLAN and priority mapping is the identity mapping. If a
mapping has been specified for both the VLAN and priority of a frame,
both mappings are applied. The frame is dropped if either mapping
indicates it should be dropped.
2.1 Multiple Crossings
Under some circumstances, a frame could pass through cut set RBridges
between a pair of regions more than once and thus have its VLAN and
priority mapped more than one. For example, in Figure 3, if the link
between RBwest1 and RBwest2 fails, then the shortest path from
RBwest1 to RBwest2 may be through RBcut1, RBeast1, and RBcut2.
---+
| |
+--+------+ +--------+ |
---+ RBwest1 +------+ RBcut1 +-------+ | +---
+-+---+---+ +--------+ | | |
| | +-+--+--+-+
---+ | | RBeast1 +---
| +-+--+--+-+
+-----+---+ +--------+ | | |
---+ RBwest2 +------+ RBcut2 +-------+ | +---
+--+------+ +--------+ |
| |
---+
Figure 3.
If all of the mappings at RBcut1 and RBcut2 are symmetric then the
VLAN and/or priority of such frames going from west to west via east
might get mapped twice but the second mapping would restore them to
their original value. Symmetric means, for example, that if RB1 is
translating from "VLAN A" to "VLAN B" when forwarding from East to
West, it will translate tag "VLAN B" to tag "VLAN A" when forwarding
from West to East (see Figure 2).
However, assume that RBcut1 and RBcut2 are configured to map VLAN A
to zero both ways, dropping VLAN A frames. This might be to keep VLAN
A frames confined to each region so there would be no connectivity
between a pair of VLAN A end stations if they were in different
regions. If so, the failure of the link between RBwest1 and RBwest2
partitions VLAN A in the West region since the RBridges will try to
R. Perlman, et al. [Page 7]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
forward the frames via RBcut1-RBeast1-RBcut2 and they will be dropped
at RBcut1 or RBcut2; however, it does achieve the goal of keeping
West VLAN A frames out of East and East VLAN A frames out of West.
Similarly, if there are asymmetric mappings, multiple cut set transit
may cause problems. For example, if VLAN A in west is mapped to VLAN
B in east and VLAN B in east is mapped to VLAN C in west, then the
above scenario could lead to frames in VLAN A from west to west being
unexpectedly mapped to VLAN C causing connectivity between VLANs A
and C in west. Similar considerations apply to priority mappings.
The probability of such situations can be minimized by providing rich
interconnectivity within each region and, if necessary, increasing
the cost of links to cut set RBridges, so that frames internal to a
regions will be routed internally to that region except in cases of
low probability multiple failures. It is generally safest to
configure symmetric mappings.
2.2 Native Frame Considerations
If the processing model described in [RFCtrill] is followed, then no
special handling is necessary for the case where a cut set RBridge
receives or transmits a native data frame, that is, where the cut set
RBridge is also an ingress or egress RBridge. In particular, the
processing model used in [RFCtrill] provides that an ingressed native
frame is always encapsulated, even if it is to be immediately
decapsulated and delivered out a different port in native form. (Of
course, implementers are free to handle this in other ways provided
the external behavior is the same.) Thus, following this processing
model, no changes are needed in an implementation model of VLAN and
priority mapping described entirely in terms of the manipulation of
TRILL encapsulated frames.
On the other hand, if there are no RBridges in a region, say region
West in Figure 1, then all frames will arrive from that region at the
cut set RBridges as unencapsulated native frames and all native
frames sent into that region will be unencapsulated. Under these
limited circumstances, traditional bridge port VLAN and priority
mapping could work to perform the inter-regional mappings described
in this document.
2.3 More than Two Regions
An RBridge campus may have more than two regions. An RBridge is in
the cut set between any pair of such regions if and only if it has at
least one port in each of the regions. There may be pairs of regions
that, because of intervening regions, have no cut set RBridges
R. Perlman, et al. [Page 8]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
connected to them both.
Every RBridge that is in any cut set MUST have every port configured
as to which region that port is in. Every RBridge port on a link
between two or more cut set RBridges, such as that shown between RB2
and RB3 in Figure 1, SHOULD be configured to be in the same region.
The mappings performed on TRILL data frames transiting a cut set
RBridge that has ports in three or more regions depend only on the
region of that frame's input and output ports and are unaffected by
what region any other ports of that RBridge might be connected to.
It is RECOMMENDED that not only should any mappings be symmetric at
every cut set RBridge in a campus that implements the VLAN and
priority mapping feature but that all cut set RBridges in the campus
should be configured so as to be transitively symmetric and similar.
That is, the mapping of the VLAN and priority in a frame going from
region A to region Z should be independent of the path that frame
follows in the campus and symmetric with the mapping to which any
frame going from region Z to region A would be subjected.
2.4 Mapping Implementation
If RB1 is configured to believe port X is in "East" and port Y is in
"West", and RB1 is configured such that "East/VLAN A ----> West/VLAN
B", then when RB1 forwards data frames from port X to port Y, if the
received frame from port X has Inner.VLAN tag VLAN ID equal to VLAN
A, then RB1 changes that VLAN ID from VLAN A to VLAN B before it
forwards onto port Y. Similarly, if priority mapping has been
configured, the Inner.VLAN priority field is mapped.
Note: This mapping is performed whether RB1 is the appointed
forwarder on port X for VLAN A and the frame arrives unencapsulated,
or whether the frame has arrived already encapsulated as a TRILL Data
frame. Likewise, RB1 performs the same VLAN translation, depending
on input and output port, whether the frame is to a known unicast
address or is multi-destination.
RBridges may implement campus region VLAN and priority mapping in any
way desired so long as the externally visible behavior matches this
specification. Two example models of internal processing are
described below.
In the forwarding-oriented model, VLAN and priority mappings occur
once as part of the inter-port forwarding process and depend on
the ordered pair on input-port-region and output-port-region.
If the port-oriented model, VLAN and priority mappings occur once
or twice associated with input and/or output ports. For example,
R. Perlman, et al. [Page 9]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
for VLANs, each input port of a cut set RBridge would (after
encpasulation in the case of a native frame) map the Inner.VLAN to
a value in an RBridge specific general VLAN space, with the
mapping dependent only on the region to which that input port was
assigned. Then, the output port through which the frame was sent
would map from that general VLAN space to a specific VLAN in the
Inner.VLAN of the transmitted frame with the mapping depending
only on the region to which the output port was assigned. Either
mapping could be the identity mapping in some cases. (In the
general case, particularly for an RBridge with ports in more than
two regions and many VLANs being mapped, the RBridge specific
general VLAN space might have to be larger than 2**12.) A similar
model could be used for priority mapping with similar
considerations.
These two models are logically interchangeable.
3. End Node Address Learning Between Regions
RBridges by default learn end node MAC addresses and VLANs from the
observation of ingressed native frames and the decapsulation of
native frame at egress, as described in [RFCtrill]. This process
requires no modification at internal RBridges to accommodate VLAN
mapping as described herein as the VLAN will be appropriate for the
region where it is observed.
For a cut set RBridge, each port is specified to be in a particular
region. For such an RBridge, the VLAN portion of the addresses
learned at a port providing direct end station service will be that
VLAN in the region to which the cut set RBridge has assigned the
port. Care must be taken within a cut set RBridge when using such
learned information. For example, if a native frame is received in
VLAN X from region Y destined for MAC address Z, then address Z can
be looked up in the address information learned for other regions
only after applying any mapping for VLAN X to that region or possibly
not at all if that mapping would call for VLAN X frames to be
dropped.
TRILL also allows RBridges to optionally advertise attached end
nodes. This end node advertisement uses the TRILL ESADI (End System
Address Distribution Information) protocol. Because TRILL ESADI
frames do not include the VLAN to which they are applicable anywhere
except in their Inner.VLAN tag and ESADI frames are forwarded just
like ordinary multi-destination TRILL Data frames, the VLAN mapping
described above works for ESADI learning. Because of this, any future
ESADI extensions MUST NOT require VLAN ID fields inside the ESADI
frame payload.
R. Perlman, et al. [Page 10]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
4. Cut Set RBridge Attraction of VLANs and Multicast
The above described mechanisms are all that is required for VLAN and
priority mapping of frames sent to know unicast addresses. However,
to correctly handle multi-destination traffic, additional steps are
required. In particular, unless cut-set RBridges take additional
actions, multi-destination frames that they need to forward from one
region to another might not reach the cut set RBridge due to the
optional pruning of distribution trees by internal RBridges.
If RB1 is configured to translate VLAN A in East to VLAN B in West,
then RB1 MUST report, 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. If it did not do this, a multi-destination frame in
VLAN A in East might be pruned before reaching RB1 and not mapped to
VLAN B and forwarded to West as it should.
If RB1 is configured to translate VLAN A in East to VLAN B in West,
then RB1 MUST take steps to ensure that a multicast packet for group
G in VLAN A will not be filtered inside the East region. To solve
this problem RB1 MUST report that it is connected in VLAN A to an
IPv4 and IPv6 multicast router so it will get all multi-cast traffic
in VLAN A and can forward appropriate multicast frames mapped to VLAN
B. While this increases traffic to cut set RBridges, it does so to an
extent no worse that an RBridge connected to an actual Layer 3
multicast router or routers.
Cut set RBridges and the links connecting them to the rest of the
network should be appropriately engineered for any additional traffic
load these requirements impose.
5. Advertisement of VLAN and Priority Mappings
To help detect misconfiguration, a cut set RBridge RB1 MAY advertise
its VLAN and priority mappings in its LSP. To enable this, a 16-bit
unsigned ID is assigned to each of the regions by manual
configuration. All cut set RBridges SHOULD be configured with the
same IDs for the regions but means of accomplishing this are outside
of the scope of this document. So, in our example Figure 1, if
"East" is "1" and "West" is "2", and VLAN A in East is mapped to VLAN
B in West, and vice versa to be symmetric, the LSP would report a set
of mappings, including:
{VLAN: (1:A,2:B), (1:B,2:A)}
A mapping to VLAN zero indicates the frame is to be dropped and a
mapping to illegal VLAN 0xFFF is ignored. A mapping from VLAN zero or
0xFFF is ignored.
R. Perlman, et al. [Page 11]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
Similarly, priority mappings MAY be advertised. The priority 8 is
allowed as a "to" priority to indicate that the frame is to be
dropped. A priority mapping is ignored if it specified a "from"
priority outside of 0 through 7 inclusive or a "to" priority outside
of 0 through 8 inclusive.
5.1 VLAN Advertisement TRILL Sub-TLV
The following sub-TLV is used by a cut set RBridge to optionally
advertise that it has VLAN mapping configured. This sub-TLV can only
occur in the TRILL GenApp TLV as described in Section 6.
+-+-+-+-+-+-+-+-+
| subType = VMAP|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+----------...
| VLAN Mapping 1 (8 bytes)
+-+-+-+-+-+-+-+------------...
| VLAN Mapping N, etc.
+--------------------------...
o Type: TRILL GenApp sub-TLV Type, set to VMAP sub-TLV 1.
o Length: variable, 8*n where n is the number of mapping entries.
o Value: Specific information on each VLAN mapping or block of VLAN
mappings as diagrammed and specified below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | From VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| From Region | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|R|R|R| To VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| To Region | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Count: If this four bit unsigned integer is zero or 1, then the
mapping of a single VLAN ID is being specified. If it is any
value from 2 through 15, then a block of that many contiguous VLAN
IDs counting up starting with the From VLAN ID is mapped to a
block of that many contiguous VLAN IDs starting with the To VLAN
ID. For this purpose, the "next" VLAN after 0xFFE is considered to
by VLAN 0x001. The From and To Regions are the same for each
mapping.
R. Perlman, et al. [Page 12]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
o From VLAN ID: This is the VLAN ID that, when received on a port
connect to the From Region on a frame being sent to the To Region,
is mapped to the To VLAN ID. This must be a real VLAN ID, that is,
the values 0x000 and 0xFFF are prohibited and mappings in which
they occur are ignored.
o From Region: This is the region number, within the campus, such
that frames received on a port connected to that region and
destined to a port connected to the To Region have their VLAN ID
mapped as specified by the From VLAN ID and To VLAN ID fields.
o S bit: The Symmetric bit. If this bit is one, then this Mapping
entry indicates that there is also a second mapping, or block of
mappings if the Count is non-zero, identical except that the From
Region and From VLAN ID are interchanged with the To Region and To
VLAN ID.
o R bits: These three bits are reserved and MUST be sent as zero and
ignored on receipt.
o To VLAN ID: This is the VLAN ID to be used on frames sent out a
port connected to the To Region if they were received on a port
connected to the From Region with the From VLAN ID; except that if
the To VLAN ID is 0x000 the frame is dropped. The invalid VLAN ID
value 0xFFF is prohibited in this field and if it occurs the
mapping is ignored.
o To Region: This is the region number, within the campus, such that
frames sent on a port connected to this region from a port
connected to the From Region have their VLAN ID mapped as
specified by the From VLAN ID and To VLAN ID fields.
5.2 Priority Advertisement TRILL Sub-TLV
The following sub-TLV is used by a cut set RBridge to optionally
advertise that it has priority mapping configured. This sub-TLV can
only occur in the TRILL GenApp TLV as described in Section 6.
+-+-+-+-+-+-+-+-+
| subType = PMAP|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+----------...
| Priority Mapping 1 (8 bytes)
+-+-+-+-+-+-+-+------------...
| Priority Mapping N, etc.
+--------------------------...
R. Perlman, et al. [Page 13]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
o Type: TRILL GenApp sub-TLV Type, set to PMAP sub-TLV 2.
o Length: variable, 9*n where n is the number of mapping entries.
o Value: Specific information on each priority mapping as shown and
specified below:
+-+-+-+-+-+-+-+-+
|S| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| From Region | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| To Region | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 to | 1 to | 2 to | 3 to | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 to | 5 to | 6 to | 7 to | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o S Bit: Symmetric bit. This indicates that the cut set RBridge
advertising this mapping is also performing the inverse priority
mapping computed as follows: initialize the inverse mapping array
of eight hex nibbles so that each entry is some illegal value such
as 15; go through all the To mapping entries in the sub-TLV and
for each one, where j is the entry you are working from and k is
the priority to which j is mapped in the sub-TLV, perform the
following:
o If k is >8, the input mapping has an illegal entry. Ignore the
symmetric bit and do not assume any inverse mapping.
o If k = 8, set entry j in the inverse map to 8.
o If k < 8, set entry k in the inverse map to j.
After performing the above for all entries in the sub-TLV, scan
the inverse map and, if any entries are still set to the illegal
value to which they were initialized, the attempt to calculate an
inverse has failed. Ignore the symmetric bit and do not assume any
inverse mapping. If all entries in the inverse map are legal, that
is from 0 through 8 inclusive, the complete inverse map is legal
and gives the mapping that the advertising cut set RBridge says it
will perform on frame going from the "To Region" to the "From
Region" as listed in the sub-TLV.
o RESV: Reserved. MUST be sent as zero and ignored on receipt.
o From Region: This is the region number, within the campus, such
that frames received on a port connected to that region and
destined to a port connected to the To Region have their priority
mapped as specified below.
R. Perlman, et al. [Page 14]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
o To Region: This is the region number, within the campus, such that
frames sent on a port connected to this region from a port
connected to the From Region have their priority mapped as
specified below.
o "To n" Fields: This is an array of 8 unsigned hex nibbles that
give the priority to which each of the 8 priority levels (0
through 7) is mapped. Mapping a priority to 8 indicates that such
frames should be dropped. A mapping to any value from 9 through 15
is prohibited and such mapping are ignored, resulting in the
corresponding From priority being unchanged.
R. Perlman, et al. [Page 15]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
6. TRILL GenApp TLV
Since the optional advertisement of VLAN and priority mappings has no
effect on IS-IS routing, the GenApp TLV is used to advertise this
information. As specified in Section 7, a GenApp [GenApp] Application
ID is allocated for TRILL.
The contents of the TRILL GenApp TLV is as follows:
+-+-+-+-+-+-+-+-+
| Type=GenApp | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| GenApp Flags | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application IP Address Info (0 to 20 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to GenApp 251 [TBD].
o Length: variable depending on the IP address and sub-TLVs carried.
o GenApp Flags: As specified in [GenApp]. Currently not used in
TRILL, which operates as a single level one area, and thus should
be zero. Some future TRILL use may require one or more to be set.
o Application ID: The GenApp application ID allocated for TRILL as
specified in Section 7 below.
o Application IP Address Info: As specified in [GenApp]. Currently
not used in TRILL and thus should be zero length. Some future
TRILL use may require address information here.
o sub-TLVs: The remaining TRILL GenApp value consists of TRILL
GenApp sub-TLVs formatted as described in [RFC5305].
R. Perlman, et al. [Page 16]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
7. IANA Considerations
IANA allocates 0xTBDX as the GenApp identifier for TRILL.
IANA establishes a TRILL GenApp Sub-TLV subregistry as follows:
Sub-TLV Status
------- ------
0 Reserved.
1 VLAN mapping advertisement.
2 Priority mapping advertisement.
3-254 Available for allocation based on IETF Review.
255 Reserved.
Reserved values in the table above require an IETF Standards action
for allocation.
8. 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, which could violate security policies.
However, misconfiguration of VLAN or priority mappings cannot cause
loops because mappings of VLANs and/or priority have no effect on
frame routing, shortest path calculations, distribution tree
construction or selection, or the like.
R. Perlman, et al. [Page 17]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
9. Normative References
[GenApp] - Ginsberg L., S. Previdi, M. Shand, "Advertising Generic
Information in IS-IS", draft-ietf-isis-genapp, Work in
Progress.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFCtrill] - R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
trill-rbridge-protocol-16.txt, in RFC Editor's Queue.
10. Informative References
None.
R. Perlman, et al. [Page 18]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
Appendix Z: Change Summary and RFC Editor Notes
RFC Editor Notes:
1. Please delete Appendix Z and these notes on publication.
2. Please replace all occurrences of [RFCtrill] and [GenApp] with
references including the actual RFC numbers, i.e., something like
[RFC1234].
3. Please replace all occurrences of 0xTBDX with the hex of the
actual TRILL GenApp code allocated by IANA, i.e., something like
0x0123.
Changes from -00 to -01
1. Because RBridges cannot tell what cloud other RBridges are in,
drop the "optimized" option for advertising multicast listeners
and require the advertisement of multicast router connectivity.
2. Specify that the cloud connectivity must be specified for all cut
set RBridges and that cloud IDs are manually configured and are 16
bit.
3. Expand rules for VLAN ID mapping/handling at a cut set RBridge so
as to drop frames that are for a VLAN ID to which another VLAN ID
is being mapped. (See Section 3.)
4. Add mention of "VLAN ID translation", the 802.1 name for VLAN
mapping.
5. Minor editing changes.
Changes from -01 to -02
1. Remove previous confused text about VLAN mapping (point 3 in
changes from -00 to -01).
2. Add text allowing mapping to zero to indicate frames should be
dropped. Add text and diagram explaining that this can lead to
VLAN partition.
3. Add normative reference to draft-ietf-isis-layer2.
4. Minor editing changes.
R. Perlman, et al. [Page 19]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
Changes from -02 to -03
This was a substantial re-write of the draft but there was no
fundamental conceptual change in the mapping mechanism.
1. Replace "cloud" with "region".
2. Introductory material was re-written to primarily reference
RBridge campuses and reduce references to 802.1 bridges.
3. Mapping of priority was added to mapping of VLANs.
4. Two different models are now described for implementation of
mappings, one in the forwarding mechanism as before and one
associated with the RBridge ports.
5. Add the specification of the TRILL GenApp TLV. Switch to using
TRILL GenApp TLV sub-TLVs to advertise VLAN and priority mappings.
Add specification of those sub-TLVs.
6. The IANA considerations section calls for the allocation of a
GenApp TLV code for TRILL and provides for sub-TLVs under that
code where the LSP advertisement of VLAN and priority mappings was
moved. Set up IANA registry for TRILL GenApp sub-TLVs.
R. Perlman, et al. [Page 20]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
Authors' Addresses
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054-1549 USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Dinesh G. Dutt
Cisco Systems
170 Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1-408-527-0955
Email: ddutt@cisco.com
Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134 USA
Email: ayabaner@cisco.com
Donald Eastlake 3rd
Stellar Switches, Inc.
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-333-2270
Email: d3e3e3@gmail.com
R. Perlman, et al. [Page 21]
INTERNET-DRAFT RBridges: VLAN and Priority Regions
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2010 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 BSD License. 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 22]
| PAFTECH AB 2003-2026 | 2026-04-23 17:24:01 |