One document matched: draft-ietf-trill-rbridge-protocol-06.txt
Differences from draft-ietf-trill-rbridge-protocol-05.txt
TRILL Working Group Radia Perlman
INTERNET-DRAFT Sun Microsystems
Intended status: Proposed Standard Donald Eastlake 3rd
Motorola Laboratories
Silvano Gai
Nuova Systems
Dinesh G. Dutt
Cisco
Expires: May 2008 November 2007
Rbridges: Base Protocol Specification
<draft-ietf-trill-rbridge-protocol-06.txt>
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list <rbridge@postel.org>.
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, D. Eastlake, S. Gai, D. Dutt [Page 1]
INTERNET-DRAFT RBridge Protocol
Abstract
RBridges allow for optimal pair-wise forwarding with zero
configuration, safe forwarding even during periods of temporary
loops, and multipathing for both unicast and multicast traffic. They
achieve these goals using IS-IS routing and encapsulation of traffic
with a header that includes a hop count.
RBridges are compatible with previous IEEE 802.1 bridges as well as
current IPv4 and IPv6 routers and end nodes. They are as invisible to
current IP routers as bridges are and, like routers, they terminate
the bridge spanning tree protocol.
The design supports VLANs, and, optionally, optimization of the
distribution of multi-destination frames based on VLAN and IP derived
multicast groups. It also allows forwarding tables to be based on
RBridge destinations (rather than end node destinations), which
allows internal forwarding tables to be substantially smaller than in
conventional bridge systems.
Acknowledgements
Many people have contributed to this design, including, in alphabetic
order, Alia Atlas, Caitlin Bestler, Stewart Bryant, James Carlson,
Dino Farinacci, Don Fedyk, Eric Gray, Joel Halpern, Erik Nordmark,
Sanjay Sane, and Joe Touch. We invite you to join the mailing list at
http://www.postel.org/rbridge.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 2]
INTERNET-DRAFT RBridge Protocol
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Introduction............................................6
1.1 Algorhyme V2, by Ray Perlner...........................7
1.2 Conventions used in this document......................7
2. RBridges................................................8
2.1 End Station Addresses..................................9
2.2 RBridge Architecture...................................9
2.3 RBridges and VLANs....................................11
2.4 Forwarding of Different Frame Types...................12
2.4.1 Known-Unicast.......................................13
2.4.2 Multi-destination...................................13
3. Details of the TRILL Header............................14
3.1 TRILL Header Format...................................14
3.2 Version (V)...........................................14
3.3 Reserved (R)..........................................15
3.4 Multi-destination (M).................................15
3.5 TRILL Header Options..................................15
3.6 Hop Count.............................................16
3.7 RBridge Nicknames.....................................16
3.7.1 Egress RBridge Nickname.............................17
3.7.2 Ingress RBridge Nickname............................17
3.7.3 RBridge Nickname Allocation.........................18
4. Other RBridge Design Details...........................20
4.1 Ethernet Data Encapsulation...........................20
4.1.1 VLAN Tag Information................................21
4.1.2 Outer VLAN Info.....................................22
4.1.3 Inner VLAN Info.....................................23
4.1.4 Frame CheckSum (FCS)................................24
4.2 Link State Protocol (IS-IS)...........................24
4.2.1 IS-IS RBridge Identity..............................24
4.2.2 IS-IS Instances.....................................25
4.2.3 TRILL IS-IS Information.............................25
4.2.3.1 Core IS-IS Information............................25
4.2.3.2 Optional Per-VLAN IS-IS Instance Information......27
4.2.4 Designated RBridge..................................27
4.2.5 Appointed VLAN-x Forwarder..........................28
4.3 Distribution Trees....................................29
4.3.1 Distribution Tree Calculation and Checks............30
4.3.2 Pruning the Distribution Tree.......................31
4.3.3 Forwarding Using a Distribution Tree................32
4.4 Forwarding Behavior...................................33
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 3]
INTERNET-DRAFT RBridge Protocol
Table of Contents Continued
4.4.1 Receipt of a Native Frame...........................33
4.4.1.1 Native Unicast Case...............................33
4.4.1.2 Native Multicast and Broadcast Frames.............34
4.4.2 Receipt of a Non-Native (TRILL) Frame...............34
4.4.2.1 TRILL IS-IS Frames................................35
4.4.2.2 TRILL Data Frames.................................35
4.4.3 Tree Distribution Optimization......................37
4.5 IGMP, MLD, and MRD Learning...........................37
4.6 End Station Address Details...........................38
4.6.1 Learning End Station Addresses......................39
4.6.2 Forgetting End Station Addresses....................40
4.7 Shared VLAN Learning..................................40
5. Pseudo Code............................................41
5.1 802MUL Destination Frames.............................41
5.1.1 All Bridges Frames..................................43
5.1.2 Media Multicast Frames..............................43
5.1.3 802.1X Frames.......................................43
5.1.4 802.1AB Frames......................................44
5.1.5 GARP, GMRP, and GVRP................................44
5.1.6 Other Bridge Multicast Frames.......................45
5.2 Processing a Frame Received by an RBridge.............45
5.2.1 Further Dispatch for IP Frames......................46
5.2.2 Common Subroutines..................................46
5.2.2.1 Learn Source MAC Address..........................46
5.2.2.2 TRILL Frame Multi-destination Forwarding..........47
5.2.2.3 TRILL Data Frame Tree Transmission................47
5.2.2.4 TRILL Data Frame Transmission.....................48
5.2.3 TRILL Ethertype Frames..............................48
5.2.3.1 TRILL IS-IS Frames................................48
5.2.3.2 TRILL Data Frames.................................49
5.2.4 Native Frame Receipt................................50
5.2.4.1 Native IPv4 Multicast Frame.......................52
5.2.4.2 Native IPv6 Multicast Frame.......................53
5.2.5 IGMP and MLD Frames.................................54
5.2.6 MRD Frames..........................................54
5.3 Frames Spontaneously Sourced..........................54
5.3.1 Bridge/Media Frames Sourced.........................54
5.3.2 IS-IS Frames Sourced................................55
5.3.2.1 Core IS-IS Frames.................................55
5.3.2.2 Per-VLAN IS-IS Frames.............................56
5.3.3 Other Frames Sourced................................57
6. Incremental Deployment Considerations..................58
6.1 VLAN Connectivity Changes.............................58
6.2 Link Cost Determination...............................58
6.3 Appointed Forwarders and Bridged LANs.................59
6.4 Wiring Closet Topology................................60
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 4]
INTERNET-DRAFT RBridge Protocol
Table of Contents Continued
6.4.1 The RBridge Solution................................61
6.4.2 The Spanning Tree Solution..........................61
6.4.3 The VLAN Solution...................................62
6.4.4 Comparison of Solutions.............................62
7. RBridge Addresses, Parameters, and Constants...........64
8. Security Considerations................................65
9. Assignment Considerations..............................66
9.1 IANA Considerations...................................66
9.2 IEEE 802 Assignment Considerations....................66
10. Normative References..................................67
11. Informative References................................68
Appendix A: Revision History..............................69
Changes from -03 to -04...................................69
Changes from -04 to -05...................................70
Changes from -05 to -06...................................71
Disclaimer................................................72
Additional IPR Provisions.................................72
Authors' Addresses........................................73
Expiration and File Name..................................73
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 5]
INTERNET-DRAFT RBridge Protocol
1. Introduction
In traditional IPv4 and IPv6 networks, each subnet has a unique
prefix. Therefore, a node in multiple subnets has multiple IP
addresses, typically one per interface. This also means that when an
interface moves from one subnet to another, it changes its IP
address. Administration of IP networks is complicated because IP
routers require significant configuration and careful IP address
management is required to avoid creating subnets that are sparsely
populated and waste addresses. IEEE 802.1 bridges avoid these
problems by transparently gluing many physical links into what
appears to IP to be a single LAN [802.1D].
Bridge forwarding using the spanning tree protocol has some
disadvantages:
o The spanning tree protocol blocks ports, limiting the number of
forwarding links, and therefore creates bottlenecks by
concentrating traffic onto selected links.
o The Ethernet header does not contain a hop count (or TTL) field
and this is dangerous when there are temporary loops such as when
spanning tree messages are lost or components such as repeaters
are added.
o VLANs can partition, perhaps unexpectedly, when spanning tree
reconfigures due to a node failure or topology change.
o Forwarding is not pair-wise shortest path, but is instead whatever
path remains after the spanning tree eliminates redundant paths.
This document presents the design for RBridges (Routing Bridges
[RBridges]) which implement the TRILL protocol and are poetically
summarized below. Rbridges combine the advantages of bridges and
routers. While they can be applied to a variety of link protocols,
this specification concentrates on IEEE 802.3 links [802.3].
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 6]
INTERNET-DRAFT RBridge Protocol
1.1 Algorhyme V2, by Ray Perlner
I hope that we shall one day see
A graph more lovely than a tree.
A graph to boost efficiency
While still configuration-free.
A network where RBridges can
Route packets to their target LAN.
The paths they find, to our elation,
Are least cost paths to destination!
With packet hop count we now see,
The network need not be loop-free!
RBridges work transparently.
Without a common spanning tree.
1.2 Conventions used in this document
"TRILL" normally refers to the protocol specified herein while
"RBridge" refers to the devices which implement that protocol. The
second letter in Rbridge is case insensitive. Both Rbridge and
RBridge are correct.
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, D. Eastlake, S. Gai, D. Dutt [Page 7]
INTERNET-DRAFT RBridge Protocol
2. RBridges
RBridges run a link state protocol amongst themselves. This enables
them to have enough information to compute pair-wise optimal paths
for unicast, and to calculate distribution trees for delivery of
frames either to unknown MAC destinations, or to multicast/broadcast
groups. [RBridges] [RP1999]
To mitigate temporary loop issues, RBridges forward based on a header
with a hop count. RBridges also specify the next hop RBridge as the
frame destination when forwarding unicast frames across a shared-
media link, which avoids spawning additional copies of frames during
a temporary loop. A Reverse Path Forwarding Check and other checks
are performed on multi-destination frames.
The first RBridge that a unicast frame encounters in a campus, RB1,
encapsulates the received frame with a TRILL header that specifies
the last RBridge, RB2. RB1 is known as the "ingress RBridge" and RB2
is known as the "egress RBridge". To save room in the TRILL header,
a dynamic nickname acquisition protocol is run among the RBridges to
select a 2-octet nickname for each RBridge, unique within the campus,
which is an abbreviation for the 6-octet IS-IS system ID of the
RBridge. The 2-octet nicknames are used to specify the ingress and
egress RBridges in the TRILL header.
Multipathing of multi-destination frames through alternative
distribution tree roots and ECMP (Equal Cost MultiPath) of unicast
frames are enabled but not fully specified in this document.
Multipathing may introduce frame reordering as can frame priorities
or changes in network topology.
RBridges run the IS-IS election protocol to elect a "Designated
RBridge" (DRB) on each bridged LAN ("link"). As with an IS-IS
router, the DRB gives a pseudonode name to the link, issues an LSP on
behalf of the pseudonode, and issues CSNPs on the link.
Additionally, the DRB specifies which VLAN will be the common VLAN to
use for communication between RBridges on that link. The DRB either
encapsulates/decapsulates all data traffic to/from the link, or for
load splitting, delegates this responsibility, for one or more VLANs,
to other RBridges on the LAN. There must at all times be at most one
RBridge on the bridged LAN that encapsulates/decapsulates traffic for
a particular VLAN. We will refer to the RBridge appointed to forward
VLAN x traffic on behalf of the link as the "appointed VLAN-x
forwarder". (Section 2.3 discusses further implications of VLANs.)
Rbridges can be managed with SNMP [RFC3410]. The Rbridge MIB will be
specified in a separate document. This management can be used,
within a campus, even by an RBridge that lacks an IP or other Layer 3
transport stack or which is zero configuration and has no Layer 3
address, by transporting SNMP with Ethernet (see [RFC4789]).
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 8]
INTERNET-DRAFT RBridge Protocol
2.1 End Station Addresses
An RBridge, RB1, that is the VLAN-x forwarder on any of its links
MUST learn the location of VLAN-x endnodes, both on the links for
which it is VLAN-x forwarder, and on other links in the campus. RB1
learns the location and Layer 2 addresses of endnodes on links for
which it is VLAN-x forwarder from the source address of frames, as
bridges do (for example, see section 8.7 of [802.1Q]). RB1 learns the
Layer 2 address of distant VLAN-x end nodes, and the corresponding
RBridge to which they are attached, by looking at the ingress RBridge
nickname in the TRILL header and the source address in the inner
frame header of TRILL data frames that it is decapsulating onto a
link.
Additionally, a VLAN-x instance of IS-IS MAY be used by the appointed
VLAN-x forwarder on a link to announce some or all of the attached
VLAN-x end nodes on that link. The intention is that such an
announcement would be used to announce end nodes that have been
explicitly enrolled, and so such information would be more
authoritative than simply learning from data packets being
decapsulated onto the link. Also, it can be more secure because not
only might the enrollment be cryptographically authenticated (for
example by [802.1X]), but IS-IS also supports cryptographic
authentication of its messages. But even if a per-VLAN instance is
used to announce attached end nodes, RBridges MUST still learn from
decapsulating data packets unless configured not to do so. Conflicts
are resolved using a confidence level reported with the address in
the per-VLAN IS-IS data.
Advertising end nodes using a per-VLAN instance of IS-IS is optional,
as is learning from these announcements.
(See Section 4.6 for further end station address details.)
2.2 RBridge Architecture
The Layer 2 technology used to connect Rbridges may be either IEEE
802.3 or some other technology such as PPP. This is possible since
the functionality of an RBridge relay entity is layered on top of the
Layer 2 technologies.
However, this document specifies only an IEEE 802.3 encapsulation
[802.3].
Figure 1 shows two RBridges RB1 and RB2 interconnected through an
Ethernet cloud. There are no restrictions on what may compose the
Ethernet cloud: point-to-point or shared media, hubs and 802.1
bridges. The Ethernet cloud may support VLAN tagging or not.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 9]
INTERNET-DRAFT RBridge Protocol
------------
/ \
+-----+ / Ethernet \ +-----+
| RB1 |----< >---| RB2 |
+-----+ \ Cloud / +-----+
\ /
------------
Figure 1. Interconnected RBridges
Figure 2 shows the format of a TRILL frame traveling through the
Ethernet cloud from RB1 to RB2.
+--------------------------------+
| Outer Ethernet Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
Figure 2. An Ethernet Encapsulated TRILL Frame
In the case of media different from Ethernet, the outer Ethernet
header is replaced by the header specific to that media. For example,
Figure 3 shows a TRILL encapsulation over PPP.
+--------------------------------+
| PPP Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
Figure 3. A PPP Encapsulated TRILL Frame
The outer header is link-specific and, although this document
specifies only Ethernet links, other links are allowed.
In both cases the Inner Ethernet Header and the Ethernet Payload are
derived from the original frame which is encapsulated with a TRILL
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 10]
INTERNET-DRAFT RBridge Protocol
header as it travels between RBridges for several reasons:
1. to mitigate loop issues a hop count field is included;
2. to prevent original source MAC learning in the core from frames in
transit;
3. to direct frames towards the egress RBridge. This enables
forwarding tables of RBridges to be sized with the number of
RBridges rather than the total number of end nodes; and,
4. to provide VLAN labeling to get the frame through bridged LANs
while preserving the original VLAN.
When forwarding unicast frames between RBridges across a shared-
media, the outer header contains the address of the next hop Rbridge,
to avoid frame duplication. Having the outer header specify the
transmitting RBridge as source address ensures that any bridges
inside the shared-media link will not get confused, as they might
given multipathing, if they were to see the original source or
ingress RBridge in the outer header.
2.3 RBridges and VLANs
A VLAN is a way to partition end nodes into different communities
[802.1Q]. The usual method of determining which community a frame
belongs to is based on the port from which it is received although
end stations can insert this information in a frame. Use of VLANs
requires configuration.
IEEE 802.1Q bridges have the capability of supporting multiple VLANs
over a single link by inserting/removing a VLAN tag in the frame.
Rbridges can be configured to provide similar VLAN support. Some end
nodes have the same capability. The VLAN tag is structured according
to IEEE 802.1Q. As shown in Figure 2, there are two places where such
tags may be present in a TRILL-encapsulated frame which is sent over
an IEEE 802.3 link: one in the outer header (outer VLAN) and one in
the inner header (inner VLAN). Inner and Outer VLANs are further
discussed in Section 4.1.
RBridges enforce delivery of an end station frame originating in a
particular inner VLAN only to other links in the same inner VLAN;
however, there are a few differences in the handling of VLANs between
RBridged LANs and 802.1 bridged LANs.
802.1 bridges will only forward a data frame over a link if that link
is configured to be part of the VLAN to which that frame belongs. (By
default a link belongs only to VLAN 1.) The GVRP (see [802.1Q])
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 11]
INTERNET-DRAFT RBridge Protocol
protocol and proprietary features of some bridges (i.e., "trunk
links") are designed to support full connectivity between all end
stations in a particular VLAN. However, bridges can be configured so
as to partition one or more particular VLANs into unconnected
islands. RBridges, on the other hand, have a campus wide view
through the IS-IS link state database and can use arbitrary outer
VLAN labeling for connectivity and to send data for any VLAN over any
link. As a result, RBridges connect all campus end stations in a
particular VLAN (unless those end stations are cut off by bridges or
configuration from access to any RBridge).
It is possible that a link which is a bridged LAN might be
partitioned with respect to some VLANs. If the bridged LAN were
partitioned with respect to, say, VLAN x, and RBridges RB1 and RB2
were to send IS-IS Hellos on that link tagged with VLAN x, they might
not see each other's Hellos, and as a result, both conclude they
should be DRB (Designated RBridge) on that link, both performing the
encapsulation/decapsulation of data packets to/from that link, and
thereby forming a loop. Therefore, it is important for RBridges to
tag IS-IS Hellos with a VLAN that is not partitioned on the link. If
the link is misconfigured, and the VLAN on which they are sending
Hellos is partitioned, TRILL provides mechanisms whereby the
duplicate DRBs will be detected and loops will be prevented.
By default, RBridges tag IS-IS Hellos with VLAN 1. However, an
RBridge MAY be configured to transmit Hellos on a set of VLANs, and
if elected DRB, to specify to the other RBridges on the link which
VLAN to tag Hellos with. Once the DRB, say RB1, is elected, and
specifies the VLAN, say VLAN x, on which to send Hellos, all RBridges
on the link, except the DRB, transmit Hellos tagged only with VLAN x,
and all RBridge-RBridge communication (including Hellos, forwarded
data packets, and LSPs) are tagged with VLAN x. To maximize the
probability that even if VLAN x is partitioned, other RBridges will
know that RB1 is the DRB, RB1 will continue to transmit Hellos on the
set of VLANs for which it is configured to send Hellos on. Note that
the set of VLANs RB1 is configured to send Hellos on need not be all
the VLANs that RB1 can send and receive on. An RBridge that is not
DRB MAY ignore any IS-IS messages (including Hellos) sent on any
VLANs other than the common VLAN. The DRB, however, MUST continue to
send and receive IS-IS Hellos on all VLANs that the DRB has been
configured to send Hellos on.
2.4 Forwarding of Different Frame Types
There are several types of transit frames between RBridges that are
forwarded differently. They are here classified into two main
categories: known-unicast and multi-destination.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 12]
INTERNET-DRAFT RBridge Protocol
2.4.1 Known-Unicast
These frames have an inner MAC destination Address (Inner.MacDA) that
is unicast and the egress RBridge for that destination MAC address
location is known to the ingress RBridge.
2.4.2 Multi-destination
These are frames that must be delivered to multiple destinations.
They are as follows:
1. frames for unknown unicast destinations: the Inner.MacDA is
unicast, but the ingress RBridge does not know its location;
2. frames for Layer 2 multicast addresses derived from IP multicast
addresses: the Inner.MacDA is multicast, from the set of Layer 2
multicast addresses derived from IPv4 [RFC1112] or IPv6 [RFC2464]
multicast addresses; these frames are handled somewhat differently
in different subcases:
2.1 IGMP [RFC3376] and MLD [RFC2710] multicast group membership
reports;
2.2 IGMP [RFC3376] and MLD [RFC2710] queries and MRD [RFC4286]
announcement messages;
2.3 other IP derived Layer 2 multicast frames;
3. frames for Layer 2 multicast addresses not derived from IP
multicast addresses: the Inner.MacDA is multicast, and not from
the set of Layer 2 multicast addresses derived from IPv4 or IPv6
multicast addresses;
4. frames for the Layer 2 broadcast address: the Inner.MacDA is
broadcast.
RBridges build distribution trees (see Section 4.3) and use these
trees for forwarding multi-destination frames.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 13]
INTERNET-DRAFT RBridge Protocol
3. Details of the TRILL Header
The section provides a textual and diagrammatic description of the
TRILL header. Section 4 below provides other RBridge design details,
and Section 5 gives pseudo-code.
3.1 TRILL Header Format
The TRILL header is shown in Figure 4 and is independent of the data
link layer used. When that layer is IEEE 802.3, it is prefixed with
the 16-bit TRILL Ethertype and is 64 bit aligned.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. TRILL Header
The header contains the following fields which are described in the
sections referenced.
o V (Version): 2-bits. See Section 3.2.
o R (Reserved): 2-bits. See Section 3.3.
o M (Multi-destination): 1-bit. See Section 3.4.
o Op-Length (Options Length): 5-bits. See Section 3.5.
o Hop Count: 6-bit unsigned integer. See Section 3.6.
o Egress RBridge Nickname: 16-bit address. See Section 3.7.1.
o Ingress RBridge Nickname: 16-bit address. See Section 3.7.2.
3.2 Version (V)
According to IEEE's Ethertype guidelines, a single Ethertype is
granted to a protocol and it is the protocol's responsibility to
structure the format of the protocol header so as to support future
revisions to the protocol. Adhering to this guideline, there is a two
bit Version field in the TRILL header. Version zero of TRILL is
specified in this document. An RBridge that sees a message with a
Version value it does not understand MUST silently discard the
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 14]
INTERNET-DRAFT RBridge Protocol
message because it may not be able to parse it.
3.3 Reserved (R)
The two reserved bits are reserved for future use in extensions to
the TRILL protocol. They MUST be zero on transmission and are ignored
on receipt.
3.4 Multi-destination (M)
The Multi-destination bit (see Section 2.4.2) indicates the frame is
to be delivered to a class of destination end stations via a
distribution tree. It specifies the meaning of the egress RBridge
nickname field as follows:
o M = 0 (FALSE) - the frame is unicast data or core TRILL IS-IS; the
egress RBridge nickname contains the nickname of the egress
Rbridge for a TRILL unicast data frame and is zero for a core
instance TRILL IS-IS frame;
o M = 1 (TRUE) - the egress RBridge nickname field contains the
nickname of the RBridge that is the root of the distribution tree.
This tree is selected by the ingress RBridge for a TRILL data
frame or by the source RBridge for a per VLAN TRILL IS-IS frame.
3.5 TRILL Header Options
The TRILL Protocol includes an option capability in the TRILL Header.
The Op-Length header field gives the length of the options in units
of 4 octets which allows up to 124 octets of options area. If Op-
Length is zero there are no options present; else, the options follow
immediately after the Ingress Rbridge Nickname field.
All Rbridges MUST be able to skip the number of 4-octet chunks
indicated by the Op-Length field in order to find the inner frame,
since RBridges must be able to find the destination MAC destination
address and VLAN tag in the inner frame. (Transit RBridges need such
information to filter VLANs, IP multicast, and the like. Egress
Rbridges need to find the inner frame to correctly decapsulate and
dispose of the inner frame.)
All transit Rbridges that do not implement any options MUST
transparently copy the options area in frames they forward.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 15]
INTERNET-DRAFT RBridge Protocol
Options will be further specified in later documents and are expected
to include provisions for hop-by-hop and ingress-to-egress options as
well as critical and non-critical options. A critical option is one
which must be understood to safely process a frame. A non-critical
option can be safely ignored.
Warning: Most RBridges are expected to be implemented to optimize the
simplest and most common cases of frame forwarding and processing.
The inclusion of any options may, and the inclusion of complex or
lengthy options almost certainly will, cause frame processing using a
"slow path" with markedly inferior performance to "fast path"
processing. Limited slow path throughput may cause such frames to be
lost.
3.6 Hop Count
The Hop Count field is a 6-bit unsigned integer. Each RBridge that is
about to forward a frame to another RBridge MUST check this field and
discard the frame if this field is zero. If this field is non-zero,
it MUST be decremented in the forwarded frame.
For known unicast frames, the ingress RBridge (or source RBridge for
a control frame) MUST set the Hop Count to at least the number of
RBridge hops it expects to the egress RBridge and SHOULD set it in
excess of that number to allow for alternate routing later in the
path.
For multi-destination frames, to minimize potential problems with
temporary loops when forwarding, the Hop Count SHOULD be set by the
ingress RBridge (or source RBridge for a control frame) to the
expected number of hops on that path to the most distant RBridge. To
accomplish this, RBridge RBn calculates, for each branch of the
distribution tree rooted at RBi, the maximum number of hops in that
branch. When forwarding a multi-destination frame onto a branch,
transit RBridge RBm MAY decrease the hop count by more than 1 to set
the hop count to be no more than necessary to reach all destinations
in that branch of tree rooted at RBi.
Although the RBridge MAY decrease the hop count by more than 1, the
RBridge forwarding a frame MUST decrease the hop count by at least 1,
and discard the packet if the hop count becomes 0.
3.7 RBridge Nicknames
Nicknames are 16-bit dynamically assigned abbreviations for each
RBridge's 48-bit IS-IS System ID (see Section 4.2.1) to achieve a
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 16]
INTERNET-DRAFT RBridge Protocol
more compact encoding. This assignment allows specifying up to 2**16
RBridges; however, the value 0x0000 is reserved to indicate that a
nickname is not specified and the value 0xFFFF is reserved for future
specification. RBridges piggyback a nickname acquisition protocol on
the link state protocol (see Section 3.7.3) to acquire a nickname
unique within the campus.
3.7.1 Egress RBridge Nickname
There are three cases for the contents of the egress RBridge nickname
field, depending on the M-bit (see Section 3.4) and the Inner.MacDA
(see Section 4.1). It is filled in by the ingress RBridge for data
frames and by the source RBridge for control frames.
o For known-unicast data frames M = 0, the Inner.MacDA is not All-
IS-IS-RBridges, and the egress RBridge nickname field specifies
the egress RBridge i.e. it specifies the RBridge that needs to
remove the TRILL header from the data frame.
o For multi-destination data frames, M = 1, and the egress RBridge
nickname field contains the nickname of the root RBridge of the
distribution tree selected to be used to forward the frame. This
root MUST NOT be changed by transit RBridges.
o For core instance TRILL IS-IS frames M = 0, the Inner.MacDA is
All-IS-IS-Rbridge, and the egress RBridge nickname field is not
used. Such frames may be sent before nicknames have been
established and are only sent one hop. The Egress RBridge
Nickname MUST be set to zero by the source RBridge for such frames
and is ignored by other RBridges.
3.7.2 Ingress RBridge Nickname
The ingress RBridge nickname contains the nickname of the ingress
RBridge in two cases: (1) Data frames (those with Inner.MacDA other
than All-IS=IS-Rbridges) and (2) Per VLAN TRILL IS-IS frames (those
with Inner.MacDA equal to All-IS-IS-Rbridges and an inner VLAN tag
present). Note: The per-VLAN-x TRILL IS-IS frame is used for the
purpose of the ingress RBridge R1 optionally advertising attachment
of a set of VLAN-x endnodes to R1.
For core TRILL IS-IS frames, that is those with Inner.MacDA equal to
All-IS-IS-Rbridges and no inner VLAN tag present, this field is not
used. Such frames may be sent before nicknames have been established
and are only sent one hop. In that case this field MUST be set to
zero by the source RBridge and is ignored by other RBridges. Note:
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 17]
INTERNET-DRAFT RBridge Protocol
Core IS-IS frames include Hello messages, SNPs, and LSPs.
3.7.3 RBridge Nickname Allocation
The nickname allocation protocol is piggybacked on the core TRILL IS-
IS instance as follows:
o The nickname being used by an RBridge is carried in an IS-IS TLV
(type-length-value data element) along with a priority of use
value. Each RBridge chooses its own nickname.
o The nickname value MAY be configured. An RBridge that has been
configured with a nickname value will have priority for that
nickname value over all Rbridges with non-configured nicknames.
o The nickname values 0x0000 and 0xFFFF are reserved and may not be
selected or configured. In some cases the value 0x0000 is used to
indicate that the nickname is not known.
o The priority of use field reported with a nickname is an unsigned
8-bit value, where the most significant bit (0x80) indicates that
the nickname value was configured. The bottom 7 bits have the
default value 0x40, but MAY be configured to be some other value.
Additionally, an RBridge MAY increase the priority (once) after
holding the nickname for some amount of time, to prevent a newly
arriving RBridge that has not yet seen all the LSPs, from usurping
its nickname, unless the new RBridge has been configured with the
nickname value and the RBridge using that nickname value was not
manually configured with that nickname value. The most significant
bit of the priority MUST NOT be set unless the nickname value was
configured.
o Each RBridge is also responsible for ensuring that its nickname is
unique. If RB1 chooses nickname x, and RB1 discovers, through
receipt of RB2's LSP, that RB2 has also chosen x, then the RBridge
with the numerically higher priority keeps the nickname, or if
there is a tie in priority, the RBridge with the numerically
higher System ID keeps the nickname, and the other RBridge MUST
choose a new nickname.
o If two RBridge campuses merge, then transient nickname collisions
are possible. As soon as each RBridge receives the link state
frames from the other RBridges, the RBridges that need to change
nicknames choose new nicknames that do not, to the best of their
knowledge, collide with any existing nicknames.
To minimize the probability of nickname collisions, each RBridge
chooses its nickname by randomly hashing some of its parameters.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 18]
INTERNET-DRAFT RBridge Protocol
There is no reason for all Rbridges to use the same algorithm for
choosing nicknames.
Once an RBridge has successfully acquired a nickname it SHOULD store
it in non-volatile memory and attempt to reuse it in the case of a
reboot.
To minimize the probability of a new RBridge usurping a nickname
already in use, an RBridge SHOULD wait to acquire the link state
database from a neighbor before it announces its own nickname.
In IS-IS [ISO10589] a shared link is modeled as a pseudonode.
Pseudonodes never act as ingress or egress RBridges and are never
treated as distribution tree roots. Thus they do not need and do not
have nicknames.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 19]
INTERNET-DRAFT RBridge Protocol
4. Other RBridge Design Details
Section 3 above describes the TRILL Headers while this Section
provides a textual and diagrammatic description of other RBridge
design details. Section 5 below provides pseudo-code.
4.1 Ethernet Data Encapsulation
TRILL data frames in transit on Ethernet links are encapsulated with
an outer Ethernet header (see Figure 2). This outer header looks, to
a bridge on the path between two RBridges, like the header of a
regular Ethernet frame and therefore bridges forward the frame
without requiring any modification. To enable RBridges to distinguish
TRILL frames, a new TRILL Ethertype (see Section 9.2) is used in the
outer header.
Figure 6 details a data frame with an outer VLAN tag traveling on the
Ethernet cloud of Figure 1 from RB1 to RB2. This encapsulation has
the advantage, in the absence of TRILL options, of aligning the
original Ethernet frame at a 64 bit boundary.
When a TRILL data frame is carried over an Ethernet cloud it has
three pairs of addresses:
o Outer Ethernet Header: Outer Destination MAC Address and Outer
Source MAC Address: These addresses are used to specify the next
hop RBridge and the transmitting RBridge, respectively, over a
shared Ethernet cloud.
o TRILL Header: Egress (RB2) Nickname and Ingress (RB1) Nickname.
These specify the nickname values of the egress and ingress
RBridges, respectively, for data frames.
o Inner Ethernet Header: Inner Destination MAC Address and Inner
Source MAC Address: These addresses are as transmitted by the
original end node, specifying, respectively, the destination and
source of the inner frame.
It also potentially has two VLAN tags that can carry two different
VLAN Identifiers and also include priority.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 20]
INTERNET-DRAFT RBridge Protocol
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address (RB2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address (RB1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = IEEE 802.1Q | Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (RB2) Nickname | Ingress (RB1) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = IEEE 802.1Q | Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame CheckSum:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame CheckSum) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. TRILL Data Encapsulation over Ethernet
4.1.1 VLAN Tag Information
The information in a "VLAN Tag", also known as a "C-tag" (formerly Q-
tag), is more than just a VLAN ID. It always includes a priority
field as shown in Figure 7. In fact, the "VLAN ID" may be zero,
indicating the no VLAN is specified, just priority, although such a
tag is properly called a "priority tag" rather than a "VLAN Tag"
[802.1Q].
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 21]
INTERNET-DRAFT RBridge Protocol
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Priority | C | VLAN ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 7. VLAN Tag Information
As recommended in [802.1Q] Rbridges SHOULD be implemented so as to
allow use of the full range of VLAN IDs from 0x001 through 0xFFE.
VLAN ID zero is the null VLAN identifier and indicates that no VLAN
is specified while VLAN ID 0xFFF is reserved. Rbridges MAY support a
smaller number of simultaneously active VLAN IDs than the total
number of different VLAN IDs they allow.
The "C" bit shown in Figure 8 is the CFI or Canonical Format
Indicator bit. It refers to the format of the associated source and
destination addresses. The CFI is not used with IEEE 802.3. In
TRILL, it MUST be set to zero and is ignored by receivers.
As specified in [802.1Q], the priority field contains an unsigned
value from 0 through 7 where 1 indicates the lowest priority, 7 the
highest priority, and the default priority zero is considered to be
higher than priority 1 but lower than priority 2. RBridges (and
bridges), are not required to implement 8 priority levels so frames
with different priority levels may be treated as if they had the same
priority. Differing priorities can cause frame re-ordering.
The C-Tag (formerly Q-Tag) Ethertype is 0x8100.
4.1.2 Outer VLAN Info
RBridges send IS-IS Hellos on a link in order to discover RBridge
neighbors. The default is to send IS-IS Hellos only on VLAN 1.
However, an RBridge MAY be configured to send Hellos on a set of,
say, k different VLAN numbers, including one preferred value. In
that case, the RBridge will transmit k times as many Hellos, sending
Hellos tagged with each of the k values in turn.
As with traditional IS-IS, one RBridge is elected DRB (Designated
RBridge), based on configured priority (most significant field), and
system ID. The DRB continues to send k times as many Hellos, but
specifies in all the Hellos, the preferred VLAN ID for the link. All
RBridges that are not DRB transmit Hellos only on the single
preferred VLAN number specified by the DRB.
This VLAN number is used in all RBridge-RBridge communication,
including forwarded encapsulated data packets and IS-IS messages,
except for the additional k-1 Hellos transmitted by the DRB on the
VLAN numbers other than the preferred VLAN number.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 22]
INTERNET-DRAFT RBridge Protocol
On forwarded data packets, the priority field in the Outer VLAN Info
is set on an outgoing TRILL frame to a copy of the priority field in
the Inner VLAN Info for data frames or to 7, the highest priority,
for TRILL IS-IS frames.
4.1.3 Inner VLAN Info
The "Inner VLAN Info" field contains the VLAN information associated
with the original native frame when it was ingressed or the VLAN
information associated with a per VLAN TRILL IS-IS message when that
message was created. When a TRILL frame with Inner VLAN Info
arrives, that Inner VLAN Info is not changed.
When a native (non-TRILL) frame arrives, the priority and VLAN in the
Inner VLAN Info are determined as specified in [802.1Q] (see [802.1Q]
Section 6.7). A high level informative summary of how this VLAN Info
is determined, omitting some details, is given in the bulleted items
below:
o When an untagged native frame arrives, a zero configuration
RBridge associates the default priority zero and the VLAN ID 1
with it. It actually sets the VLAN for the untagged frame to be
the "port VLAN ID" associated with that port. The port VLAN ID
defaults to VLAN ID 1 but may be configured to be any other VLAN
ID. An Rbridge may also be configured on a per port basis to
discard such frames or to associate a different priority with
them. Determination of the configured port VLAN IDs may also be
made dependent on the Ethertype or NSAP (referred to in 802.1 as
the Protocol) of the arriving frame.
o When a priority tagged native frame arrives, a zero configuration
RBridge associates with it both the port VLAN ID, which defaults
to 1, and the priority provided in the priority tag in the frame.
An Rbridge may be configured on a per port basis to discard such
frames or to associate them with a different VLAN ID as described
in the point immediately above. It may also be configured to map
the priority provided in the frame by specifying, for each of the
eight possible priorities that might be in the frame, what actual
priority will be associated with the frame by the RBridge.
o When a C-tagged (formerly called Q-tagged) native frame arrives, a
zero configuration RBridge associates with it the VLAN ID and
priority in the C-tag. An RBridge may be configured on a per port
per VLAN basis to discard such frames. It may also be configured
on a per port basis to map the priority as specified above for
priority tagged frames.
In 802.1, the process of assigning a priority to a frame including
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 23]
INTERNET-DRAFT RBridge Protocol
mapping a priority provided in the frame to another priority, is
referred to as priority "regeneration".
Thus, in TRILL, the Inner VLAN Tag always specifies a VLAN ID. This
Inner VLAN ID is required at the ingress Rbridge as one element in
determining the appropriate egress Rbridge for a known unicast frame
and is required at the ingress and every transit Rbridge for multi-
destination frames to correctly prune the distribution tree.
The VLAN ID 0xFFF is reserved and MUST NOT be used. Rbridges MUST
discard any frame they receive with a VLAN 0xFFF tag.
4.1.4 Frame CheckSum (FCS)
Each frame has a single Frame CheckSum (FCS) that is computed to
cover the entire frame for detecting errors due to communications
failures. It is calculated before transmission and checked on
receipt. Any frame for which the FCS fails is discarded. The FCS
generally changes on every hop due to changes in the outer
destination and source addresses and the decrementing of the hop
count.
It is desirable, when practical, for the FCS to accompany a frame
transiting an RBridge and be dynamically updated to account for all
changes to the frame during that transit. This is helpful in
detecting a class of RBridge equipment failures.
4.2 Link State Protocol (IS-IS)
TRILL uses IS-IS as the routing protocol, since it has the following
advantages:
o it runs directly over Layer 2, so therefore may be run with zero
configuration (no IP addresses need to be assigned);
o it is easy to extend by defining new TLV (type-length-value)
encoded data elements for carrying TRILL information;
4.2.1 IS-IS RBridge Identity
Each RBridge has a unique 6-octet IS-IS System ID, which may be
derived from any of the RBridge's unique MAC addresses.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 24]
INTERNET-DRAFT RBridge Protocol
4.2.2 IS-IS Instances
TRILL implements separate IS-IS instances from the one used by Layer
3, that is, different from the one used by IP routers. TRILL IS-IS
messages are distinguished from Layer 3 IS-IS messages because TRILL
IS-IS frames have a TRILL header and never use the Layer 3 IS-IS
multicast addresses (AllL1ISs and AllL2ISs) as their outer MAC
destination address. All TRILL IS-IS frames have an Inner.MacDA of
All-IS-IS-Rbridges.
Within TRILL, there is a mandatory core IS-IS across all Rbridges in
the campus and optional per VLAN instances between the RBridges on
each supported VLAN. They are distinguished by the presence of an
inner VLAN tag in the per VLAN instance frames and the absence of
such a tag in the core instances frames.
All Rbridges must participate in the core IS-IS instance. Core IS-IS
instance frames are never forwarded by an RBridge but are
decapsulated and locally processed. (Such processing may cause the
RBridge to emit additional core IS-IS instance frames.)
RBridges that are the appointed VLAN-x forwarder for a link having an
end station in a particular VLAN-x MAY participate in the per VLAN
IS-IS instance for that VLAN. But all transit RBridges MUST properly
forward per VLAN IS-IS instance frames. Because of this forwarding,
it appears to a per VLAN IS-IS instance at an RBridge that it is
directly connected by a shared link to all other RBridges in the
campus running that per VLAN IS-IS instance. Egress RBridges that do
not implement the per VLAN IS-IS instance for that VLAN do not
decapsulate or locally process any per VLAN IS-IS frames they
receive.
4.2.3 TRILL IS-IS Information
The information in the IS-IS link state for the mandatory core and
optional per-VLAN TRILL IS-IS instances is listed below. The actual
encoding of this information and the IS-IS Type values for any new
IS-IS TLV or sub-TLV data elements are specified in a separate
document.
4.2.3.1 Core IS-IS Information
The information contained in the link state of RBridge RBn for the
mandatory core IS-IS instance is as follows:
1. The IS-IS IDs of neighbors (pseudonodes as well as RBridges) of
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 25]
INTERNET-DRAFT RBridge Protocol
RBridge RBn, and the cost of the link to each of those neighbors.
2. The nickname of RBridge RBn (2 octets) and the unsigned 8-bit
priority for RBn to have that nickname (see Section 3.7.3);
3. The TRILL Header Versions supported by RBridge RBn (4 bits).
4. A flag RequestTree indicating whether RBridges MUST calculate a
tree rooted at RBn (default RequestTree = TRUE).
5. The list of RBridge nicknames that RBn might select for a
distribution tree when RBn injects a multi-destination frame into
the campus. The purpose of this field is so that RBridges can
efficiently build receipt filters to avoid multicast loops (see
Section 4.3.1). If the list is empty or not provided, RBn can
only select itself (if RBn's Request Tree flag is true) or the
RBridge with the lowest System ID (if RBn's Request Tree flag is
false).
6. The list of VLAN IDs of VLANs directly connected to RBn for links
on which RBn is the appointed forwarder for that VLAN. (Note: an
RBridge may advertise that it is connected to additional VLANs in
order to receive additional information to support certain VLAN
based features beyond the scope of this specification as discussed
in Section 4.7.) In addition, the link state contains the
following information on a per VLAN basis:
6.1 Per VLAN Multicast Router attached flags: This is two bits of
information that indicate whether there is an IPv4 and/or IPv6
multicast router attached to the Rbridge on that VLAN. An
RBridge which does not do IP multicast control snooping MUST
set both of these bits (see Section 4.4.3). This information
is used because IGMP [RFC3376] and MLD [RFC2710] Membership
Reports MUST be transmitted to all links with IP multicast
routers, and SHOULD NOT be transmitted to links without such
routers. Also, all frames for IP-derived multicast addresses
MUST be transmitted to all links with IP multicast routers
(within a VLAN), in addition to links from which an IP node has
explicitly asked to join the group the frame is for.
6.2 Per VLAN Other Multicast flag. This is a flag bit, which
defaults to true, that indicates that the RBridge wishes to
receive non-IP derived multicast for that VLAN. It defaults to
true (one). Within each VLAN, all non-IP derived multicast
traffic MUST be sent to an RBridge in the VLAN that asserts
this flag.
6.3 Per VLAN mandatory announcement of the set of IDs of Root
bridges for any of RBn's links on which RBn is forwarder for
that VLAN. Where MSTP (Multiple Spanning Tree Protocol) is
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 26]
INTERNET-DRAFT RBridge Protocol
running on a link, the root bridge is of the CIST (Common and
Internal Spanning Tree). This is to quickly detect cases where
two Layer 2 clouds accidentally get merged, and where there
might otherwise temporarily be two DRBs for the same VLAN on
the same link. (See Section 4.2.4.)
6.4 Optionally, per VLAN Layer 2 multicast addresses derived from
IPv4 IGMP or IPv6 MLD notification messages received from
attached end nodes on that VLAN, indicating the location of
listeners for these multicast addresses (see Section 4.4.3).
7. Optionally, a list of VLAN groups, where each VLAN group is a list
of VLAN IDs, with the first VLAN ID listed in a group is the
"primary" and the others are "secondary". This is solely to detect
misconfiguration of features outside the scope of this document.
RBridges that do not support features such as "shared VLAN
learning" ignore this field (see Section 4.7).
Using this information each RBridge can compute the optimal pair-wise
forwarding for known-unicast traffic (the Forwarding Database) and
the distribution trees for multi-destination traffic.
The distribution of multi-destination frames (see Sections 4.3 and
4.4.3) SHOULD also be pruned according to the list of VLAN IDs for
which each RBridge is an appointed forwarder and for IP based
multicast optimization (see Section 4.3.2). If RBn is forwarding a
multi-destination frame tagged with VLAN-x, RBn SHOULD NOT forward it
onto branches of the distribution tree that have no downstream VLAN-x
links.
4.2.3.2 Optional Per-VLAN IS-IS Instance Information
The information in the link state for the optional per VLAN TRILL IS-
IS instances is the list of local end station MAC addresses known to
the originating RBridge and for each such address a one octet
unsigned "confidence" rating in the range 0-254 (see Section 4.6).
4.2.4 Designated RBridge
IS-IS elects one RBridge for each link to be the Designated RBridge
(DRB), i.e. to have special duties. The Designated RBridge:
o chooses, for the link, the common VLAN tag to be used for all
inter-Bridge communication (forwarded data packets, IS-IS
messages), and announces it in its Hello.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 27]
INTERNET-DRAFT RBridge Protocol
o decides whether the link should be represented in the IS-IS
topology as a pseudonode, and if so, chooses a pseudonode ID and
announces that in the Hello. Although it is not necessary to
standardize the algorithm that the DRB uses to determine whether
the link should be represented by a pseudonode or not, the
following algorithm is recommended. If the link contains only one
or two RBridges (the DRB plus potentially one other), then the DRB
does not use a pseudonode for the link. If the link contains five
or more RBridges (the DRB has at least 4 RBridge neighbors), then
the DRB creates a pseudonode for the link. If the DRB has 2 or 3
neighbors, then the DRB does not change the state of the link; in
other words, if there was a pseudonode because at some point in
the past there were 5 RBridges on the link, then the link remains
represented as a pseudonode until the population of RBridges on
the link drops to 2 or fewer. Likewise, if there is no pseudonode
for the link, the DRB will not create one until there are at least
5 RBridges on the link.
o issues an LSP on behalf of the pseudonode (if the link is to be
represented by a pseudonode).
o issues CSNPs.
o for each VLAN x appearing on the link, chooses an RBridge on the
link to be the appointed VLAN-x forwarder (the DRB MAY choose to
be the appointed VLAN-x forwarder for all or some of the VLANs).
o before forwarding traffic off the link, or appointing a VLAN-x
forwarder, wait at least 5 Hello intervals (to ensure you are
DRB).
o continues sending IS-IS Hellos on all the VLANs that the DRB has
been configured to send Hellos on (whereas non-DRBs send Hellos
only on the common VLAN as specified by the DRB).
4.2.5 Appointed VLAN-x Forwarder
The appointed VLAN-x forwarder is responsible for
o forwarding VLAN x data traffic to-from the link.
o learning the location of local VLAN-x endnodes based on looking at
the source address of native VLAN-x packets on the link.
o optionally learning the location of local VLAN-x endnodes based on
any sort of layer 2 enrollment protocols.
o keeping track of (RBridge, MAC address) of distant VLAN endnodes,
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 28]
INTERNET-DRAFT RBridge Protocol
learned by looking at the fields (ingress RBridge, source address
in inner Ethernet header) from packets being decapsulated onto the
link.
o optionally listening to the messages in the VLAN-x instance of IS-
IS to learn (RBridge, MAC address) pairs of explicitly advertised
endnodes.
o optionally advertising VLAN x endnodes, on links for which you are
appointed VLAN-x forwarder, in a VLAN-x instance of IS-IS.
o listening to BPDUs on the common spanning tree to learn the root
bridge.
o reporting in its LSP, the complete set of root bridges on any link
for which this RBridge is appointed forwarder for any VLAN.
o loop avoidance: not decapsulating a packet from ingress RBridge
RB3 unless it has RB3's LSP, and the root bridge on the link it is
about to forward onto is not listed in RB3's list of root bridges
for the same VLAN.
o duplicate avoidance: not forwarding packets off a link until
waiting several Hello intervals on each of its links, and, for
each link, receiving all the LSPs listed in the first CSNP (if
any) it has received from the neighbor on that link.
o including a "port number" in its Hellos, and if it sees its own
Hello on port p, where the port number in the received Hello is
"q", then if q>p, forwarding traffic to/from port p.
4.3 Distribution Trees
RBridges use distribution trees to forward multi-destination frames
(see Section 2.4.2). Distribution Trees are bidirectional. A single
distribution tree is logically enough for the entire campus. The
TRILL WG decided that the computation of additional distribution
trees was warranted because:
1. using a tree rooted at the ingress RBridge optimizes the
distribution path and (almost always) the cost of delivery when
the number of destination links is a subset of the total number of
links, as is the case with VLANs and IP multicasts;
2. for unknown unicast destinations, using a tree rooted at the
ingress RBridge minimizes out-of-order delivery because, in the
case where a flow starts before the location of the destination is
known by the RBridges, the path to the destination is the same as
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 29]
INTERNET-DRAFT RBridge Protocol
the shortest path to the destination.
A distribution tree rooted in the ingress RBridge is not always the
best choice:
1. In some cases, a different tradeoff might be wanted in terms of
the expense of computing many trees vs. optimality of traffic
distribution (so fewer trees would be desired).
2. It might be desirable to allow choosing a different distribution
tree than the one rooted at the ingress RBridge for some frames in
order to allow multipathing of multi-destination traffic injected
by a particular RBridge.
RBridges MUST calculate at least one distribution tree, and by
default SHOULD compute one distribution tree for every Rbridge.
However, to scale in the presence of a large number of RBridges in a
campus, some RBridges MAY be configured to not be the root of a
distribution tree. Each RBridge RBi announces whether RBridges MUST
compute a tree rooted at RBi via the RequestTree flag in its core IS-
IS instance LSP. The default is RequestTree == TRUE, but management
configuration MAY reduce the number of trees.
If all Rbridges have their RequestTree == FALSE, then each RBridge
MUST calculate a tree rooted at the RBridge with lowest System ID.
If RBi is a tree root, then any RBridge RBn that needs to send multi-
destination traffic MAY select the RBi-tree by specifying RBi as the
egress Nickname in the TRILL header. However, RBn MUST announce, in
its LSP, an intention to use RBi as a tree root if RBn ever chooses
the RBi-tree. All the other RBridges MUST comply with the decision
of the RBridge RBn.
In IS-IS a shared link is modeled as a pseudonode. The RBridge acting
as designed RBridge for a shared link MUST set RequestTree false for
the pseudonode.
4.3.1 Distribution Tree Calculation and Checks
RBridges do not use the spanning tree protocol to calculate
distribution trees. Instead, distribution trees are calculated based
on the link state information, selecting a particular RBridge as the
root.
Calculation of a tree rooted at RBi is done independently by each
RBridge RBn by performing the SPF (Shortest Path First) calculation
with RBi as the root without requiring any additional exchange of
information.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 30]
INTERNET-DRAFT RBridge Protocol
When a node RBn has two or more minimal equal cost paths toward the
Root RBi a deterministic tie-breaker is needed to guarantee that all
Rbridges calculate the same distribution tree. This is obtained by
selecting the path that goes to the parent that has the lower IS-IS
System ID.
Each RBridge RBn keeps a set of adjacencies (port, neighbor pair) for
each distribution tree. One of these adjacencies is toward the root
RBi and the others are toward the leaves. Once the adjacencies are
chosen, it is irrelevant which ones are towards the root RBi, and
which are away from RBi. Let's suppose that RBn has calculated that
adjacencies a, c, and f are in the RBi tree. A multi-destination
frame for the distribution tree RBi is received only from one of the
adjacencies a, c, or f (otherwise is discarded) and forwarded to the
other two adjacencies.
To further avoid temporary multicast loops during topology changes,
RBridges MUST do a sanity check that a multi-destination frame
arrives on the expected link. This is called the Reverse Path
Forwarding Check and is done as follows. When RBn calculates the RBi
tree, for each adjacency in the RBi tree, RBn lists the possible
ingress RBridge nicknames on that adjacency. The only ingress
RBridges that appear on any of the adjacencies are RBridges that have
explicitly stated, in their LSP, that they may select RBi as a
distribution tree. If a multi-destination frame is received on a
particular adjacency, marked as the RBi-tree, then RBn MUST NOT
forward it if the ingress RBridge is not listed in the allowed list
of ingress RBridges for that adjacency for that tree.
4.3.2 Pruning the Distribution Tree
Each distribution tree SHOULD be pruned per VLAN eliminating branches
that have no potential receivers downstream. Multi-destination frames
SHOULD only be forwarded on branches that are not pruned.
Further pruning SHOULD be done in several cases: (1) IGMP [RFC3376],
MLD [RFC2710], and MRD [RFC4286] messages, where these are to be
delivered only to ports with IP Multicast routers; (2) other
multicast frames derived from an IP multicast which should be
delivered only to links that have registered listeners, plus links
which have IP Multicast routers; and (3) other multicast traffic not
derived from an IP address which is only delivered to links for which
the appointed forwarder has the Other Multicast requested flag set.
All of these cases are scoped per VLAN.
Let's assume that RBridge RBn knows that adjacencies (a, c, and f)
are in the RBi-distribution tree. RBn marks pruning information for
each of the adjacencies in the RBi-tree. For each adjacency and for
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 31]
INTERNET-DRAFT RBridge Protocol
each tree, RBn marks:
o the set of VLANs reachable downstream,
o for each one of those VLANs, flags indicating whether there are
IPv4 or IPv6 multicast routers downstream and whether there are
one or more RBridge downstream with the Other Multicast flag set,
and
o the set of Layer 2 multicast addresses derived from IP multicast
groups for which there are receivers downstream.
4.3.3 Forwarding Using a Distribution Tree
Forwarding a multi-destination data frame is done as follows:
o The RBridge RBn receives a multi-destination frame with inner VLAN
A and a TRILL header indicating that the selected tree is the RBi-
tree;
o if the adjacency from which the frame was received is not one of
the adjacencies in the RBi-tree for the specified ingress RBridge,
the frame is dropped (see Section 4.3.1);
o else, if the frame is an IGMP or MLD announcement message or an
MRD query message, then the frame is forwarded onto adjacencies in
the RBi-tree that indicate there are downstream VLAN A IPv4 or
IPv6 multicast routers respectively (for more information see
Section 4.4);
o else, if the frame is for a Layer 2 multicast address derived from
an IP multicast group, then the frame is forwarded onto
adjacencies in the RBi-tree that indicate there are downstream
VLAN A IP multicast routers of the corresponding type (IPv4 or
IPv6), as well as adjacencies that indicate there are downstream
VLAN A receivers for that group address (see Section 4.4);
o else, if the frame is for a Layer 2 multicast address not derived
from an IP multicast group, then the frame is forwarded onto
adjacencies in the RBi-tree that indicate there are downstream
RBridges in VLAN A with the Other Multicast flag set;
o else (the inner frame is for an unknown destination or broadcast)
the frame is forwarded onto an adjacency if and only if that
adjacency is in the RBi-tree, and marked as reaching VLAN A links.
For each link for which RBn is appointed forwarder, RBn additionally
checks to see if it should decapsulate the frame and send it to the
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 32]
INTERNET-DRAFT RBridge Protocol
link, or process the frame.
The per-VLAN instance TRILL IS-IS frames will be delivered only to
RBridges which are appointed forwarders for that VLAN. Per-VLAN TRILL
IS-IS messages look, to transit RBridges, like any multicast data
packet tagged with an inner VLAN tag. Such packets will be multicast
throughout the campus, like other non-IP-derived multicast data
packets, on the distribution tree chose by the RBridge which created
the per-VLAN IS-IS message, and pruned according to the inner VLAN
tag. Thus they are received by all the RBridges who are appointed
forwarders for a link in that VLAN unless the RBridge has cleared its
Other Multicast bit for that VLAN and has no appointed forwarders
downstream in the tree with the Other Multicast bit set.
4.4 Forwarding Behavior
This section describes RBridge behavior for a variety of received
frames, including how they are forwarded when appropriate.
4.4.1 Receipt of a Native Frame
An RBridge can tell that it has received a native frame because it
does not have the TRILL Ethertype.
The ingress Rbridge RB1 determines the VLAN ID according to the same
rules as 802.1 bridges do (see Section 4.1.3). Once the VLAN is
determined, if RB1 is not the appointed forwarder for that VLAN for
the link from which the frame was received, the frame is discarded.
If it is appointed forwarder for that VLAN, then it is forwarded
according to 4.4.1.1 if the frame is unicast, and 4.4.1.2 if it is
multicast or broadcast.
4.4.1.1 Native Unicast Case
If the destination MAC address of the native frame is a unicast
address, the following steps are performed.
The Layer 2 destination address D is looked up in the Encapsulation
Database for that VLAN to find the egress RBridge RBm, or discover
that D is unknown.
If D is known, with egress Rbridge RBm, then RB1 converts the native
frame to a TRILL data frame with outer MAC addresses from RB1 unicast
to the next hop RBridge towards RBm and a TRILL header with M = 0,
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 33]
INTERNET-DRAFT RBridge Protocol
the ingress nickname for itself, and the egress nickname for RBm.
If D is unknown, RB1 converts the native frame to a TRILL data frame
with outer MAC addresses of RB1 as source and the All-Rbridges
multicast address as destination and a TRILL header with the multi-
destination bit M = 1, the ingress nickname for itself, and the
egress nickname for the root of the distribution tree it wants to
use. The default is for RB1 to write its own nickname into the
egress nickname field. However, RB1 MAY choose a different
distribution tree if either RB1 has not elected to be a tree root, or
if RB1 has been configured to path-split multicast. In that case RB1
MUST select a tree by specifying an RBridge that has elected to be a
tree root. Also, RB1 MUST select a tree that RB1 has announced (in
RB1's own LSP) to be one of the ones that RB1 MAY choose as a
distribution tree. (see Section 4.3.1)
4.4.1.2 Native Multicast and Broadcast Frames
If the destination address of a native frame is the broadcast address
or a multicast address other than All-Rbridges or All-IS-IS-Rbridge,
the frame is processed as described below. A native (non-TRILL) frame
sent to the All-Rbridges or All-IS-IS-Rbridges address is erroneous
and is discarded.
If the frame is an IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286]
message, then RB1 SHOULD analyze the frame, learn any group
membership or IP multicast router presence indicated, and announce
that information for the appropriate VLAN in its IS-IS link state
(see Section 4.5).
For all such frames, RB1 also chooses a distribution tree,
encapsulates, and forwards the frame on the pruned distribution tree
(see Section 4.3.2). In the encapsulation, M = 1 the Outer.MacSA is
set to that of the port on which the frame is being transmitted and
the Outer.MacDA is normally the All-Rbridges multicast address;
however, if for any particular port there is only one next hop
RBridge, the frame MAY be sent with the unicast Outer.MacDA of the
target RBridge. Using a unicast Outer.MacDA is of no benefit on a
point-to-point link but may result in substantial savings if the link
is actually a complex bridged LAN.
4.4.2 Receipt of a Non-Native (TRILL) Frame
Non-native frames are indicated by a TRILL outer Ethertype. Such
frames will be received with an Outer.MacDA that is unicast or that
is the All-RBridges multicast address. TRILL frames with any other
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 34]
INTERNET-DRAFT RBridge Protocol
Outer.MacDA are erroneous and are discarded except that a TRILL frame
with the broadcast Outer.MacDA MAY be treated as if the Outer.MacDA
was the All-Rbridges multicast address. TRILL frames received by an
RBridge on a port are never blocked because of that RBridge's
appointed forwarder or Designated RBridge status for that port.
If the Outer.MacDA is a unicast address, the frame is discarded
unless that address is the address of the receiving Rbridge. (Such
discarded frames are most likely addressed to another RBridge on a
multi-access link and that other Rbridge will handle them.) After
this check, further processing of TRILL frames is independent of the
Outer.MacDA.
If the Version field in the TRILL Header is greater than 0, the frame
is discarded. The Inner.MacDA is then tested. If it is the All-IS-IS-
Rbridges multicast address, processing proceeds as in Section 4.4.2.1
below. If it is any other address, processing proceeds as in Section
4.4.2.2.
4.4.2.1 TRILL IS-IS Frames
If there is no Inner VLAN tag, the frame is a core instance TRILL IS-
IS frame and is processed by the core IS-IS instance on RBn and is
not forwarded. Note that in this instance, nicknames may not yet have
been established and the ingress and egress nickname fields are
ignored.
If there is an Inner VLAN tag, the frame is a per VLAN instance TRILL
IS-IS frame. If M == 0, the frame is discarded. The egress nickname
designates the distribution tree. In this case, the frame is
forwarded as described in Section 4.4.2.2.2. In addition, if the
forwarding Rbridge is an appointed forwarder for a link in the
specified VLAN and implements a per VLAN IS-IS instance for that
VLAN, the inner frame is decapsulated and provided to that local per
VLAN IS-IS instance.
4.4.2.2 TRILL Data Frames
The port on which the frame was received is first checked and the
frame discarded if there is no IS-IS adjacency on that port.
The Inner.MacDA is then checked. If it is unicast, processing
continues as described in Section 4.4.2.2.1, otherwise processing
continues as described in Section 4.4.2.2.2.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 35]
INTERNET-DRAFT RBridge Protocol
4.4.2.2.1 Unicast TRILL Data Frames
If M == 1 the frame is discarded.
Generally, the hop count is decremented by one and the frame
forwarded to the next hop RBridge towards the egress RBridge, using
the Forwarding Database, unless the hop count was zero, in which case
the frame is discarded.
On the other hand, if the egress RBridge indicated is the RBridge
performing the processing (RBn), the frame being forwarded is
reconverted to native form. This frame is then either sent onto the
link containing the destination or locally processed if the RBridge
itself is the destination.
A known unicast TRILL data frame can arrive at the egress Rbridge
only to find that the MAC destination address is not actually known
by that RBridge. One way this can happen is that the destination MAC
address may have timed out in the egress RBridge cache. In this case,
the egress RBridge decapsulates the frame to native form and sends it
out on all links that are in the frame's VLAN for which the RBridge
is appointed forwarder except that it is MAY refrain from sending the
frame on links where it knows there can not be an end station with
the destination MAC address, for example the link is known to be a
point-to-point link to another RBridge.
4.4.2.2.2 Multi-Destination TRILL Data Frames
If M == 0, the frame is discarded.
The Outer.MacSA is then checked and the frame discarded if it is not
a tree adjacency for the tree indicated by the egress RBridge
nickname or the RPF check fails (see Section 4.3.1).
The frame is then forwarded down the tree specified by the egress
RBridge nickname pruned as described in Section 4.3.2.
In the forwarded frame, the Outer.MacSA is set to that of the port on
which the frame is being transmitted and the Outer.MacDA is normally
the All-Rbridges multicast address; however, if for any particular
port there is only one next hop RBridge, the frame MAY be sent with a
unicast Outer.MacDA. Using a unicast Outer.MacDA is of no benefit on
a point-to-point link but may result in substantial savings if the
link is actually a complex bridged LAN.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 36]
INTERNET-DRAFT RBridge Protocol
4.4.3 Tree Distribution Optimization
RBridges MUST determine the VLAN associated with all native frames
and properly enforce VLAN rules on the emission of native frames at
egress RBridges according to how they are configured. They SHOULD
also prune the distribution tree of multi-destination frames
according to VLAN. But, since they are not required to do such
pruning, they may receive TRILL data frames that should have been
VLAN pruned earlier in the tree distribution. They silently discard
such frames. A campus may contain some Rbridges that prune on VLAN
and some which do not.
The situation is more complex for multicast. RBridges SHOULD analyze
IP derived multicast frames, and learn and announce listeners and IP
multicast routers for such frames as discussed in Section 4.5 below.
And they SHOULD prune the distribution of IP derived multicast frames
based on such learning and announcements. But, as with VLANs, they
are not required to prune and, unlike VLANs, they are not required to
learn. A campus may contain a mixture of Rbridges with different
levels of IP derived multicast optimization. An RBridge may receive
IP derived multicast frames that should have been pruned earlier in
the tree distribution. They silently discard such frames.
An RBridge that does not examine IGMP [RFC3376], MLD [RFC2710], and
MRD [RFC4286] frames that it ingresses MUST advertise that it has
IPv4 and IPv6 IP multicast routers attached for all the VLANs for
which it is an appointed forwarder. It need not advertise any IP
derived multicast listeners. This will cause all IP derived
multicast traffic to be sent to this RBridge for those VLANs. It then
egresses that traffic onto the links for which it is appointed
forwarder where the VLAN of the traffic matches the VLAN for which it
is appointed forwarder on that link. (This may cause the suppression
of certain IGMP membership report messages from end stations but that
is not significant as any multicast traffic such reports would be
requesting will be sent to such end stations under these
circumstances.)
See also "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
[RFC4541].
4.5 IGMP, MLD, and MRD Learning
RBridges SHOULD learn, based on seeing IGMP [RFC3376], MLD [RFC2710],
and MRD [RFC4286] frames, which IP derived multicast messages should
be forwarded onto which links.
An IGMP or MLD membership report received in native form from a link
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 37]
INTERNET-DRAFT RBridge Protocol
indicates a multicast group listener for that group on that link. An
IGMP or MLD query or an MRD advertisement received in native form
from a link indicates the presence of an IP multicast router on that
link.
IP multicast group membership reports have to be sent throughout the
campus to all IP multicast routers, distinguishing IPv4 and IPv6. All
multicast traffic must also be sent to all IP multicast routers for
the same version of IP.
IP multicast data SHOULD only be sent on links where there is either
an IP multicast router for that IP type (IPv4 or IPv6) or an IP
multicast group listener for that IP multicast derived MAC address.
RBridges do not need to announce themselves as listeners to the All-
Snoopers multicast group, used for MRD reports, because the IP
multicast address for that group is in the range where frames sent to
such addresses must be broadcast.
See also "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
[RFC4541].
4.6 End Station Address Details
RBridges have to learn the MAC addresses and VLANs of their locally
attached end stations for link/VLAN pairs for which they are the
appointed forwarder so they can
o forward the native form of incoming unicast TRILL data frames onto
the correct link and
o decide for an incoming native unicast frame from a link, where the
RBridge is the appointed forwarder, whether the frame is
- known to have been destined for another end station on the same
link, so the RBridge need do nothing, or
- know to be destined for another end station on another local
link where the RBridge is also appointed forwarder so it can be
directly forwarded in native form or
- neither of the above, so the frame has to be converted to a
TRILL data frame and forwarded.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 38]
INTERNET-DRAFT RBridge Protocol
4.6.1 Learning End Station Addresses
There are three ways an RBridge can learn end station addresses as
follows:
1. For links where it is the appointed VLAN-x forwarded and for VLAN
x frames, from the observation of data, learning the { source MAC,
VLAN, port } triplet of received native frames and the { source
MAC, VLAN, remote RBridge nickname } triplet of data frames that
it decapsulates.
2. By running a per VLAN IS-IS instance which receives remote
information and transmits local information.
3. By management configuration.
RBridges MUST implement capability 1 above and MUST use it unless
configured, for one or more particular VLANs and/or ports, to not
learn from either received local native frames or from decapsulated
TRILL data frames or both.
RBridges MAY implement capability 2 above. If implemented, such a per
VLAN IS-IS instance is run only when the RBridge is configured to do
so on a per VLAN basis.
Entries in the table of learned MAC addresses and ancillary
information also have a one octet unsigned confidence level
associated with each entry. Such information learned from the
observation of data has a confidence of 1 unless configured to have a
different confidence. Such information received via IS-IS is
accompanied by a confidence level in the range 0 to 254. Such
information configured by management defaults to a confidence level
of 255 but may be configured to have another value.
When a new learned address and related information are to be entered
into the local database there are several possibilities:
o If this is a new address, the information is entered accompanied
by the confidence level.
o If there is already an entry for this address with the same
accompanying information, the confidence level in the local
database is set to the maximum of its existing confidence level
and the confidence level with which it is being learned.
o If there is already an entry for this address with different
information, the learned information is ignored unless it is being
learned with higher or equal confidence than that in the database
entry.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 39]
INTERNET-DRAFT RBridge Protocol
4.6.2 Forgetting End Station Addresses
While RBridges need to learn end station addresses as described
above, it is equally important that they be able to forget such
information. Otherwise, frames for end stations that have moved to a
different part of the campus could be indefinitely black holed by
RBridges with stale information as to the link to which the end
station is attached.
The RBridge time out for locally learned end station address
information from the last time a native frame was received or
decapsulated with the information conforms to the recommendations of
[802.1Q]. It is configurable per RBridge with a default value of 300
seconds.
The situation is different for end station address information
acquired via a per VLAN IS-IS instance. It is up to the originating
RBridge to decide when to remove such information from the link state
(or up to IS-IS timeouts if the originating RBridge becomes
inaccessible).
4.7 Shared VLAN Learning
Although outside the scope of this specification, there are some
Layer 2 features in which a set of VLANs is considered to be a group,
where one of the VLANs is the "primary" and the other VLANs in the
group are "secondaries". An example of this is where traffic from
different communities are separated using VLAN tags, and yet some
resource (such as an IP router or DHCP server) is to be shared by all
the communities. A method of implementing this feature is to give a
VLAN tag, say Z, to a link containing the shared resource, and have
the other VLANs, say A, C, and D, be part of the group {primary=Z,
secondaries = A, C, D}. An RBridge, aware of this grouping, attached
to one of the secondary VLANs in the group also claims to be attached
to the primary VLAN. So an RBridge attached to A would claim to also
be attached to Z. An RBridge attached to the primary would claim to
be attached to all the VLANs in the group.
This specification does not specify how VLAN groups might be used.
Only RBridges that participate in a VLAN group will be configured to
know about the VLAN group. However, to detect misconfiguration, an
RBridge configured to know about a VLAN group SHOULD report the VLAN
group in its LSP.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 40]
INTERNET-DRAFT RBridge Protocol
5. Pseudo Code
This section provides partial high level pseudo code for the RBridge
processing of all possible types of received and generated IEEE 802.3
frames. In case of conflict between this section and any of the other
sections in this document, the pseudo code is authoritative; however,
certain optional processing is shown in the pseudo code with such
optionality being indicated. Of course, any other arrangement of
processing is fine as long as the results are the same as the pseudo
code in this section.
Frame destination address abbreviations used in this section are as
follows:
Abbreviation Destination Address(es)
------------------------------------------------------------
**** Any address.
802MUL Multicast address in the range 01-80-C2-00-00-00
to 01-80-C2-00-00-0F.
ALLRB The All-Rbridges multicast address, <tbd>.
ALLRBI The All-IS-IS-Rbridges multicast address, <tbd>.
BROAD The broadcast address: FF-FF-FF-FF-FF-FF
IP4MUL IPv4 based multicast addresses (the range
00-01-5E-00-00-00 to 00-01-5E-7F-FF-FF)
IP6MUL IPv6 based multicast addresses (the range
33-33-00-00-00-00 to 33-33-FF-FF-FF-FF)
OTHERM Multicast addresses other than ALLRB, IP4MUL,
IP6MUL, or 802MUL.
OTHERU Unicast addresses other than SELF.
SELF The unicast address of the Rbridge port at which
an operation is occurring.
Section 5.1 below discusses 802MUL addressed frames, most of which
are handled by the port and are partially or fully out of scope for
TRILL. Section 5.2 then discusses other received frames and frames
emitted in direct response to such other received frames. Section
5.3 discusses spontaneously emitted frames.
5.1 802MUL Destination Frames
Frames addressed to an 802MUL multicast address are sometimes handled
by a port under IEEE 802 protocols which are out of scope for
RBridges proper as show in Figure 8. Such frames, by definition, are
never forwarded by 802.1 customer bridges and are not forwarded by
RBridges.
An RBridge MAY learn source MAC address from such frames as described
in Section 5.2.2.1.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 41]
INTERNET-DRAFT RBridge Protocol
+------------------------------------------+
| +--------+ +---------+ |
| | Port | | Rbridge | |
| | | RBridge | Proper | |
| | +--+ | | | |
| | \| | | | | |
---------------------+ | | | | |
| | /| |/ | | \ | |
802MUL Frames | | | +- | - - - - - - - - - - - - | |
/ | | | |\ | | / | |
---------------------+ | | | | |
\ | | | | | | | |
| | +--+ | | +---+ | |
| \ | \| | \| | | |
----------------- | -------| -------------------+ | | |
| / | /| | /| | | |
Other Frames | | | Other Frames | | | | |
/ | | / | / | | | | |
----------------- | -------| -------------------+ | | |
\ | | \ | \ | | | | |
| | | | +---+ | |
| +--------+ +---------+ |
+------------------------------------------+
Figure 8. 802MUL and RBridge Frames
The following table give the sections where the various protocols
which use 802MUL multicast addresses are discussed:
Address Section and Description
---------------------------------------------------------
01-80-C2-00-00-00 5.1.1 All Bridges.
01-80-C2-00-00-01 5.1.2 [802.3] Clause 31 (PAUSE, etc)
01-80-C2-00-00-02 5.1.2 [802.3] Clause 43 ( Link
Aggregation) and Clause 57 (OAM)
01-80-C2-00-00-03 5.1.3 [802.1X] Port Authenticator
Entity (PAE)
01-80-C2-00-00-04/5 5.1.2 Reserved.
01-80-C2-00-00-06/7 5.1.6 Reserved.
01-80-C2-00-00-08 5.1.6 All Provider Bridges
01-80-C2-00-00-09/C 5.1.6 Reserved.
01-80-C2-00-00-0D 5.1.5 Provider Bridge GVRP Address
01-80-C2-00-00-0E 5.1.4 [802.1AB] Link Layer Discovery
Protocol
01-80-C2-00-00-0F 5.1.2 Reserved.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 42]
INTERNET-DRAFT RBridge Protocol
5.1.1 All Bridges Frames
Frames sent with the All Bridges multicast address
(01-80-C2-00-00-00) use the bridge protocol NSAP 0x42 so the frame
begins LL-LL-42-42-03-PP-PP where 0xLLLL is the length and the
trailing 0xPPPP indicates the particular All Bridges protocol.
If 0xPPPP is 0x0000 the frame is a BPDU (Bridge Protocol Data Unit),
used to implement the spanning tree protocol and further discussed
below. If 0xPPPP is 0x0001 the frame is a GARP (General Attribute
Registration Protocol) PDU discussed in Section 5.1.5 below.
An RBridge port MUST examine received BPDUs to determine the current
root bridge and advertise what it sees as the current root bridge on
that port via the core IS-IS instance (see Section 4.2.3). It would
be sufficient for the RBridge to test that the DSAP/SSAP are 0x4242,
the control octet is 0x03, and the first four octets of the BPDU
payload are zero. If so, the spanning tree root bridge identifier is
the eight octets from the sixth octet through the 13th octet. (The
fifth octet is an octet of flags that need not be examined by the
RBridge.) The last six of these eight octets are the part of the
root identifier reported in the LSP.(Octets six and seven include a
priority.) When MSTP (Multiple Spanning Tree Protocol) is running on
a link, this is the CIST (Common and Internal Spanning Tree) root.
Note: RBridges do not implement spanning tree or the spanning tree
state machine. Frames are not blocked from admission to an RBridge
except as provided in this TRILL protocol specification. It is never
the case that a bridging spanning tree extends through an RBridge
between two of its ports. Those ports always terminate the spanning
tree. See also section 5.3.1.
5.1.2 Media Multicast Frames
These frames are for media specific port features or are reserved for
the future standardization of such features. Such features are
outside of the scope of TRILL which is generally media independent.
5.1.3 802.1X Frames
This port protocol provides for the authentication of end stations as
specified in [802.1X]. That an end station has been so authenticated
MAY be used to increase the confidence in end station MAC addresses
reported via the optional per VLAN IS-IS instance (see Section
4.6.1). These frames are also identified by Ethertype 0x888E.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 43]
INTERNET-DRAFT RBridge Protocol
An amendment to 802.1X [802.1af] is under development such that
802.1X authentication would produce keying material usable in
[802.1AE] which can in turn be used to authenticate and encrypt
frames between ports.
5.1.4 802.1AB Frames
Frames with this multicast address are used in the Station and Media
Access Control Connectivity Discovery standard [802.1AB] which
specifies the Local Link Discovery Protocol (LLDP). These frames are
also identified by the Ethertype 0x88CC.
This protocol is generally outside of the scope of TRILL but see
Section 5.3.1.
5.1.5 GARP, GMRP, and GVRP
IEEE [802.1D] bridging defines a Generic Attribute Registration
Protocol, GARP, on which a GARP Multicast Registration Protocol,
GMRP, and a GARP VLAN Registration Protocol, GVRP, are based. GARP
uses the bridge spanning tree protocol NSAP 0x42 and the frame begins
LL-LL-42-42-03-00-01 where 0xLLLL is the length and the trailing
0x0001 indicate the frame is a GARP PDU (see also Section 5.1.1).
The multicast addresses in the range 01-80-C2-00-00-20 to
01-80-C2-00-00-2F have been reserved for GARP applications. [802.1D]
requires that bridges transparently propagate frames to any multicast
address in this range if they do not implement the corresponding GARP
application. RBridges do not implement any of these applications.
They treat such frames as any other non-IP-derived Layer 2 multicast.
The GMRP application of GARP uses multicast address
01-80-C2-00-00-20. It would provide a basis for the optimization of
the distribution of frames with Layer 2 multicast addresses. However,
RBridges provide for optional automatic IP based multicast
optimization instead.
The GVRP application of GARP uses multicast address
01-80-C2-00-00-21. It provides for the registration of VLANs and is
not supported by RBridges.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 44]
INTERNET-DRAFT RBridge Protocol
5.1.6 Other Bridge Multicast Frames
These frames relate to other bridge features outside of the scope of
TRILL or are reserved for future standardization of such features.
5.2 Processing a Frame Received by an RBridge
The RBridge performing the processing is RBn.
/* Ethertype abbreviations used are as follows:
------------------------------------------------------
**** Any Ethertype.
IP** IPv4 or IPv6 message Ethertype.
IPv4 0x0800 IP version 4 message Ethertype.
IPv6 0x86DD IP version 6 message Ethertype.
ISIS 0xFE IS-IS Message NSAP value.
TRILL <TBD> TRILL frame Ethertype.
*/
if ( port administratively disabled )
{
exit; /* discard frame */
}
/* Set per frame global data */
Frame-VLAN = Determine Frame VLAN per Section 4.1.3;
Frame-priority = Determine Frame Priority per Section 4.1.3;
Frame-protocol = Extract Frame Ethertype / NSAP;
AF = Appointed Forwarder status of RBn for Frame-VLAN for
receiving port;
The Frame-protocol, Outer.MacDA, and AF are then used to sequentially
search the table below from the top. As soon as a match is found,
the processing indicated (either discard the frame or process as give
in the reference) is performed.
The "AF" column is "Y" if the RBridge must be the appointed forwarder
on that port for Frame-VLAN, "N" if it must not be the appointed
forwarder, and "*" if it does not matter.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 45]
INTERNET-DRAFT RBridge Protocol
Sequential Table: Search from top for first match
Ethertype Dest. AF Section/Description
------------------------------------------------------------
TRILL SELF * 5.2.3 TRILL encapsulated frame.
TRILL OTHERU * TRILL encapsulated frame addressed
to another Rbridge; discard.
TRILL ALLRB * 5.2.3 TRILL encapsulated frame.
TRILL BROAD * Erroneous frame but MAY be treated
as if Destination was ALLRB.
**** ALLRB * Erroneous frame; discard.
**** ALLRBI * Erroneous frame; discard.
**** 802MUL * 5.1 Should not get here.
IP** **** Y 5.2.1 Process IP frame.
**** IPMUL * Erroneous frame; discard.
**** **** Y 5.2.4 Process native frame.
**** **** N Discard native frame.
5.2.1 Further Dispatch for IP Frames
Frames containing IP (Internet Protocol) payload, both IPv4 and IPv6,
are treated in different ways depending on the particular protocol
within IP which they are carrying. The following table is searched
sequentially from the top and the first match used. The "Ver."
column is the version of IP used in the frame and "Proto" is the
Payload IP protocol for the frame.
Ver. Proto Section/Description
------------------------------------------------------------
IPv4 IGMP 5.2.5 Internet Group Membership Protocol
IPv6 MLD 5.2.5 Multicast Listener Discovery
IP** MRD 5.2.6 Multicast Router Discovery
IP** **** 5.2.4 Other
5.2.2 Common Subroutines
The following pseudo code subroutines are called from several places
in Section 5.
5.2.2.1 Learn Source MAC Address
If this pseudo code subroutine is called more than once for the same
frame, all calls after the first have no effect and do not actually
have to be performed.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 46]
INTERNET-DRAFT RBridge Protocol
if (Outer.MacSA has the "group" bit off)
{
Learn Outer.MacSA for the port on which the frame was
received for the determined VLAN unless configured
not to do such learning.
}
5.2.2.2 TRILL Frame Multi-destination Forwarding
Forward a TRILL Frame over a distribution tree with VLAN pruning.
{{ This code needs to be extended to perform similar pruning for
multicast frames being forwarded to that done by Section 5.2.4 on
received multicast native frames.}}
if ( (Trill.HopCount = 0 ) or
(RPF check fails on Outer.MacSA (Section 4.3.1) )
{
Exit; /* do not forward the frame */
}
else
{
For ( all ports from RBn on the tree rooted at the
Trill.EgressNickname except that on which the
frame was received )
{
if ( no downstream RBridges for Inner.VLAN )
{
Continue to next "for" value;
}
Execute 5.2.2.3;
}
}
5.2.2.3 TRILL Data Frame Tree Transmission
Trill.HopCount -= 1 /* at least, see Section 3.4 */
Outer.MacDA = ALLRB (or optionally, if there is
only one destination, its unicast address).;
Execute 5.2.2.4
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 47]
INTERNET-DRAFT RBridge Protocol
5.2.2.4 TRILL Data Frame Transmission
Outer.MacSA = MAC address of the port on which the
frame is being sent;
Outer.VLAN = DRB specified RBridge traffic VLAN for
the port on which the frame is being sent;
Outer.priority = Inner.priority;
Include or omit Outer C-tag / priority tag as per
802.1Q customer bridge port transmission rules;
Transmit frame out port;
5.2.3 TRILL Ethertype Frames
if (Version > 0)
{
Discard the frame, unknown format.
}
elseif (Inner.MacDA == ALLRBI) /* IS-IS */
{
Execute Section 5.2.3.1.
}
else /* Inner.MacDA != ALLRBI, Data */
{
Execute Section 5.2.3.2.
}
5.2.3.1 TRILL IS-IS Frames
/* get here for TRILL Ethertype frames where Outer.MacDA is
either ALLRB or SELF and the Inner.MacDA is
All-IS-IS-Rbridges. TRILL Ethertype frames with other
Outer.MacDA values are discarded by the dispatch table */
if ( (Multi-Destination == 0) or
(Inner.Protocol Type != ISIS ) or
(Outer.MacSA !=
a tree adjacency for tree indicated) )
{
Discard the frame.
}
elseif (inner VLAN tag not present)
{
Process payload as a core TRILL IS-IS message
for RBn.
Note: nicknames may be invalid, ignore them.
}
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 48]
INTERNET-DRAFT RBridge Protocol
else /* inner VLAN tag is present */
{
If RBn has end stations on links for which it is the
appointed forwarder for the indicated VLAN, give the
IS-IS message to the per VLAN IS-IS instance if
implemented.
Execute 5.2.2.2; /* forward VLAN pruned */
}
5.2.3.2 TRILL Data Frames
/* get here for TRILL Ethertype frames where Outer.MacDA is
either ALLRB or SELF and the Inner.MacDA is not
All-IS-IS-Rbridges. TRILL Ethertype frames with other
Outer.MacDA values are discarded by the dispatch table */
if (Trill.M == 1)
{ /* a multi-destination frame */
If (Outer.MacSA !=
a tree adjacency for tree indicated) )
{
Discard the frame.
}
else
{
If RBn is an appointed forwarder for the indicated VLAN,
decapsulate the data frame and forward it onto appropriate
links in the VLAN.
Execute Section 5.2.2.2.
}
}
else /* Trill.M == 0 */
{
if (Trill.EgressNickname == RBn)
{
If (Inner.MacDA is a group address)
{
Discard the frame.
}
Convert to native format and forward the extracted
frame onto the link containing the destination or,
if you don't know the destination, onto all local
links in the Inner.VLAN for which you are an
appointed forwarder.
Locally process the frame if the Inner.MacDA == RBn.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 49]
INTERNET-DRAFT RBridge Protocol
}
else
{ /* The frame needs to be forwarded to another RBridge */
if (Trill.HopCount = 0)
{
Discard the frame.
}
else
{
if (Trill.EgressNickname unknown)
{
Discard the frame.
}
Outer.MacDA = LookUpNextHop(Trill.EgressNickname);
Outer.MacSA = MAC address of the port on which the
frame is being sent;
Outer.VLAN = DRB specified RBridge traffic VLAN for
the port on which the frame is being sent;
Outer.priority = Inner.priority;
Include or omit Outer C-tag / priority tag as per
802.1Q customer bridge port transmission rules;
Transmit frame out port;
}
}
5.2.4 Native Frame Receipt
The following pseudo code is executed for frames that are not of the
TRILL Ethertype and are received on a port and VLAN for which the
RBridge is the appointed forwarder (see Section 4.2.4).
Execute Section 5.2.2.1.
if (Outer.MacDA == SELF)
{
Process locally;
/* A native frame for the RBridge received from a local
link, for example a management protocol frame from a
directly connected management station. */
}
elseif (Outer.MacDA is a known unicast address)
{
if (Outer.MacDA is on the directly connected link on
which the frame was received)
{
Exit; /* Destination has already seen it */
}
elseif (Outer.MacDA in Frame-VLAN is on another
directly connect link)
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 50]
INTERNET-DRAFT RBridge Protocol
{
Include or omit Outer C-tag / priority tag as per
802.1Q customer bridge port transmission rules;
Forward the native frame out the port for the link.
}
else
{
/* Assume that the egress RBridge is RBm */
Inner.VLAN = Frame-VLAN;
Inner.priority = Frame-priority;
Trill.V = 0;
Trill.R = 0;
Trill.M = FALSE; /* this is not multi-destination */
Trill.HopCount = determined value (see Section 3.4);
Trill.EgressNickname = RBm;
Trill.IngressNickname = RBn;
Outer.MacDA = LookUpNextHop(Trill.EgressNickname);
Outer.Ethertype = TRILL;
Execute Section 5.2.2.4;
}
else
{ /* unknown unicast or general multicast or broadcast */
Forward in native form to other links where RBn is the
appointed forwarder for Frame-VLAN;
Inner.VLAN = Frame-VLAN;
Inner.priority = Frame-priority;
Trill.V = 0;
Trill.R = 0;
Trill.M = TRUE; /* this is a multi-destination frame */
Trill.EgressNickname = RBi /* Distribution Tree, See below */
Trill.IngressNickname = RBn;
Outer.Ethertype = TRILL;
For ( all ports from RBn on the tree rooted at the
Trill.EgressNickname )
{
if ( no downstream RBridges for Frame-VLAN for this port )
{
Continue to next "for" value;
}
if ( ( Inner.MacDA <= 00-01-5E-7F-FF-FF ) and
( Inner.MacDA >= 00-01-5E-00-00-00 ) )
{
returnValue = Execute 5.2.4.1;
}
elseif ( ( Inner.MacDA <= 33-33-FF-FF-FF-FF ) and
( Inner.MacDA >= 33-33-00-00-00-00 ) )
{
returnValue = Execute 5.2.4.2;
}
elseif ( ( Inner.MacDA == FF-FF-FF-FF-FF-FF ) or
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 51]
INTERNET-DRAFT RBridge Protocol
( Inner.MacDA == ALLRBI ) )
{
returnValue = True;
}
elseif ( no downstream RBridges with Other Multicast
bit set for Frame-VLAN )
{
returnValue = False;
}
else
{
returnValue = True;
}
if ( returnValue )
{
Trill.HopCount = determined value (see Section 3.4);
Execute 5.2.2.3;
}
} /* end For */
}
In the last case above, the egress nickname indicates the chosen
distribution tree RBi. The default is for RBn to put its own address
there. However, if RBn is configured to decline to be a tree root,
then RBn MUST select some other RBridge RBi which has elected to be a
tree root or the RBridge with the lowest ID if none have elected to
be a tree root.
5.2.4.1 Native IPv4 Multicast Frame
if ( Frame-protocol != IPv4 )
{
return ( False ); /* inconsistent frame */
}
elseif ( frame is an IGMP announcement )
{
if ( there are downstream IPv4 multicast routers )
{
return ( True );
}
else
{
return ( False );
}
}
elseif ( IPv4 Destination multicast address is in the range
which must be broadcast )
{
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 52]
INTERNET-DRAFT RBridge Protocol
return ( True );
}
elseif ( there is a downstream listener or IPv4
multicast router for Inner.MacDA )
{
return ( True );
}
else
{
return ( False );
}
5.2.4.2 Native IPv6 Multicast Frame
if ( Frame-protocol != IPv6)
{
return ( False ); /* inconsistent frame */
}
elseif ( frame is an NLD announcement )
{
if ( there are downstream IPv6 multicast routers )
{
return ( True );
}
else
{
return ( False );
}
}
elseif ( IPv6 Destination multicast address is in the range
which must be broadcast )
{
return ( True );
}
elseif ( there is a downstream listener or IPv6
multicast router for Inner.MacDA )
{
return ( True );
}
else
{
return ( False );
}
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 53]
INTERNET-DRAFT RBridge Protocol
5.2.5 IGMP and MLD Frames
An IGMP (IPv4 [RFC3376]) or MLD (IPv6 [RFC2710]) announcement
received from a link by the appointed forwarder for Frame-VLAN
teaches RBn a group membership on that link. RBn adds receiver for
that Layer 2 group address for Frame-VLAN in its core link state
instance.
Then execute Section 5.2.4.
5.2.6 MRD Frames
An MRD [RFC4286] reply or IGMP [RFC3376] query or MLD [RFC2710] query
received from a link by the appointed forwarder for Frame-VLAN
teaches RBn that there is an IP multicast router on that link. RBn
adds that information, for IPv4 or IPv6 as appropriate, into its core
IS-IS link state information for Frame-VLAN.
Then execute Section 5.2.4.
5.3 Frames Spontaneously Sourced
The sections below discuss all frames that might be spontaneous
sourced by an RBridge.
5.3.1 Bridge/Media Frames Sourced
RBridges are not required to originate any of the frames discussed in
Section 5.1 (although it may be necessary for an 802.3 port to
implement PAUSE to operate correctly in the presence of allowed clock
skew).
An RBridge port may optionally emit BPDUs as described in Section
6.2.2. However, RBridges do not implement spanning tree or the
spanning tree state machine. It is never the case that a bridging
spanning tree extends through an RBridge between its ports. Those
ports always terminate the spanning tree.
If an Rbridge port implements [802.1X], this MAY be used in
determining the confidence level of learned addresses (see Section
5.1.3).
If an RBridge port sources [802.1AB] frames, also known as Local Link
Discovery frames, containing the System Capabilities 802.1AB TLV, it
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 54]
INTERNET-DRAFT RBridge Protocol
is RECOMMENDED that the "bridge" bit be asserted in the "system
capabilities" subfield and if that port is participating in spanning
tree, then it is RECOMMENDED that the "bridge" bit be asserted in the
"enabled capabilities" subfield.
Other bridge/media frames may also be sourced by an RBridge port and
are generally out of scope for this document.
5.3.2 IS-IS Frames Sourced
An RBridge R1 MUST spontaneously emit core instance TRILL IS-IS
frames as described in 5.3.2.1. In addition, if it is appointed
forwarder for a link that has end stations in a particular VLAN, it
MAY run an IS-IS instance for that VLAN and emit TRILL per-VLAN IS-IS
frames as described in 5.3.1.2.
Do not confuse the per VLAN DRB determination, which is done by the
core IS-IS instance, with the optional per VLAN IS-IS instances used
to distribute end station addresses.
5.3.2.1 Core IS-IS Frames
For core IS-IS frames, a TRILL header is added and no VLAN tag is
included in the inner frame. The 802.3 LLC NSAP format MUST be used,
that is LL-LL-FE-FE-03 where 0xLLLL is the length, 0x03 is the CTL
octet, and 0xFE is the NSAP for IS-IS. (The IS-IS standard also
permits the less efficient SNAP SAP format LL-LL-AA-
AA-03-00-00-00-80-FE which is not used in TRILL.)
The frame it is formed as follows:
Outer.MacDA = ALLRB;
Outer.MacSA = RBn; // MAC address of transmission port
Outer.Ethertype = TRILL.
Trill.V = 1;
Trill.R = 0;
Trill.M = 1;
Trill.HopCount = 1;
Trill.IngressNickname = 0;
Trill.EgressNickname = 0;
Inner.MacDA = ALLRBI;
Inner.MacSA = RBn;
Inner.FrameLength = IS-IS frame length;
Inner.DSAP = 0xFE;
Inner.SSAP = 0xFE;
Inner.CTL = 3;
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 55]
INTERNET-DRAFT RBridge Protocol
followed by the rest of the IS-IS Frame.
The frame is then sent out all ports of the RBridge if it is a Hello.
If it is a non-Hello, it is sent out all ports on which there is an
IS-IS adjacency. For each port not either known to be a point-to-
point connection to an Rbridge or configured not to use Outer VLAN
Tags, an Outer VLAN Tag is added as follows:
Outer VLAN Tag priority = 7;
Outer VLAN VLAN ID = ID associated with the logical port on
which the frame is being sent or zero if none.
Note that this Outer VLAN Tag may be different on different ports.
The Inner.MacDA is always All-IS-IS-Rbridges for all TRILL IS-IS
frames. Furthermore, core instance TRILL IS-IS Hellos MUST always be
send out all enabled ports to the All-Rbridges multicast address.
However, non-Hello core TRILL IS-IS messages for which there is only
one destination MAY be send to a unicast Outer.MacDA as follows:
Outer.MacDA = DestinationRBridge;
Outer.MacSA = RB1; // MAC address of transmission port
Outer.Ethertype = TRILL.
Trill.V = 1;
Trill.R = 0;
Trill.M = 0;
Trill.HopCount = 1;
Trill.IngressNickname = 0;
Trill.EgressNickname = 0;
Inner.MacDA = DestinationRBridge;
Inner.MacSA = RB1;
Inner.FrameLength = IS-IS frame length;
Inner.DSAP = 0xFE;
Inner.SSAP = 0xFE;
Inner.CTL = 3;
followed by the rest of the IS-IS Frame.
The frame is then transmitted on the port for DestinationRBridge with
an Outer VLAN Tag possibly added using the same logic as for a
multicast core TRILL IS-IS frame above.
5.3.2.2 Per-VLAN IS-IS Frames
For per VLAN TRILL IS-IS frames, a TRILL header is added and a VLAN
tag is always included in the inner frame. Note that, in a strict
sense, IS-IS has no Ethertype but the 802.3 NSAP format must be used
as discusses at the start of section 5.3.2.1.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 56]
INTERNET-DRAFT RBridge Protocol
If the frame is per VLAN multicast, it is formed as follows:
Outer.MacDA = All-RBridges;
Outer.MacSA = RB1;
Outer.Ethertype = TRILL.
Trill.V = 0;
Trill.R = 0;
Trill.M = 1;
Trill.HopCount = count to reach farthest node in the
distribution tree;
Trill.IngressNickname = RB1 nickname;
Trill.EgressNickname = SelectedDistributionTree;
Inner.MacDA = All-IS-IS-RBridges;
Inner.MacSA = RB1;
Ethertype = VLAN Tag;
Inner VLAN Tag priority = 7;
Inner.VLAN = Relevant VLAN;
Inner.FrameLength = IS-IS frame length
Inner.DSAP = 0xFE;
Inner.SSAP = 0xFE.
Inner.CTL = 3;
followed by the rest of the IS-IS Frame.
The frame is then sent out the ports appropriate for the selected
distribution tree pruned to the selected VLAN. The presence or
absence of downstream RBridges with the Other Multicast (OM) flag on
for that VLAN is ignored and the frame is distributed to all RBridges
that indicate they are connected to that VLAN. Other than this
special handling of downstream Other Multicast flags, per VLAN
instance TRILL IS-IS frames are distributed like any other non-IP-
derived Layer 2 multicast.
5.3.3 Other Frames Sourced
Other frames may be sourced due to management protocols or general
applications running on an RBridge. These can be handled as if they
were received by the RBridge on a port for which it was the appointed
forwarder and on which there were no know directly connected
stations, as described in Section 5.2.4.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 57]
INTERNET-DRAFT RBridge Protocol
6. Incremental Deployment Considerations
Because RBridges are generally compatible with current IEEE 802.1
bridges, a LAN can be upgraded by incrementally replacing bridges
with RBridges. Any remaining bridges are invisible to RBridges and
the physical links directly interconnected by such bridges, which,
together with the bridges, constitute bridged LANs, appear to
RBridges to be multi-access links. If the bridges that were replaced
by RBridges were un-managed, zero configuration bridges, then the
RBridge replacements will not require configuration.
The campus will work best if all IEEE 802.1 bridges are replaced with
RBridges, assuming the RBridges have the same basic speed and
capacity as the bridges. However, there may be intermediate states,
where only some bridges have been replaced by RBridges.
6.1 VLAN Connectivity Changes
Even with partial RBridge deployment, RBridges will provide
connectivity between all links in a particular VLAN that are
connected to any one RBridge, assuming TRILL connectivity between the
RBridges themselves. This is true even where the bridged LAN into
which the RBridges are being introduced was myopically configured so
as to partition one or more particular VLANs into unconnected
islands.
6.2 Link Cost Determination
With an RBridged campus having no bridges on the links between
RBridges, the RBridges can accurately determine the number of
physical hops involved in a path and the line speed of each hop
assuming this is reported by their port logic. With intervening
bridges, this is no longer possible. For example, as shown in Figure
9, the two bridges B1 and B2 can completely hide a slow link so that
both Rbridges RB1 and RB2 incorrectly believe the link is faster.
+-----+ +----+ +----+ +-----+
| | Fast | | Slow | | Fast | |
| RB1 +--------+ B1 +--------+ B2 +--------+ RB2 |
| | Link | | Link | | Link | |
+-----+ +----+ +----+ +-----+
Figure 9, Link Cost of a Bridged Link
Even in the case of a single intervening bridge, two RBridges may
know they are connected but each see the link as a different speed
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 58]
INTERNET-DRAFT RBridge Protocol
from how it is seen by the other.
6.3 Appointed Forwarders and Bridged LANs
With partial RBridge deployment, the RBridges may partition a bridged
LAN into a relatively small number of relatively large remnant
bridged LANs. Then two potential problems can occur as follows:
1. The requirement that end station frames enter and leave a link via
the appointed forwarder for the link and VLAN of the frame can
cause congestion or suboptimal routing. (Similar problems can
occur within a bridged LAN due to the spanning tree algorithm.)
The extent to which such a problem will occur is highly dependent
on the network topology. For example, if a bridged LAN had a star-
like structure with core bridges that connected to other bridges
and peripheral bridges that connected to end stations and singly
connected to a core bridge, the replacement of all of the core
bridges by RBridges without replacing the peripheral bridges would
generally improve performance without inducing any appointed
forwarder congestion. Solutions to this problem are discussed
below in this section and a particular example explored in Section
6.4.
2. TRILL traffic sent to the All-Rbridge multicast address will
typically be flooded throughout a bridged LAN link which may
create a greater burden than necessary. In cases where there is
actually only one intended RBridge next hop recipient, this
problem can be eliminated by using the option of sending the TRILL
traffic as a unicast frame to that recipient rather than
multicasting it. (Since one purpose of IS-IS Hello frames is to
find previously unknown Rbridges, they must always be multicast.)
Inserting RBridges so that all the bridged portions of the LAN stay
connected to each other and have multiple RBridge connections is
generally the least efficient arrangement.
There are four techniques which may help if problem 1 above occurs
and which can, to some extent, be used in combination:
1. Replace more IEEE 802.1 bridges with RBridges so as to minimize
the size of the remnant bridged LANs between RBridges. This
requires no configuration of the RBridges unless the bridges they
replace required configuration.
2. Re-arrange network topology to minimize the problem. If the
bridges and RBridges involved are configured, this may require
changes in their configuration.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 59]
INTERNET-DRAFT RBridge Protocol
3. Configure the RBridges and bridges so that end stations on a
remnant bridged LAN are separated into different VLANs that have
different appointed forwarders. If the end stations were already
assigned to different VLANs, this is straightforward (see Section
4.2.4). If the end stations were on the same VLAN and have to be
split into different VLANs, this technique may lead to
connectivity problems between end stations but it may be possible
to overcome these problems using shared VLANs (see Section 4.7).
4. Configure the RBridges such that their ports which are connected
to the bridged LAN emit BPDUs (see Section 5.1.1) in such a way as
to force the partition of the bridged LAN. (Note: a spanning tree
is never formed through an RBridge but always terminates at
RBridge ports.) To use this technique, the RBridges must support
this optional feature, and would need to be configured to make use
of it but the bridges involved would rarely have to be configured.
Warning: This technique makes the bridged LAN unavailable for
TRILL through traffic because the bridged LAN partitions.
Conversely to item 3 above, there may be bridged LANs which use
VLANs, or use more VLANs than would otherwise be necessary, to evade
the congestion that can be caused by the spanning tree protocol.
Replacing the IEEE 802.1 bridges in such LANs with RBridges may
enable a reduction in or elimination of VLANs and configuration
complexity.
6.4 Wiring Closet Topology
If 802.1 bridges are present and RBridges are not configured, the
bridge spanning tree or the appointed forwarder designation may make
inappropriate decisions. Below is a detailed example of the more
general problem that can occur when a bridge LAN is connected to
multiple RBridges.
In cases where there are two (or more) groups of end nodes, each
attached to a bridge (say B1 and B2 respectively), and each bridge is
attached to an RBridge (say RB1 and RB2 respectively), with an
additional link connecting B1 and B2 (see Figure 10), it may be
desirable to have the B1-B2 link only as a backup in case one of RB1
and RB2, or one of the links B1-RB1 or B2-RB2 fail.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 60]
INTERNET-DRAFT RBridge Protocol
+-------------------------------+
| | | |
| Data +-----+ +-----+ |
| Center -| RB1 |----| RB2 |- |
| +-----+ +-----+ |
| | | |
+-------------------------------+
| |
| |
+-------------------------------+
| | | |
| +----+ +----+ |
| Wiring | B1 |-----| B2 | |
| Closet +----+ +----+ |
| |
+-------------------------------+
Figure 10. Wiring Closet Topology
For example, B1 and B2 may be in a wiring closet and it may be easy
to provide a short high bandwidth low cost link between them while
RB1 and RB2 are at a distant data center such that the RB1-B1 and
RB2-B2 links are slower and more expensive.
Default behavior would be that one of RB1 or RB2 (say RB1) would
become DRB for the bridged LAN including B1 and B2 and appoint itself
forwarded for the VLANs on that bridged LAN. As a result, RB1 would
forward all traffic to/from the link, so end nodes attached to B2
would be connected to the campus via the path B2-B1-RB1, rather than
the desired B2-RB2. This wastes the bandwidth of the B2-RB2 path and
cuts available bandwidth between the end stations and the data center
in half. The desired behavior would probably be to make use of both
the RB1-B1 and RB2-B2 links.
Three solutions to this problem are described below.
6.4.1 The RBridge Solution
Of course, if B1 and B2 are replaced with RBridges, the right thing
will happen with zero configuration, but this may not be immediately
practical if bridges are being incrementally replaced by RBridges.
6.4.2 The Spanning Tree Solution
Another solution is to configure RB1 and RB2 to be part of a "wiring
closet group", with a configured System ID RBx (which may be RB1 or
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 61]
INTERNET-DRAFT RBridge Protocol
RB2's System ID). Both RB1 and RB2 emit BPDUs on the configured ports
as root RBx, which causes the spanning tree to partition the bridged
LAN and break the B1-B2 link as desired, and both RB1 and RB2 act as
Designated RBridge and appointed forwarder on each of their
respective partitions. Of course, with the partition, no TRILL
through traffic can flow over the RB1-B1-B2-RB2 path.
In the BPDU, the Root is "RBx", cost to Root is 0, Designated Bridge
ID is "RB1" when R1 transmits and "RB2" when R2 transmits, and port
ID is a value chosen independently by each of RB1 and RB2 to
distinguish each of its own ports. If RB1 and RB2 were actually on
the same shared medium with no bridges between them, the result is
that the one with the larger ID sees "better" BPDUs (because of the
tie-breaker on the third field; the ID of the transmitting RBridge),
and turns off the port.
Should either the RB1 or the RB1-B1 link or RB2 or the RB2-B2 link
fail, the spanning tree algorithm will stop seeing one of the RBx
roots and will re-enable the B1-B2 link maintaining connectivity of
all the end stations with the data center.
If the link RB1-B1-B2-RB2 is on the cut set of the campus and RB2
and/or RB1 have been configured to believe they are part of a wiring
closet group the campus becomes partitioned as the link partitions.
6.4.3 The VLAN Solution
If the end stations attached to B1 and B2 are already divided among a
number of VLANs, RB1 and RB2 could be configured so that which ever
becomes DRB for this link will appoint itself for some of these VLANs
and the other RBridge for the remaining VLANs. Should either of the
RBs fail or become disconnected, the other will have only itself to
appoint for all the VLANs.
If the end stations are all on a single VLAN, then it would be
necessary to arbitrarily assign them between at least two VLANs to
use this solution. This may lead to connectivity problems which might
require further measures, outside the scope of this specification, to
rectify.
6.4.4 Comparison of Solutions
Replacing all 802.1 bridges with RBridges is usually the best
solution with the least amount of configuration required, possibly
none.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 62]
INTERNET-DRAFT RBridge Protocol
The spanning tree solution does quite well in this particular case.
But it depends on both RB1 and RB2 having implemented the optional
feature of being able to configure a port to emit BPDUs as described
in Section 6.4.2 above. It also makes the bridged LAN whose partition
is being forced unavailable for through traffic Finally, while in
this specific example it neatly breaks the link between the two
bridges B1 and B2, if there were a more complex bridged LAN, instead
of exactly two bridges, there is no guarantee that it would partition
into roughly equal pieces. In such a case, you might end up with a
highly unbalanced load on the RB1 link and the RB2 link.
The VLAN solution works well with a relatively small amount of
configuration if the end stations are already divided among a number
of VLANs. If they are not, it becomes more complex and problematic.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 63]
INTERNET-DRAFT RBridge Protocol
7. RBridge Addresses, Parameters, and Constants
IS-IS requires each RBridge to have a unique 6-octet System ID. This
is easily obtainable, for example, as any one of the 6-octet MAC
addresses owned by that RBridge.
A new Ethertype must be assigned to indicate a TRILL encapsulated
frame.
Two Layer 2 multicast addresses must be assigned. All-RBridges for
use as the destination address in multi-destination frames. And All-
IS-IS-RBridges as the inner destination MAC address for TRILL IS-IS
frames.
To support VLANs, RBridges (like bridges today), must be configured
appropriately. RBridge ports may also be configured to map frame
priorities (see Section 4.1.3).
RBridges may be configured with a nickname and nickname selection
priority.
RBridges may be configured to have per VLAN IS-IS instances and to
send and/or learn end station address information via such instances.
Static end address information and priority of such end station
information statically configured and learned in various ways can
also be configured.
The per RBridge parameter RequestTree that indicates whether an
RBridge wants to be the root of a distribution tree which defaults to
true.
The per RBridge per VLAN Other Multicast bit, which defaults to true,
to request the receipt of non-IP derived multicast traffic.
Configuration for the spanning tree solution to the wiring closet
topology problem (see Section 6.4.2) consists of System ID of the
RBridge with lowest System ID. If RB1 and RB2 are part of a wiring
closet topology, only RB2 needs to be configured to know about this,
and that RB1 is the ID it should use in the spanning tree protocol on
the specified port.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 64]
INTERNET-DRAFT RBridge Protocol
8. Security Considerations
Layer 2 bridging in not inherently secure. It is, for example,
subject to forgery of source addresses and bridging control messages.
A goal for TRILL is that RBridges do not add new issues beyond those
existing in current bridging technology.
TRILL encapsulates native frames inside the TRILL Ethertype while
they are in transit between that frame's ingress and egress RBridge.
Thus, TRILL ignorant devices, such as bridges with firewall features,
will not generally be able to examine the interior of such frames for
security checking purposes and may be less effective. (Since routers
appear to RBridges to be end stations, such frames will be
decapsulated before being sent to a router.) Such "firewall bridges"
should be modified to understand TRILL encapsulation.
Countermeasures are available such as to configure the RBridge IS-IS
instances to use IS-IS security [RFC3567] and ignore unauthenticated
control messages received on a port. Since such authentication
requires configuration, RBridges using it are no longer zero
configuration.
IEEE 802.1 port admission and link security mechanisms, such as
[802.1X] and [802.1AE], can also be used. These are best thought of
as being implemented within a port and are outside the scope of TRILL
proper (just as they are generally out of scope for bridging
standards 802.1D and 802.1Q) although TRILL can make use of secure
registration through the confidence level communicated in the
optional per VLAN IS-IS instance (see Section 4.6).
RBridges do not prevent nodes from impersonating other nodes, for
instance, by issuing bogus ARP/ND replies. However, RBridges do not
interfere with any schemes that would secure neighbor discovery.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 65]
INTERNET-DRAFT RBridge Protocol
9. Assignment Considerations
This section discuses IANA and IEEE 802 assignment considerations.
9.1 IANA Considerations
A new IANA registry is created for TRILL.
New TRILL Header Version numbers and uses of TRILL Header Reserved
bits are assigned by an IETF Standards Action [RFC2434] as modified
by [RFC4020].
9.2 IEEE 802 Assignment Considerations
The Ethertype <tbd> is assigned by IEEE 802 to indicate a TRILL
encapsulated frame.
The Layer 2 multicast addresses <tbd1> and <tbd2> are assigned by
IEEE 802 for "All-Rbridges" and "All-IS-IS-Rbridges".
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 66]
INTERNET-DRAFT RBridge Protocol
10. Normative References
[802.1D] "IEEE Standard for Local and metropolitan area networks /
Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004.
[802.1Q] "IEEE Standard for Local and metropolitan area networks /
Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.
[802.3] "IEEE Standard for Information technology /
Telecommunications and information exchange between systems /
Local and metropolitan area networks / Specific requirements Part
3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications",
802.3-2005, 9 December 2005
[ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate
system routeing information exchange protocol for use in
conjunction with the Protocol for providing the Connectionless-
mode Network Service (ISO 8473)," ISO/IEC 10589:2002.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, Stanford University, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-Standard
Management Framework", RFC 3410, December 2002.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4286] Haberman, B., Martin, J., "Multicast Router Discovery", RFC
4286, December 2005.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 67]
INTERNET-DRAFT RBridge Protocol
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network
Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789,
November 2006.
11. Informative References
[802.1AB] "IEEE Standard for Local and metropolitan area networks /
Station and Media Access Control Connectivity Discovery",
802.1AB-2005, 6 May 2005.
[802.1AE] "IEEE Standard for Local and metropolitan area networks /
Media Access Control (MAC) Security", 802.1AE-2006, 18 August 2006
[802.1X] "IEEE Standard for Local and metropolitan area networks /
Port Based Network Access Control", 802.1X-2004, 13 December 2004.
[Arch] Gray, E., "The Architecture of an RBridge Solution to TRILL",
draft-ietf-trill-rbridge-arch-03.txt, October 2006, work in
progress.
[PAS] Touch, J., & R. Perlman, "Transparent Interconnection of Lots
of Links (TRILL) / Problem and Applicability Statement", draft-
ietf-trill-prob-01.txt, October 2006, work in progress.
[RBridges] Perlman, R., "RBridges: Transparent Routing", Proc.
Infocom 2005, March 2004.
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic Authentication", RFC
3567, July 2003.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541,
May 2006.
[RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches,
and Internetworking Protocols", Addison Wesley Chapter 3, 1999.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 68]
INTERNET-DRAFT RBridge Protocol
Appendix A: Revision History
RFC Editor: Please delete this appendix before publication.
Changes from -03 to -04
1. Divide IANA Considerations section into IANA and IEEE parts. Add
IANA considerations for TRILL Header variations and reserved bit
and normative references to RFCs 2434 and 4020.
2. Add note on the terms Rbridge and TRILL to section 1.2.
3. Remove IS-IS marketing text.
4. Split Section 3 into Sections 3 and 4. Add a new top level
section "5. Pseudo Code", renumbering following sections. Move
pseudo code that was in old Section 3 into Section 4 and make
section 3 more textural. This idea is that Section 3 and 4 have
more readable text descriptions with some corner cases left out
for simplicity while section 5 has more structured and complete
coverage.
5. Revised and extended Security Considerations section.
6. Move multicast router attachment bit and IGMP membership report
information from the per VLAN IS-IS instance to the core IS-IS
instance so the information can be used by core RBridges to prune
distribution trees.
7. Remove ARP/ND optimization.
8. Change TRILL Header to add option feature. Add option section.
9. Change TRILL Header to expand Version field to the Variation
field. Add TRILL message variations (8 bits) supported to the per
RBridge link state information.
10. Distinguish TRILL data and IS-IS messages by using Variation = 0
and 1.
11. Consistently state that VLAN pruning and IP derived multicast
pruning of distribution trees are SHOULD.
12. Add text and pseudo code to discard TRILL Ethertype data frames
received on a port that does not have an IS-IS adjacency on it.
13. Add end station address learning section. Specify end station
address learning from decapsulated native frames.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 69]
INTERNET-DRAFT RBridge Protocol
14. Add nickname allocation priority and optional nickname
configuration. Reserve nickname values zero and 0xFFFF.
15. Explain about multiple Designated RBridges because of multiple
VLANS.
16. Add Incremental Deployment Considerations Section incorporating
expanded Wiring Closet Topology Section.
17. Add more detail on VLAN tag information and material on frame
priority.
18. Miscellaneous minor editing and terminology updates.
Changes from -04 to -05
NOTE: Section 5 was NOT updated as indicated below but the remainder
of the draft was so updated.
1. Mention optional VLAN and multicast optimization in Abstract.
2. Change to distinguish TRILL IS-IS from TRILL data frames based on
the Inner.MacDA instead of a TRILL Header bit.
3. Split IP multicast router attached bit in two so you can
separately indicate attachment of IPv4 and IPv6 routers. Provide
that these bits must be set if an RBridge does not actually do
multicast control snooping on ingressed traffic.
4. Add the term "port VLAN ID" (PVID).
5. Drop references to PIM. Improve discussions of IGMP, MLD, and MRD
messages.
6. Move M bit over one and create two bit pruning field at the
bottom of the "V" combined field.
7. Add pruning control values of V and discussion of same.
8. Permit optional unicast transmission of multi-destination frames
when there is only one received out a port.
9. Miscellaneous minor editing and terminology updates.
NOTE: Section 5 was NOT updated as indicated above but the remainder
of the draft was so updated.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 70]
INTERNET-DRAFT RBridge Protocol
Changes from -05 to -06
1. Revise Section 2 discussion of DRB determination in the presence
of VLANs and move it to Section 2.2. Adjust VLAN handling
description.
2. Change "V" field to be a 2-bit version fields followed by 2
reserved bits. Make corresponding changes to eliminate the
inclusion in the header of frame analysis indicating type of
multi-destination pruning which is proper for frame. Thus all
non-ingress RBridges that wish to perform such pruning are forced
to do full frame analysis. Make further corresponding changes in
IANA Considerations.
3. The Inner.MacDA for TRILL IS-IS frames is changed to a second
multicast address: All-IS-IS-RBridges. IEEE Allocation
Considerations, etc., are correspondingly changed.
4. Note in Section 6 that bridges can hide slow links and generally
make it harder from RBridges to determine the cost of an RBridge
to RBridge hop that is a bridged LAN.
5. Add material noting that replacement of bridges by RBridges can
cause connectivity between previously isolated islands of the
same VLAN.
6. Expand Security Considerations by mentioning RFC 3567 and
indicating that TRILL enveloping may reduce the effectively of
TRILL-ignorant firewall functionality.
7. Extensive updates to psuedo code.
8. Change to one DRB per physical link which dictates the inter-
RBridge VLAN for the link, appoints forwarders per VLAN, can be
configured to send Hellos on multiple VLANs, etc.
9. Add a minimal management by SNMP statement to Section 2.
10. Delete requirement to process TRILL frames arriving on a port
even if the port implements spanning tree and is in spanning tree
blocked state.
11. Drop recommendation to set "bridge" flags in some 802.1AB frame
fields.
12. Miscellaneous minor editing and terminology updates.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 71]
INTERNET-DRAFT RBridge Protocol
Disclaimer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Additional IPR Provisions
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 72]
INTERNET-DRAFT RBridge Protocol
Authors' Addresses
Radia Perlman
Sun Microsystems
Email: Radia.Perlman@sun.com
Donald E. Eastlake, 3rd
Motorola Laboratories
111 Locke Drive
Marlborough, MA 01752 USA
Phone: +1-508-786-7554
Email: Donald.Eastlake@motorola.com
Silvano Gai
Nuova Systems
Email: sgai@nuovasystems.com
Dinesh G. Dutt
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134-1706
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Expiration and File Name
This draft expires in May 2008.
Its file name is draft-ietf-trill-rbridge-06.txt.
R. Perlman, D. Eastlake, S. Gai, D. Dutt [Page 73]
| PAFTECH AB 2003-2026 | 2026-04-23 17:03:13 |