TRILL R.Perlman
Internet Draft Sun Microsystems
Intended status: Proposed Standard Silvano Gai
Nuova Systems
Dinesh G. Dutt
Cisco Systems
Expires: August 2007 March 2007
RBridges: Base Protocol Specification
draft-ietf-trill-rbridge-protocol-03.txt
Status of this Memo
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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire September 2007.
Abstract
RBridges allow for optimal pair-wise forwarding with zero
configuration, safe forwarding even during periods of temporary
loops, and the ability to cut down on ARP/ND and IP multicast
Perlman, Gai, Dutt Expires September 2007 [Page 1]
Internet-Draft RBridge Protocol March 2007
traffic. They achieve these goals by replacing the Spanning Tree
protocol with IS-IS.
The design also supports VLANs, and allows forwarding tables to be
based on RBridge destinations (rather than endnode destinations),
which allows internal forwarding tables to be substantially smaller
than in conventional bridge systems.
Acknowledgements
Many people have contributed to this design, including the working
group co-chairs Donald Eastlake 3rd and Erik Nordmark, and many other
members of the working group including, in alphabetic order, Alia
Atlas, Stewart Bryant, Dino Farinacci, Don Fedyk, Eric Gray, Sanjay
Sane, and Joe Touch. We invite you to join the mailing list at
http://www.postel.org/rbridge.
Table of Contents
1. Introduction...................................................3
1.1. Algorhyme V2..............................................4
1.2. Conventions used in this document ........................5
2. RBridges.......................................................5
2.1. RBridge Architecture......................................6
2.2. RBridges and VLAN.........................................8
2.3. Forwarding of Different Frame Types.......................9
2.3.1. Known-Unicast........................................9
2.3.2. Multi-destination....................................9
2.4. Advantages of RBridges...................................10
3. Detailed RBridge Design.......................................10
3.1. TRILL Header Format......................................10
3.1.1. Version (V).........................................11
3.1.2. Multi-destination (M)...............................11
3.1.3. Hop Limit...........................................11
3.1.4. RBridge addresses...................................12
3.1.4.1. Egress RBridge Address.........................12
3.1.4.2. Ingress RBridge Address........................12
3.2. Ethernet Encapsulation...................................12
3.2.1. Outer VLAN Tag......................................14
3.2.2. Inner VLAN Tag......................................14
3.2.3. FCS.................................................15
3.2.4. Point-to-point links................................15
3.3. Link State Protocol (IS-IS)..............................15
3.3.1. IS-IS RBridge Identity..............................16
3.3.2. Separate Instances..................................16
3.3.3. Multiple RBridge IS-IS Instances....................16
3.3.3.1. The IS-IS core instance........................16
Perlman, Gai, Dutt Expires September 2007 [Page 2]
Internet-Draft RBridge Protocol March 2007
3.3.3.2. The IS-IS VLAN instance........................17
3.3.4. Designated RBridge..................................18
3.4. Distribution Trees.......................................20
3.4.1. Distribution Tree Calculation.......................21
3.5. Pruning the Distribution Tree............................22
3.6. Forwarding using a Distribution Tree.....................22
3.7. Wiring Closet Topology...................................23
3.8. Learning Endnode Location................................24
3.9. Forwarding Behavior......................................25
3.9.1. Receipt of a Native Frame...........................25
3.9.1.1. Unicast case...................................25
3.9.1.2. Other multi-destination frames.................26
3.9.1.3. IS-IS frames...................................26
3.9.2. Receipt of an In-transit Frame......................27
3.9.2.1. Flooded Frame..................................27
3.9.2.2. Unicast Frame..................................28
3.9.2.3. IS-IS Frame....................................28
3.10. IGMP Learning...........................................28
3.11. RBridge Addresses.......................................29
3.12. Handling ARP/ND Queries.................................29
3.13. Discovering IP Multicast Routers........................31
3.14. Assuring Freshness of Endnode Information...............31
4. RBridge Addresses, Parameters, and Constants..................32
5. Security Considerations.......................................32
6. IANA Considerations...........................................33
7. References....................................................33
7.1. Normative References.....................................33
7.2. Informative References...................................34
Intellectual Property Statement..................................35
Disclaimer of Liability..........................................36
Copyright Statement..............................................36
Acknowledgment...................................................36
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 not fully
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.
Perlman, Gai, Dutt Expires September 2007 [Page 3]
Internet-Draft RBridge Protocol March 2007
Bridge forwarding via the spanning tree has some disadvantages:
o The spanning tree blocks ports limiting the number of forwarding
links and therefore creates bottleneck by concentrating traffic
onto selected links.
o The Ethernet header does not contain a 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 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),
which combines the advantages of bridges and routers [RBridges] and
which is poetically summarized below. While RBridge technology can
be applied to a variety of link protocols, this specification, where
relevant, concentrates on 802.3 links.
1.1. Algorhyme V2
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 limits we now see,
The network need not be loop-free!
RBridges work transparently.
Without a common spanning tree.
Ray Perlner
Perlman, Gai, Dutt Expires September 2007 [Page 4]
Internet-Draft RBridge Protocol March 2007
1.2 Conventions used in this document
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].
2. RBridges
The main idea is to have RBridges run a link state protocol amongst
themselves. This enables them to have enough information to compute
pairwise optimal paths for unicast, and to calculate distribution
trees for delivery of frames either to unknown destinations, or to
multicast/broadcast groups.
ECMP (Equal Cost MultiPath) may be supported, but it may introduce
frame reordering.
To mitigate the temporary loop issues, RBridges forward based on a
header with a hop limit (AKA TTL or hop count). Although the hop
limit discards looping frames, it is also desirable not to spawn
additional copies of frames by having RBridges specify the next
RBridge recipient, while forwarding across a shared-media link.
RBridges MUST learn the location of endnodes. They learn the location
and layer 2 addresses of attached nodes from the source address of
frames, as bridges do (for example, see section 8.7 of [802.1Q]).
RBridges also learn the IP addresses of directly attached
nodes and their association with MAC addresses from ARP/ND
requests/replies.
Once an RBridge learns the location of a directly attached endnode,
it advertises this information to the other RBridges in its link
state information.
Perlman, Gai, Dutt Expires September 2007 [Page 5]
Internet-Draft RBridge Protocol March 2007
2.1. RBridge Architecture
+----------------------------------------------------------+
| Higher Layer Entities |
+--+--------------+----------------------+--------------+--+
| \ Trill Layer | RBridge Relay Entity | Trill Layer / |
+----+------------+----------------------+------------+----+
| Data Link Layer | | Data Link Layer |
+-----------------+ +-----------------+
| Physical Layer | | Physical Layer |
+-------+---------+ +-------+---------+
| |
P1 P2
Figure 1 Architecture of an RBridge
Figure 1 shows an RBridge that contains:
o An Rbridge Relay Entity that interconnects two Rbridge ports;
o At least one port (two in the example);
o Higher Layer Entities, including at least the IS-IS protocol.
o The TRILL Layer. An RBridge encapsulates incoming IEEE 802.3
frames (in this document also referred to as Ethernet frames) with
a TRILL header to forward them to other Rbridges.
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, in accordance with the TRILL WG charter, the first edition
of this document specifies only an IEEE 802.3 encapsulation.
Figure 2 shows two RBridges R1 and R2 interconnected through an
Ethernet cloud. There are no restrictions on what may compose the
Ethernet cloud: point-to-point or shared media, hubs and bridges. The
Ethernet cloud may support VLAN tagging or not.
Perlman, Gai, Dutt Expires September 2007 [Page 6]
Internet-Draft RBridge Protocol March 2007
------------
/ \
+----+ / Ethernet \ +----+
| R1 |----< >---| R2 |
+----+ \ Cloud / +----+
\ /
------------
Figure 2 Interconnected RBridges
Figure 3 shows the format of a TRILL frame traveling through the
Ethernet cloud from R1 to R2.
+--------------------------------+
| Outer Ethernet Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
Figure 3 An Ethernet Encapsulated TRILL Frame
In the case of other media different from Ethernet, the outer
Ethernet header is replaced by the header specific to that media. For
example, figure 4 shows a TRILL encapsulation over PPP.
+--------------------------------+
| PPP Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
Figure 4 A PPP Encapsulated TRILL Frame
Perlman, Gai, Dutt Expires September 2007 [Page 7]
Internet-Draft RBridge Protocol March 2007
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
those of the original frame.
Frames are encapsulated with a TRILL header as they travel between
RBridges for several reasons:
1. to mitigates the loop issues with bridges a hop limit field is
included;
2. to prevent 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 endnodes.
When forwarding between RBridges across a shared-media, the data link
layer header contains the address of the next hop Rbridge, to avoid
frame duplication and, in the case of loops, to avoid spawning
additional copies of frames.
2.2. RBridges and VLAN
A VLAN is a way to partition endnodes 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. IEEE
802.1Q compliant bridges support VLANs and the same support is
present in RBridges.
IEEE 802.1Q bridges have the capability of supporting multiple VLANs
over a single link by inserting/removing a VLAN tag into the frame.
Some endnodes have the same capability.
The VLAN tag is structured according to IEEE 802.1Q. As shown in
figure 3, there are two places where such tags may be present in a
TRILL-encapsulated frame: one in the outer header (outer VLAN) and
one in the inner header (inner VLAN). Inners and Outer VLANs are
further discussed in section 3.2.
RBridges enforce that a frame originating in a particular inner VLAN
gets delivered only to other links in the same inner VLAN.
Perlman, Gai, Dutt Expires September 2007 [Page 8]
Internet-Draft RBridge Protocol March 2007
A side-effect of inner VLANs is that it makes RBridges more scalable,
since endnode membership in an inner VLAN is only of interest to
RBridges that have an attached port configured to be in that inner
VLAN.
2.3. Forwarding of Different Frame Types
There are several types of frames which RBridges forward slightly
differently. They are here classified into two main categories:
known-unicast and multi-destination.
2.3.1. Known-Unicast
These frames have an inner MAC Destination Address (Inner.MacDa) that
is unicast and the MAC address location is known to the ingress
RBridge (the RBridge that performs the TRILL encapsulation).
2.3.2. Multi-destination
These are frames that must be delivered to multiple destinations,
because either they have a group address or the location of the
destination is unknown.
They are:
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;
3. frames for layer 2 multicast addresses not derived from IP
multicast addresses: the Inner.MacDa is multicast;
4. frames for the layer 2 broadcast addresses: the Inner.MacDa is
broadcast;
5. ARP queries: the Inner.MacDa is broadcast;
6. ND queries: the Inner.MacDa is multicast;
Perlman, Gai, Dutt Expires September 2007 [Page 9]
Internet-Draft RBridge Protocol March 2007
7. IGMP membership reports: the Inner.MacDa is multicast.
RBridges build distribution trees (see Section 3.4. ) and use these
trees for forwarding multi-destination frames.
2.4. Advantages of RBridges
Like bridges, RBridges are zero configuration and transparent to IP
nodes. Like routers, RBridges forward on pair-wise shortest paths,
and do not create broadcast storms during temporary loops.
RBridges have the additional advantage that they may optimize IP
multicast traffic, and ARP (IPv4) [RFC826] and ND (IPv6) [RFC2461]
by avoiding the broadcast/multicast behavior of the queries.
RBridges are fully compatible with current 802.1D and 802.1Q bridges
as well as current IPv4 and IPv6 routers and endnodes. They are as
invisible to current IP routers as bridges are, and like routers,
they terminate the spanning tree protocol.
3. Detailed RBridge Design
3.1. TRILL Header Format
The TRILL header is shown in Figure 5 and it is independent of the
data link layer used.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Hop Limit |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress RBridge Address | Egress RBridge Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 TRILL Encapsulation
o V (Version): 2-bit. See Section 3.1.1.
o Hop Limit: 6-bit unsigned integer. See Section 3.1.3.
o M (Multi-destination): 1-bit. See Section 3.1.2.
o Reserved: 7-bit.
Perlman, Gai, Dutt Expires September 2007 [Page 10]
Internet-Draft RBridge Protocol March 2007
o Ingress RBridge Address: 16-bit address. See Section 3.1.4.2.
o Egress RBridge Address: 16-bit address. See Section 3.1.4.1.
3.1.1. Version (V)
According to IEEE's Ethertype format 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. In adhering to this guideline, a two bit
field called version is used to identify the format in use. It is
set to 0 by default. If it is set to 1, 2, 3 the header format is
undefined by this version of the standard.
3.1.2. Multi-destination (M)
The Multi-destination bit (see Section 2.3.2. ) specifies the content
of the egress RBridge address:
o M = 0 (FALSE) - the egress RBridge address contains the address of
the egress Rbridge;
o M = 1 (TRUE) - the egress RBridge address contains the address of
the RBridge that is the root of the distribution tree.
3.1.3. Hop Limit
A 6-bit unsigned integer. Each RBridge MUST check this field before
forwarding the frame to another RBridge. If this field is zero, the
frame MUST be discarded. If this field is non-zero, it MUST be
decremented by one in the forwarded frame.
This field was previously referred to as TTL (Time To Live) or hop
count. In IPv6 the IETF has replaced the concept of TTL with Hop
Limit. TRILL aligns with this newer definition.
Perlman, Gai, Dutt Expires September 2007 [Page 11]
Internet-Draft RBridge Protocol March 2007
3.1.4. RBridge addresses
16-bit address. This is the TRILL address of the RBridge. This
assignment allows addressing up to 64K RBridges. This was also
referred to in the past as "RBridge nickname" or "shim nickname".
The simplest encoding of an RBridge address would be a 48-bits MAC
address. However, to achieve a more compact encoding, RBridges
piggyback a address acquisition protocol on the link state protocol
(see Section 3.11. ), to acquire a unique 16-bit addresses (within
the campus).
3.1.4.1. Egress RBridge Address
This field contains two types of information, depending on M-bit (see
Section 3.1.2. ):
o For known-unicast frames, it contains the egress RBridge Address
i.e. the RBridge that needs to remove the TRILL header from the
frame.
o For multi-destination frames, it contains the address of the root
RBridge of the distribution tree to be used to forward the frame.
3.1.4.2. Ingress RBridge Address
The ingress RBridge address always contains the identifier of the
ingress RBridge, i.e. the RBridge that added the TRILL header to the
frame.
3.2. Ethernet Encapsulation
TRILL frames in transit on Ethernet links are encapsulated with an
additional outer Ethernet header (see figure 3). This outer header
looks, to an Ethernet 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 encapsulated frames, a new Ethertype = TRILL (to be
assigned) is used in the outer header.
Perlman, Gai, Dutt Expires September 2007 [Page 12]
Internet-Draft RBridge Protocol March 2007
Figure 6 details a frame traveling on the Ethernet cloud of Figure 2
from R1 to R2. This encapsulation has the advantage of aligning the
original Ethernet frame at 64 bit boundaries.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = IEEE 802.1Q | UP |C| Outer VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | Hop Limit |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Address | Ingress RBridge Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | InnerSource MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = IEEE 802.1Q | UP |C| Inner VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Original Ethernet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 TRILL Encapsulation over Ethernet
When a TRILL frame is carried over an Ethernet cloud it has three
sets of addresses:
o Outer MAC Addresses. These addresses are used to address the next
hop RBridge over a shared Ethernet Cloud.
o TRILL Addresses. These are the end-to-end addresses of the
RBridges doing the encapsulation/decapsulation (at least for the
known unicast case, see Section 3.1.4. ).
o Inner MAC Addresses. These are the addresses of the endnodes, as
originally inserted in the frames by the transmitting endnode.
Perlman, Gai, Dutt Expires September 2007 [Page 13]
Internet-Draft RBridge Protocol March 2007
It also potentially has two IEEE 802.1Q tags that carries two
different VLAN Identifier (VID).
3.2.1. Outer VLAN Tag
The Outer VLAN Tag: MAY or MAY NOT be present. If present, it is used
to enable connectivity between two RBridges through an Ethernet cloud
that support VLANs. Once two RBridges have established connectivity
on an outer VLAN, they become adjacent and they start to operate as
if connected by a direct link.
For example, a network manager may configure VLAN 4 for RBridges RB1
and RB2 to communicate (the outer VID contains the value 4). VLAN 3
may be assigned for RB2 and RB3 to communicate (the outer VID
contains the value 3). In this case RB2 becomes adjacent to both RB1
(on VLAN 4) and RB3 (on VLAN 3), but RB1 and RB3 are not adjacent
(since they have no common VLAN).
There is no additional discussion of this field in the rest of the
document.
3.2.2. Inner VLAN Tag
The Inner VLAN Tag: contains the VLAN information associated with the
original frame.
Each Ethernet port of an RBridge uses the "ingress rule" specified in
Section 6.7 of IEEE 802.1Q. This rule always associates a VID (VLAN
Identifier) with any frame, independently of whether the frame came
in tagged, untagged or priority tagged.
Since the most common default value for the parameter PVID (Port VLAN
Identifier) is 1, an Rbridge MAY suppress the inner VLAN tag for
frames with VID = 1.
The Inner VID is extremely important for TRILL (see section 2.2. ).
In the rest of this document, any reference to the term VLAN should
be interpreted as inner VLAN.
Perlman, Gai, Dutt Expires September 2007 [Page 14]
Internet-Draft RBridge Protocol March 2007
3.2.3. FCS
The frame has a single FCS that is computed to cover the entire
frame. This has become standard practice in IEEE 802.1: the tagging
structure effectively requires FCS recomputation at the boundaries of
the network. Additionally, the IETF (with diffserv, ECN, routing)
have also effectively required FCS recomputation at all boundaries of
the network.
3.2.4. Point-to-point links
If there is a direct RBridge-to-RBridge point-to-point link, there is
no real need for the outer header. Therefore if the link is a point-
to-point Ethernet link, it is acceptable to set the fields in the
outer header to predefined values on transmission and ignore them on
reception.
3.3. Link State Protocol (IS-IS)
In recent years, the IS-IS routing protocol [ISO10589] has become
increasingly popular, with widespread usage among Service Providers.
It is a link state protocol, which enables very fast convergence with
large scalability. It is also a very flexible protocol and has been
extended to incorporate leading edge features such as MPLS Traffic
Engineering.
TRILL uses IS-IS, since it also provides the following advantages:
o it runs directly over the layer 2;
o it is easy to extend by defining new TLVs for carrying the TRILL
information;
o it may be run with zero configuration.
IS-IS exchanges information by exchanging LSPs (Link State PDUs).
Perlman, Gai, Dutt Expires September 2007 [Page 15]
Internet-Draft RBridge Protocol March 2007
3.3.1. IS-IS RBridge Identity
Each RBridge has a unique 6-byte System ID, which may be derived from
any of the RBridge universal MAC addresses.
3.3.2. Separate Instances
RBridge implements a separate IS-IS instance from the one used by any
routing protocol, e.g. the ones used by IP routers. This instance is
identified by a combination of Outer.Mac.DA, Outer.Ethertpe and
Inner.Ethertype (see 3.9.1.3. ).
The RBridge IS-IS instance is also differentiated by defaulting to a
distinct, constant "area address" (the value 0) that would never
appear as a real IS-IS area address.
3.3.3. Multiple RBridge IS-IS Instances
Each RBridge runs multiple IS-IS instances:
o One IS-IS core instance;
o IS-IS VLAN instances, one per each inner VLAN the RBridge is
connected to.
In theory this information could all be contained in one instance of
RBridge IS-IS. However, since endnode information for a particular
VLAN needs to be known only to RBridges that are connected to links
configured to be in that VLAN, and since the core instance is global
to all RBridges, it is appropriate to have multiple instances.
3.3.3.1. The IS-IS core instance
The information contained in the LSP of RBridge Rn core is:
1. the TRILL address of RBridge Rn;
2. the list of VIDs of VLANs directly connected to Rn;
3. a flag RequestTree indicating whether RBridges MUST calculate a
tree rooted at Rn (default RequestTree = TRUE);
Perlman, Gai, Dutt Expires September 2007 [Page 16]
Internet-Draft RBridge Protocol March 2007
4. the System IDs of RBridges which are neighbors of RBridge Rn, and
the cost of the link to each of those neighbors.
Using the previous information each RBridge can compute the optimal
pair-wise forwarding for know-unicast traffic and the distribution
trees for multi-destination traffic.
The distribution trees (see Section 3.4. ) may also be pruned
according to the list of VIDs connected to each RBridge (see Section
3.5. ). In fact, if Rn is forwarding a multi-destination frame tagged
with VLAN A, Rn need not forward it onto branches of the distribution
tree that have no downstream VLAN A links.
3.3.3.2. The IS-IS VLAN instance
The endnode information for VLAN A, which is carried in the LSP
injected by Rn in VLAN A, contains:
1. L2INFO: layer 2 addresses of nodes on a VLAN A link attached to Rn
which have transmitted frames, but have not transmitted ARP/ND
requests/replies (i.e., these are not known to be IP nodes).
2. L3and2INFO: layer 3, layer 2 addresses of IP nodes attached Rn on
VLAN A, which Rn has learned through ARP/ND requests/replies. In
the case of IPv6, for data compression, only the portion of the
address following the campus-wide prefix is carried.
3. Multicast Router attached: This is one bit of information that
indicates whether there is an IP multicast router attached on VLAN
A. This information is used because IGMP [RFC3376] Membership
Reports MUST be transmitted to all links with IGMP routers, and
SHOULD NOT be transmitted to links without IGMP routers. Also, all
frames for IP-derived multicast addresses MUST be transmitted to
all links with IGMP routers (within the VLAN), in addition to
links from which an IP node has explicitly asked to join the group
which the frame is for.
4. Layer 2 addresses derived from IPv4 or IPv6 IGMP notification
messages received from attached endnodes on VLAN A, indicating the
location of listeners for these multicast addresses.
If Rn has learned endnode E's location first from a data frame (and
therefore has included E's layer 2 address in the L2INFO), and later
E transmits an ARP/ND request/reply, Rn MUST include E in the
L3andL2INFO, and SHOULD remove E from L2INFO.
Perlman, Gai, Dutt Expires September 2007 [Page 17]
Internet-Draft RBridge Protocol March 2007
The way that RBridges distinguish which IS-IS instance the VLAN link
state information is for is based on the VLAN tag in the inner header
i.e. the inner VLAN.
Given that RBridges already support distribution trees pruned by VID
(see Section 3.3.3.1. ), the same mechanism is used by the per-VLAN
instance of IS-IS to distribute endnode information solely to
RBridges within a VLAN.
Each per-VLAN instance of IS-IS appears to the RBridges as a single
link with all the RBridges with endnodes in that VLAN as neighbor.
When an RBridge originates an IS-S frame for the VLAN A instance, all
RBridges forward it as an ordinary frame in VLAN A, along the
specified distribution tree, even if they nave no endnodes connected
to VLAN A.
RBridges with endnodes in VLAN A also receive and process the frame
in their VLAN-A IS-IS instance.
3.3.4. Designated RBridge
IS-IS elects one RBridge on each link to be the Designated RBridge,
i.e. to have special duties. The Designated RBridge:
o learns and advertises the identities of attached endnodes;
o encapsulates and forwards frames that originate on that link to
the rest of the campus;
o decapsulates and forwards frames onto that link received from
other RBridges;
o initiates a distributed ARP/ND when an ARP/ND query is received
for an unknown destination;
o answers ARP/ND queries when the target node is known.
It is incorrect to have multiple RBridges being Designated RBridge on
the same link at the same time. This could temporarily happen if a
partitioned bridged LAN became connected with a bridge or repeater.
The situation resolves once the better priority RBridge's IS-IS Hello
is received by the other RBridges on the link.
Perlman, Gai, Dutt Expires September 2007 [Page 18]
Internet-Draft RBridge Protocol March 2007
BPDUs are messages that are transmitted and received even in
preforwarding state (listening and learning states). If RBridges
listen to BPDUs, and if the LANs for which R1 was Designated RBridge,
and for which R2 was Designated RBridge get joined, then either R1 or
R2 detect that the bridge Root has changed identity.
A conservative solution would be to invoke something like a
preforwarding state, in which the RBridge that detects the change
stops forwarding anything to or from the link until it is sure the
IS-IS link election would have completed. But the IS-IS election
could get slowed down due to bridges in preforwarding state, and it
would be undesirable to disrupt traffic to and from the link just
because the root ID has changed.
An alternative solution is to have RBridges participate in the
spanning tree election, with higher priority for becoming root
(actually, lowest numerical priority value) than any of the bridges,
and with the same priority as for becoming Designated RBridge on the
link. Then an RBridge is Designated RBridge if and only if it is the
spanning tree Root. Note that RBridges MUST NOT merge spanning trees
from different ports. If two ports of R1 are connected to the same
bridged LAN, then the regular bridge spanning tree algorithm
partitions the LAN into distinct LANs for each of R1's ports.
However, if two of R1's ports are connected to the same shared medium
(without any bridges between the ports), then the regular bridge
spanning tree algorithm turns off one of R1's redundant ports.
So for example, R1 sends BPDUs on each of its ports, with itself as
Root (with highest, i.e., numerically lowest priority), 0 cost from
Root, and the port ID. There are several possible cases:
o R1 is the highest priority RBridge on the bridged LAN, in which
case it becomes spanning tree Root and Designated RBridge.
o R1 receives a BPDU from itself (because two of its ports are on
the same shared medium without any bridges between). In this case,
the numerically lowest port remains in ST forwarding state, and
the other port(s) go into ST blocking state.
R1 receives a BPDU from someone else with higher priority
(numerically lower priority|ID), in which case R1 is not Root, and
not Designated RBridge. It is possible this is due to a bridge
being configured with the lowest priority, and then if R1 declines
being Designated RBridge, the LAN becomes orphaned from the campus.
We must treat this case as a misconfiguration of bridges, and the LAN
becomes orphaned until the misconfiguration is corrected, but an
RBridge could in theory eventually discover it is not receiving
Perlman, Gai, Dutt Expires September 2007 [Page 19]
Internet-Draft RBridge Protocol March 2007
any IS-IS Hellos, and become Designated RBridge even though it is not
spanning tree Root.
3.4. Distribution Trees
RBridges use distribution trees to forward multi-destination frames
(see Section 2.3.2. ). Distribution Trees are bidirectional. A single
distribution tree is 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
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
expense of computation 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, in order to allow
multipathing of multicast traffic injected by a particular Bridge.
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
distribution tree. Each RBridge Ri announces whether RBridges MUST
compute a tree rooted at Ri via the RequestTree flag in its IS-IS
core 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 ID.
Perlman, Gai, Dutt Expires September 2007 [Page 20]
Internet-Draft RBridge Protocol March 2007
If Ri is a tree root, then any RBridge Rn that needs to send multi-
destination traffic MAY select the Ri-tree. Rn does so by specifying
in the TRILL header:
Trill.EgressRbridgeAddress = Ri;
Trill.M = TRUE;
All the other RBridges MUST comply with the decision of Rn.
In IS-IS a shared link is modeled as a pseudonode. Pseudonodes MUST
set RequestTree = FALSE.
3.4.1. Distribution Tree Calculation
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 Ri is done independently by each
RBridge Rn by performing the SPF (Shortest Path First) calculation
with Ri as the root without requiring any additional exchange of
information.
In the case a node Rn has two or more minimal equal cost path toward
the root Ri 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 Rn keeps a set of adjacencies (port, neighbor pair) for
each distribution tree. One of these adjacencies is toward the root
Ri and the others are toward the leaves. Once the adjacencies are
chosen, it is irrelevant which ones are towards the root Ri, and
which are away from Ri. Let's suppose that Rn has calculated that
adjacencies a, c, and f are in the Ri tree. A multi-destination frame
for the distribution tree Ri is received only from one of the
adjacencies a, c, or f (otherwise is discarded) and forwarded to the
other two adjacencies.
Perlman, Gai, Dutt Expires September 2007 [Page 21]
Internet-Draft RBridge Protocol March 2007
3.5. Pruning the Distribution Tree
Each distribution tree is pruned per VLAN eliminating branches that
have no potential receivers downstream. Multi-destination frames are
forwarded only on branches that are not pruned.
Further pruning is done in the case of IGMP Notification Messages
[RFC3376], where these are to be delivered only to ports with IP
Multicast Routers. In the case of a multicast derived from an IP
multicast, these multicast data frames are delivered only to links
that have registered listeners, plus links which have IP Multicast
routers.
Let's assume that RBridge Rn knows that adjacencies (a, c, and f) are
in the Ri-distribution tree. Rn marks pruning information for each of
the adjacencies in the Ri-tree. For each adjacency and for each tree,
Rn marks:
o the set of VLANs reachable downstream, and for each one of those,
a flag indicating whether there are IP multicast routers
downstream, and
o the set of layer 2 multicast addresses derived from IP
multicast group for which there are receivers downstream.
3.6. Forwarding using a Distribution Tree
Forwarding a multi-destination frame is done as follows:
o The RBridge Rn receives a multi-destination frame on VLAN A and
the TRILL header indicates the selected tree is the Ri-tree;
o if the adjacency from which the frame was received is not one
of the adjacencies in the Ri-tree, the frame is dropped;
o else if the frame is an IGMP Notification message then the frame
is forwarded onto adjacencies in the Ri-tree that indicate there
are downstream VLAN-A IP multicast routers;
o else if the frame is for a layer 2 multicast address derived from
IP multicast groups then the frame is forward onto adjacencies in
the Ri-tree that indicate there are downstream VLAN-A IP multicast
routers, as well as adjacencies that indicate there are downstream
VLAN-A receives for that group address;
Perlman, Gai, Dutt Expires September 2007 [Page 22]
Internet-Draft RBridge Protocol March 2007
o else if the inner frame is for an unknown destination or layer 2
multicast not derived from IP multicast, or distributed ARP/ND, or
broadcast, the frame is forwarded onto an adjacency if and only if
that adjacency is in the Ri-tree, and marked as reaching VLAN-A
links.
For each link for which Rn is Designated RBridge, Rn additionally
checks to see if it should decapsulate the frame and send it to the
link (e.g., if it is a distributed ARP/ND in the specified VLAN for
that link), or process the frame (e.g., if it is a per-VLAN IS-IS
instance link state announcement for a VLAN that Rn is attached to).
3.7. Wiring Closet Topology
In cases where there are two (or more) groups of endnodes, each
attached to a bridge (say B1 and B2 respectively), and each bridge is
attached to an RBridge (say R1 and R2 respectively), with a link
connecting B1 and B2 (see Figure 7), it may be desirable to have the
B1-B2 link only as a backup in case one of R1 and R2, or the links
B1-R1 or B2-R2 fail.
+----+ +----+
| R1 |-----| R2 |
+----+ +----+
| |
+-------------------------------+
| | | |
| +----+ +----+ |
| Closet | B1 |-----| B2 | |
| +----+ +----+ |
| |
+-------------------------------+
Figure 7 Wiring Closet Topology
For example, B1 and B2 may be in a wiring closet and it may be easy
to provide a very short very high bandwidth link between them while
R1 and R2 are at a distant data center such that the R1-B1 and R2-B2
links are slower and more expensive.
Default behavior would be that one of R1 or R2 (say R1) would become
Designated RBridge, and forward traffic to/from the link, so endnodes
attached to B2 would be connected to the campus via the path B2-B1-
Perlman, Gai, Dutt Expires September 2007 [Page 23]
Internet-Draft RBridge Protocol March 2007
R1, rather than the desired B2-R2. The desired behavior would
probably be to make maximum use of both the R1-B1 and R2-B2 links.
The solution is to configure R1 and R2 to be part of a "wiring closet
group", with a configured System ID Rx (which may be R1 or R2's
System ID). Both R1 and R2 participate in the bridge spanning tree on
the configured ports as root Rx, which causes the spanning tree to
break the B1-B2 link as desired, and both R1 and R2 act as Designated
RBridge on each of their respective partitions.
In the BPDU, the Root is "Rx", cost to Root is 0, Designated Bridge
ID is "R1" when R1 transmits and "R2 when R2 transmits, and port ID
is a value chosen independently by each of R1 and R2 to distinguish
each of its own ports. If R1 and R2 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.
The only misconfiguration that may occur is if the link R1-R2 is on
the cut set of the campus, and R2 and/or R1 have been configured to
believe they are part of a wiring closet group. In that case, the
link becomes partitioned.
3.8. Learning Endnode Location
RBridges learn endnode location from native frames (similar to 802.1D
bridges, see in section 7.0 of [802.1Q]). They learn (layer 3, layer
2) pairs, for the purpose of supporting ARP/ND optimization, from
listening to ARP/ND request/replies.
This endnode information is learned by the Designated RBridge, and
distributed to other RBridges through the link state protocol.
RBridges need not remember endnode information for a VLAN unless
there are endnodes for that VLAN on one of their directly connected
links.
Perlman, Gai, Dutt Expires September 2007 [Page 24]
Internet-Draft RBridge Protocol March 2007
3.9. Forwarding Behavior
3.9.1. Receipt of a Native Frame
3.9.1.1. Unicast case
Let's assume that Rn receives a unicast frame with Mac.Da = D, Mac.Sa
= S and Ethertype != TRILL. Rn knows this is a native frame from the
Ethertype value.
Rn determines the VID according to the same rules as bridges do. Once
the VLAN is established, the layer 2 address of D is looked up in the
destination table for that VLAN to find the egress RBridge Rm, or
discover that D is unknown.
If D is known, with egress Rm, then Rn encapsulates the frame, in the
following way:
Outer.MacDa = next hop RBridge (in the path to Rm);
Outer.MacSa = Rn;
Outer.Ethertype = TRILL;
Trill.v = 0;
Trill.Reserved = 0;
Trill.M = FALSE; // this is not a multi-destination frame
Trill.HopLimit = default or configured hop limit;
Trill.EgressRBridgesAddress = Rm;
Trill.IngressRBridgesAddress = Rn;
Followed by the received frame;
If D is unknown, Rn encapsulates the frame, in the following way:
Outer.MacDa = ALL-RBRIDGES;
Outer.MacSa = Rn;
Outer.Ethertype = TRILL;
Trill.v = 0;
Trill.Reserved = 0;
Trill.M = TRUE; // this is a multi-destination frame
Trill.HopLimit = default or configured hop limit;
Trill.EgressRBridgesAddress = Ri // Distribution Tree, see below
Trill.IngressRBridgesAddress = Rn;
Followed by the received frame;
In the latter case, the egress RBridge address indicates the chosen
distribution tree Ri. The default is for Rn to put its own address
there. However, if Rn is configured to decline to be a tree root,
Perlman, Gai, Dutt Expires September 2007 [Page 25]
Internet-Draft RBridge Protocol March 2007
then Rn MUST select some other RBridge Ri which has elected to be a
tree root or the RBridge with the lowest ID if none have elected to
be a tree root.
3.9.1.2. Other multi-destination frames
If the frame is an IGMP announcement, then Rn learns the group
membership, and announces a receiver for that layer 2 group address
in its per-VLAN link state instance.
If the frame is a PIM or MRD [RFC4286] message, Rn learns that there
is an IP multicast router (for the specified VLAN) on its link, and
adds that information into its per-VLAN IS-IS link state information.
If the frame is an ARP/ND reply, then Rn learns the (layer 3, layer
2) correspondence, and adds that information into its per-VLAN link
state information.
3.9.1.3. IS-IS frames
If the frame is from the IS-IS core instance of Rn, then there is no
need for the TRILL Ethertype and inner headers. The outer header
contains:
Outer.MacDa = ALL-RBRIDGES;
Outer.MacSa = Rn;
Outer.Ethertype = IS-IS;
In this case the IS-IS frame is never forwarded by the RBridge as a
layer 2 frame, but instead is delivered to the RBridge IS-IS process
for processing.
The situation is different in the per-VLAN instances of IS-IS, since
there is the need to carry the VID. The encapsulation is as follow:
Outer.MacDa = ALL-RBRIDGES;
Outer.MacSa = Rn;
Outer.Ethertype = TRILL;
Trill.v = 0;
Trill.Reserved = 0;
Trill.M = TRUE; // this is a multi-destination frame
Trill.HopLimit = MAX-HOP-LIMIT;
Trill.EgressRBridgesAddress = Ri; // Distribution Tree, see above
Trill.IngressRBridgesAddress = Rn;
Perlman, Gai, Dutt Expires September 2007 [Page 26]
Internet-Draft RBridge Protocol March 2007
Followed by a VLAN-tagged IS-IS packet (same as for core instance,
but with VLAN tag). In this case the frames are forwarded like a non-
IP-multicast flooded frame, as well as processed, if the RBridge
belongs to the specified VLAN.
3.9.2. Receipt of an In-transit Frame
Let's suppose RBridge Rn receives a TRILL encapsulated frame (as
indicated by Outer.Ethertype = TRILL).
3.9.2.1. Flooded Frame
if (Outer.MacDa == ALL-RBRIDGES)
{
if (Outer.MacSa != a tree adjacency for the tree indicated)
{
Discard the frame
}
else
{
Rn forwards along the tree indicated by
Trill.EgressRBridgesAddress,
pruned as specified in section 3.5.
It also removes the TRILL encapsulation
and forwards the frame to the appropriate ports
where it is a Designated RBridge.
}
}
Perlman, Gai, Dutt Expires September 2007 [Page 27]
Internet-Draft RBridge Protocol March 2007
3.9.2.2. Unicast Frame
if (Outer.MacDa != Rn)
{
R1 Drops the frame // the destination in the outer header
// is not R1
}
else
{
if (Trill.EgressRBridgesAddress == Rn)
{
Rn process the frame, i.e. it removes the TRILL encapsulation,
extracts the inner frame and forwards it onto the link
containing the destination, or processes the frame if the
Inner.MacDa == Rn.
}
else
{
// The frame needs to be forwarded to another RBridge
//
Outer.MacDa = lookup (Trill.EgressRBridgesAddress);
Outer.MACSa = Rn;
Trill.HopLimit -= 1;
forward_frame();
}
}
3.9.2.3. IS-IS Frame
If the protocol type in the outer header indicates this is an IS-IS
frame, then Rn processes the frame accordingly.
3.10. IGMP Learning
RBridges learn, based on seeing IGMP [RFC3376] frames, which
multicast addresses should be forwarded onto which links.
IGMP messages have to be forwarded throughout the campus, since IP
routers in the broadcast domain also need to see these messages.
IGMP messages are forwarded by RBridges throughout the campus like
any layer 2 multicast. They are recognized by having an IP message
type=2 in the IP header. In addition, they are processed by RBridges
Perlman, Gai, Dutt Expires September 2007 [Page 28]
Internet-Draft RBridge Protocol March 2007
in order to extract, from announcements, what egress RBridges have
receivers for which groups.
3.11. RBridge Addresses
To make the TRILL header smaller, RBridges dynamically acquire 2-byte
addresses that are unique within the campus. The address allocation
protocol is piggybacked on the core IS-IS RBridge instance as
follows:
o The address requested by the RBridge is carried in a new TLV. Each
RBridge chooses its own address.
o Each RBridge is also responsible for ensuring that its address is
unique. If R1 chooses address x, and R1 discovers, through
receipt of R2's LSP, that R2 has also chosen x, then the RBridge
with the lower System ID keeps the address, and the other RBridge
MUST choose a new address.
o If two RBridge domains merge then transient address collisions
are possible. As soon as each RBridge receives the link
state frames from the other RBridges, the RBridges that need to
change addresses choose new addresses that do not, to the best of
their knowledge, collide with any existing addresses.
To minimize the probability of address collisions, each RBridge
chooses its address randomly hashing some of its parameters. There is
no reason for all RBridges to use the same algorithm for choosing
addresses.
Once an RBridge has successfully acquired an address it SHOULD store
it in non-volatile memory and reuse it in the case of a reboot.
To minimize the probability of a new RBridge usurping a address
already in use, an RBridge SHOULD wait to acquire the link state
database from a neighbor before it announces its own address.
3.12. Handling ARP/ND Queries
IEEE 802.1 bridges forward an ARP/ND query as an ordinary
broadcast/multicast frame to all links belonging to the same VLAN.
Rbridges SHOULD implement an "optimized ARP/ND response"
Perlman, Gai, Dutt Expires September 2007 [Page 29]
Internet-Draft RBridge Protocol March 2007
When the target's location is assumed to be known by the first
RBridge, it needs not flood the query. Alternative behaviors of the
first Designated RBridge that receives the ARP/ND query would be to:
1. send a response directly to the querier, with the layer 2 address
of the target, as believed by the RBridge
2. encapsulate the ARP/ND query to the target's Designated RBridge,
and have the Designated RBridge at the target forward the query to
the target. This behavior has the advantage that a response to the
query is authoritative. If the query does not reach the target,
then the querier does not get a response
3. block ARP/ND queries that occur for some time after a query to the
same target has been launched, and then respond to the querier
when the response to the recently-launched query to that target is
received
The reason not to do the most optimized behavior all the time is for
timeliness of detecting a stale cache. Also, in the case of scure
neighbor discovery (SEND) [RFC3971], cryptography might prevent
behavior 1, since the RBridge would not be able to sign the response
with the target's private key.
It is not essential that all RBridges use the same strategy for which
option to select for a particular query. However, once the first
Designated RBridge decides on a strategy for a particular query, the
other RBridges MUST carry that through. If the first RBridge responds
directly to the querier, or blocks the query, then no other RBridges
are involved.
If the first Designated RBridge R1 decides to unicast the query to
the target's Designated RBridge R2, then R2 decapsulates the query,
and initiate an ARP/ND query on the target's link. When/if the
target responds, R2 encapsulates and unicast the response to R1,
which decapsulates the response and send it to the querier.
If the first Designated RBridge R1 decides to flood the query (which
it MUST do if the target is unknown, but MAY do if it wants to assure
freshness of the information), the query is encapsulated to be
flooded through the indicated VLAN.
The distributed ARP/ND query is carried by RBridges through the
RBridge distribution tree. Each Designated RBridge, in addition to
forwarding the query through the distribution tree, initiates an
ARP/ND query on its link(s). If a reply is received from the target
by Designated RBridge R2, R2 initiates a link state update to inform
Perlman, Gai, Dutt Expires September 2007 [Page 30]
Internet-Draft RBridge Protocol March 2007
all the other RBridges of D's location, layer 3 address, and layer 2
address, in addition to forwarding the reply to the querier.
It is the querier's Designated RBridge R1 that chooses which strategy
to employ when seeing an ARP/ND query.
Some mix of these strategies (responding directly, unicasting the
query to the target's Designated RBridge, or flooding the query)
might be the best solution. For instance, even if the target's
location and (layer 3, layer 2) correspondence is in the link state
information R1 received from R2, if the target's location has not
been recently verified by R1 through a broadcast ARP/ND or unicast
query to the target, then R1 MAY broadcast or unicast the query or
respond directly. So for instance, RBridges could keep track of the
last time a broadcast ARP/ND occurred for each endnode E (by any
source, and injected by any RBridge). Let's say the parameter is 20
seconds. If a source S on RBridge R1's link does an ARP/ND for D, if
R1 has not seen an ARP/ND for D within the last 20 seconds, R1
unicasts the query to force a reply from the target; otherwise it
proxies the reply.
When R2 forwards a unicast ARP/ND query, if the target does not
respond, then R2 MAY replay the query, and if the target still does
not respond, R2 SHOULD remove the target from its link state
information.
3.13. Discovering IP Multicast Routers
Until Multicast Router Discovery [RFC4286] is universally deployed,
RBridges discover IP multicast routers through their transmission of
PIM messages. So an RBridge concludes there is an IP multicast router
on its port if it either receives an MRD message or a PIM message on
that port. A PIM message is recognized because the protocol type in
the IP header is decimal 103.
3.14. Assuring Freshness of Endnode Information
A Designate RBridge MUST be capable of ensuring freshness of its
endnode information using periodic ARP/ND queries. Because this may
be a problem if the endnodes are in power-saver mode, there MUST be a
configuration option to disable or control the frequency of these
queries. These queries SHOULD be enabled by default.
Perlman, Gai, Dutt Expires September 2007 [Page 31]
Internet-Draft RBridge Protocol March 2007
4. RBridge Addresses, Parameters, and Constants
Each RBridge needs a unique System ID. The simplest such address is
a unique 6-byte ID, since such an ID is easily obtainable as any of
the EUI-48's owned by that RBridge. IS-IS already requires each
router to have such an address.
The parameter DEFAULT-HOP-LIMIT (suggested value 20). It is the value
used to initialize Trill.HopLimit when an RBridge encapsulates a
frame if some other value has not been configured.
A new Ethertype must be assigned to indicate a TRILL encapsulated
frame.
A layer 2 multicast address for ALL-RBRIDGES must be assigned for
use as the destination address in flooded frames.
To support VLANs, RBridges (like bridges today), must be configured,
for each port, with the PVID (Port VLAN ID) in which that port
belongs.
A parameter to determine whether an RBridge should periodically do
queries to ensure that the endnode information is fresh, and if so,
with what frequency.
The parameter RequestTree that indicates whether an RBridge wants to
be the root of a distribution tree.
Configuration for wiring closet topology consists of System ID of the
RBridge with lowest System ID. If R1 and R2 are part of a wiring
closet topology, only R2 needs to be configured to know about this,
and that R1 is the ID it should use in the spanning tree protocol on
the specified port.
5. Security Considerations
The goal is for RBridges to not add additional security issues over
what would be present with traditional bridges. 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.
As with routing schemes, authentication of RBridge messages would be
a simple addition to the design (and it would be accomplished the
same way as it would be in IS-IS). However, any sort of
Perlman, Gai, Dutt Expires September 2007 [Page 32]
Internet-Draft RBridge Protocol March 2007
authentication requires additional configuration, which might
interfere with the perception that RBridges, like bridges, are zero
configuration.
6. IANA Considerations
A new Ethertype must be assigned to indicate an TRILL encapsulated
frame.
A layer 2 multicast address for "All RBridges" must be assigned for
use as the destination address in flooded frames.
7. References
7.1. 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.
[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.
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC
826, November 1982.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461 (Standards Track),
December 1998.
[RFC3376] Cain, B., "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[RFC4286] Haberman, B., Martin, J., "Multicast Router Discovery", RFC
4286, December 2005.
Perlman, Gai, Dutt Expires September 2007 [Page 33]
Internet-Draft RBridge Protocol March 2007
[SNOOP] Christensen, M., Kimball, K, Solensky, F., "Considerations
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12.txt
7.2. Informative References
[Arch] Gray, E., "The Architecture of an RBridge Solution to TRILL",
draft-ietf-trill-rbridge-arch-01.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, Octover 2006, work in progress.
[RBridges] Perlman, R., "RBridges: Transparent Routing", Proc.
Infocom 2005, March 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches,
and Internetworking Protocols", Addison Wesley Chapter 3, 1999.
Perlman, Gai, Dutt Expires September 2007 [Page 34]
Internet-Draft RBridge Protocol March 2007
Author's Address
Radia Perlman
Sun Microsystems
Email: Radia.Perlman@sun.com
Silvano Gai
Nuova Systems
Email: sgai@nuovasystems.com
Dinesh G. Dutt
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: 1-408-527-0955
EMail: ddutt@cisco.com
Intellectual Property Statement
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.
Perlman, Gai, Dutt Expires September 2007 [Page 35]
Internet-Draft RBridge Protocol March 2007
Disclaimer of Liability
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.
Copyright Statement
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Perlman, Gai, Dutt Expires September 2007 [Page 36]
