Internet DRAFT - draft-eastlake-rbridge-compatibility
draft-eastlake-rbridge-compatibility
Network Working Group Donald Eastlake
INTERNET-DRAFT Susan Hares
Intended status: Informational Huawei
Jon Hudson
Brocade
Expires: February 27, 2012 August 28, 2011
RBridge and Switching Device Layering and Compatibility
<draft-eastlake-rbridge-compatibility-02.txt>
Abstract
This document describes a layering and peering model for network
switches and end stations. It also discusses, using this model, the
compatibility of RBridges (Routing Bridges) with Layer 3 routers and
various types of bridges including Shortest Path Bridges. RBridges
are devices that implement the IETF TRILL (TRansparent
Interconnection of Lots of Links) standard.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
D. Eastlake, S. Hares, J. Hudson [Page 1]
INTERNET-DRAFT RBridge Compatibility
Table of Contents
1. Introduction............................................3
1.1 Simplifying Assumptions................................3
1.2 Terminology............................................3
2. Layers and Peering......................................4
2.1 Basic Layers...........................................4
2.2 Basic Peering..........................................5
2.2.1 Bridges..............................................6
2.2.2 Layer 3 Routers......................................6
2.2.3 User End Stations....................................6
2.3 More Layers............................................7
2.3.1 RBridges (Routing Bridges)...........................8
2.3.2 Customer Bridges and VLANs...........................9
2.3.3 Provider Bridges and VLANs..........................11
3. A Prevalent Confusion..................................13
4. Shortest Path Bridges..................................16
5. Conclusions............................................18
6. IANA Considerations....................................19
7. Security Considerations................................19
8. Informative References.................................20
9. Normative References...................................21
D. Eastlake, S. Hares, J. Hudson [Page 2]
INTERNET-DRAFT RBridge Compatibility
1. Introduction
RBridges (Routing Bridges) provide transparent least-cost forwarding
in networks with arbitrary topology using the IETF TRILL (TRansparent
Interconnection of Lots of Links) standard [RFC6325] that builds on
IS-IS (Intermediate System to Intermediate System) routing [IS-IS]
[RFC1195] [RFC6326].
This document describes a model of the layered relationship between
types of switching devices and how this correlates with peering for
some protocols. It also discusses the compatibility of RBridges with
end stations, Layer 3 routers, Layer 2 Customer Bridges, general
Layer 2 Provider Bridges, and Shortest Path Bridges.
1.1 Simplifying Assumptions
There tend to be many twists and turns in the real world so, to keep
this document to a reasonable size, the following assumptions are
made:
1. All physical links between devices are point-to-point Ethernet
connections [802] [802.3].
2. Although there are a variety of Layer 3 routers, we will assume
pure IPv4/IPv6 [IS-IS] [RFC1195] routers.
3. It is assumed that the reader has some general understanding of
what Layer 3 routing and Layer 2 bridging [ITU-X.200] are, how
Ethernet works, and is familiar with [RFC6325].
1.2 Terminology
The terminology and acronyms of [RFC6325] are used in this document
supplemented by the following definitions:
Bridge - as used in this document, a device that transparently
forwards frames using some version of the Spanning Tree
Protocol.
RBridge - Routing Bridge - a device generally conformant to the TRILL
base protocol standard [RFC6325] that transparently routes
frames.
SPB - Shortest Path Bridge - a device that is not only a Bridge as
defined above but that can also forward frames using bridging
mechanisms that are configured using the IS-IS protocol.
D. Eastlake, S. Hares, J. Hudson [Page 3]
INTERNET-DRAFT RBridge Compatibility
2. Layers and Peering
This section discusses a model of the layered relationship between
switching devices and how it affects peering for some protocols.
2.1 Basic Layers
Relative layering is essential to a clear understanding of the model
used by this document. While "Layer 2" and "Layer 3," in
approximately the OSI (Open System Interconnect) sense [ITU-X.200],
are commonly used terms, finer gradations are needed. For the most
part, only relative layer between two technologies matters, i.e.,
which is at a "higher" or "lower" layer, not whether they are
precisely Layer 2 or Layer 3 or Layer 2.718281828459045 or Layer (2 +
7i).
To a general approximation, a device at Layer X sees all lower layer
devices, that is devices at Layer Y where X > Y, as transparent. In
other words, with the possible exception of some minor implementation
details, "layer violating" optimizations, or odd corner cases, two
devices at layer X don't particularly care if there are devices at
layer Y (or lower) between them.
On the other hand, to devices at Layer Y, all higher layer devices,
that is devices at Layer X where X > Y, act as boundaries. That is,
Layer X (or higher) devices bound a cloud of such Layer Y devices.
In the past, when things were simpler, one could generally understand
networks by distinguishing three layers as shown below:
+------------------+
| User End Station |
+---+-------+------+
| |
| +----+------+
| | L3 Router |
| +-----+-----+
| |
+--+--------+--+
| Bridge |
+--------------+
Figure 1. Simple Layers
The above diagram is meant to indicate that user end stations are at
the highest relative layer, Layer 3 routers are at an intermediate
layer, and bridges are at the lowest layer. The vertical lines mean
that you can have bridges and routers between and directly connected
D. Eastlake, S. Hares, J. Hudson [Page 4]
INTERNET-DRAFT RBridge Compatibility
to user end stations and bridges between and directly connected to
routers.
The two types of devices above bridges act as boundaries for a
bridging area. That is, user end stations and Layer 3 routers bound a
bridged LAN (Local Area Network). To Layer 3 routers, bridges are
approximately transparent but user end stations bound a routed area.
And, finally, both bridges and Layer 3 routers are pretty much
transparent to communications between user end stations.
2.2 Basic Peering
In the cases we are discussing, if two devices are at the same layer,
there is a significant protocol related to the device type in which
(1) they peer with each other, (2) devices at lower layers are
generally transparent to and do not interfere with such peering, and
(3) devices at a higher layer block the protocol and do not permit
peering through such higher layer devices.
For example, consider the diagram below
+----------+ +----------+
| User End | peer | User End |
| Station |..................................| Station |
+--+----+--+ +--+---+---+
/ \ | |
| | / \
+------+-+not +-+------+ peer +---------+ | |
| Router |peer| Router |.............| Router | | |
+--+-----+ +----+---+ +--+---+--+ / \
| | / \ | |
| | / \ | |
+----+---+ +--+-----+peer+------+-+ +-+---+--+ +--+-----+
| Bridge | not | Bridge |....| Bridge | not | Bridge | not | Bridge |
| | peer | +----+ | peer| | peer| |
+--------+ +--------+ +--------+ +--------+ +--------+
Figure 2. Simple Layered Peering
As shown in this diagram, for the model in this document, devices at
the same level peer if and only if there are no higher layer devices
intervening.
How does this simple peering and layering work? It is generally
implemented, as described below, by the discarding or propagation of
frames based on their destination MAC address or their protocol type
(typically represented by an Ethertype). (There are additional
details not covered here for the sake of brevity such as registration
D. Eastlake, S. Hares, J. Hudson [Page 5]
INTERNET-DRAFT RBridge Compatibility
protocols, OAM, link level protocols, and IEEE 802.1 Two-Port MAC
Relays.)
2.2.1 Bridges
At the bridging and link layers there are reserved MAC multicast
addresses that are used, particularly the block from
01-80-C2-00-00-00 to 01-80-C2-00-00-0F [802.1Q]. From the beginning,
the specifications for bridges included a requirement to discard any
frame sent to an address in this block if the bridge did not
understand a protocol that used that address.
2.2.2 Layer 3 Routers
Layer 3 routers normally only recognize or forward frames in the
specific Layer 3 protocol(s) they are routing and those related to
the routing protocol itself. For example, an IPv4/IPv6 router will
recognize or forward only IPv4/IPv6 packets (including IPv4/IPv6
multicast if it handles such traffic) and Layer 3 routing control
frames such as those for Layer 3 IS-IS.
(IPv4/IPv6 multicast uses MAC multicast addresses 01-00-5E-00-00-00
to 01-00-5E-7F-FF-FF (IPv4) and 33-33-00-00-00-00 to 33-33-FF-FF-FF-
FF (IPv6) [RFC5342] and Layer 3 IS-IS routing uses MAC multicast
addresses 01-80-C2-00-00-14 and 01-80-C2-00-00-15 [IS-IS].)
Layer 3 routers normally do not route frames sent to any of the
bridging and link layer multicast addresses thus blocking bridge
peering and properly limiting the scope of link protocols. But
bridges forward IS-IS routing frames, IPv4 and IPv6 multicast frames
and, of course, unicast frames addressed to a router or end station.
Thus, of the devices we are discussing in this section, bridges can
transparently connect Layer 3 routers but Layer 3 routers block
bridging protocols and bound bridged LANs.
2.2.3 User End Stations
A pure user end station does not normally forward any frames
received. Thus it clearly meets the layering criterion of blocking
the peering of devices at all lower layers. Devices cannot peer if
they cannot exchange frames. (Of course, it is possible to have what
is thought of as a user end station also act like a bridge or router
or whatever, but then it isn't a pure user end station any more, is
it?) An example of a protocol by which end stations peer is TCP/IP.
D. Eastlake, S. Hares, J. Hudson [Page 6]
INTERNET-DRAFT RBridge Compatibility
But wait, you say, it is common for an end station to speak TCP/IP
with a bridge or a router, for SNMP or SSH or the like. Actually, the
best way to look at such interactions, and the way they are commonly
implemented, is that the TCP/IP interactions with a bridge or router
are with a virtual end station inside that bridge or router. To have
included this in Figure 2, we could draw an end station box at the
top for each bridge or router box and draw a link from the end
station down to the corresponding bridge or router. Thus the model of
end stations peering with each other using TCP/IP is pretty much
correct.
2.3 More Layers
The world is now more complex than that described above. There can be
quite a number of layers but, for the purposes of this document, the
five layers shown in the diagram below are adequate.
+--------------------------------+
| User End Station |
+-+---+----+-------------------+-+
| | | |
| | +--+---------------+ |
| | | L3 Router | |
| | +----+--------+--+-+ /
| | | | | /
| +-+------+------+ | \ /
| | RBridge | | X
| +--+-------+----+ | / \
| | | | | \
| | +-----+------+--+-+ \
| | | Customer Bridge | |
| | +-------+---------+ |
| | | |
+-+----+---------+-------------+-+
| Provider Bridge |
+--------------------------------+
Figure 3. More Layers
As in Figure 1, the position of a box in this diagram corresponds to
the relative layer of the device type. And the more or less vertical
connections, which exist between every pair of types indicate that it
is workable to have devices of any type shown between and directly
connected to instances of any higher layer device shown.
The additions are a layer for RBridges (Routing Bridges), devices
that implement the IETF TRILL standard [RFC6325] [RFC6326], and the
splitting of the bridge layer into Customer Bridges and Provider
D. Eastlake, S. Hares, J. Hudson [Page 7]
INTERNET-DRAFT RBridge Compatibility
Bridges. RBridges are discussed in Section 2.3.1, Customer Bridges
and VLANs are discussed in Section 2.3.2, and Provider Bridges and
Provider VLANs are discussed in Section 2.3.3.
The transparency and bounding properties of layers, depending on
their relative position, are as before. Any of the four types of
devices shown layered above provider bridges will bound a provider
bridged LAN. To customer bridges, provider bridges are approximately
transparent, while RBridges, Layer 3 routers, and user end stations
will bound a customer bridged LAN. To RBridges, customer and provider
bridges are approximately transparent while Layer 3 routers and user
end stations bound an RBridge campus. To Layer 3 routers, bridging
and RBridges are all approximately transparent while user end
stations bound a routed area. And user end stations see all four
types of devices layered below user end stations as approximately
transparent.
2.3.1 RBridges (Routing Bridges)
RBridges are devices that implement the IETF TRILL standard.
(Approval of the TRILL base protocol [RFC6325] as an IETF standard
was announced 15 March 2010. Approval of the TRILL base protocol
specific IS-IS code points and formats [RFC6326] used as an IETF
standard was announced 9 February 2011.)
There have been endless arguments about whether RBridges are routers
or bridges. They are neither. They are a new type of device that is
demonstrably higher layer than a Layer 2 bridge, because they bound
bridging protocols such as spanning tree and stop bridges from
peering with each other, and demonstrably lower layer than Layer 3
routing because they are transparent to Layer 3 routing such as IS-
IS. So Layer 3 routers can peer through RBridges.
Nevertheless, when looked at in one way, RBridges are a type of
router because they implement a Hop Count, can do equal cost multi-
path, swap the outer link header on each RBridge hop, etc. But,
looked at another way, they appear to be a type of bridge because
they transparently deliver frames unmodified, can provide useful plug
and play service with zero configuration, honor frame customer VLANs
and priorities, and the like.
Arguing about what an RBridge "really" is like arguing about whether
a proton is really a wave or a particle. The fact that you can
perform experiments that provide very strong evidence that a proton
is a wave and other experiments that provide the same for it being a
particle does not make it a wave or just a particle. A proton is
really just a proton and has wave/particle duality. Just so, the fact
that you can present strong arguments that an RBridge is a router or
D. Eastlake, S. Hares, J. Hudson [Page 8]
INTERNET-DRAFT RBridge Compatibility
that an RBridge is a bridge does not make RBridges be one of those
types. RBridges are just RBridges, a new type of device at a new
layer.
Looking downward in our layering and peering model from RBridges,
RBridges as currently standardized do not forward frames sent to any
of the addresses in the basic 01-80-C2-00-00-00 to 01-80-C2-00-00-0F
bridging and link protocols block. Thus they bound and are layered
above bridging protocols and they appropriately scope link protocols.
In particular, this means they bound the various versions of the
spanning tree protocol. It was always a goal of TRILL to bound the
spanning tree protocol due to its poor performance in large networks
[RFC5556]. RBridge ports may still interact with bridging and/or
link protocols but those bridging and/or link protocols cannot
communicate through an RBridge between ports of that RBridge.
The TRILL protocol itself, including IS-IS control frames supporting
TRILL, uses unicast frames addressed to RBridge ports and multicast
frames sent to MAC addresses in the block from 01-80-C2-00-00-40 to
01-80-C2-00-00-4F. That block has been reserved exclusively for TRILL
use by the IEEE Registration Authority [RegAuth]. Since these
addresses have no special meaning to bridges, bridges forward them
normally and thus bridges are transparent to TRILL.
On the other hand, looking up our layering and peering model from
RBridges, because this block of TRILL multicast addresses has no
special meaning to Layer 3 routers, frames addressed to them are
discarded by Layer 3 routers, bounding the RBridge campus. Thus
RBridges are layered below Layer 3 routers. User end stations also
bound an RBridge campus, even if they are multi-port, because the
don't normally forward anything.
The default for a bridge is to forward frames it doesn't know
anything about. The default for a Layer 3 router is to discard frames
it doesn't know anything about. The default for a user end station is
to forward no frames.
2.3.2 Customer Bridges and VLANs
(The discussion of bridge types and VLANs in this and the immediately
following section may seem a bit tedious but stick with it, they are
of some relevance to the topic of this document.)
Bridging worked well enough that there was a desire to share bridged
LANs across multiple Layer 2 communities. To differentiate these
communities, a "tag" was specified to indicate the particular "VLAN"
(Virtual LAN) a frame was in. It consisted of the Ethertype 0x8100
followed by 2 bytes that include a 12-bit VLAN identifier. (For
D. Eastlake, S. Hares, J. Hudson [Page 9]
INTERNET-DRAFT RBridge Compatibility
brevity, the use of the remaining four bits in these two bytes will
be ignored.) This tag goes after the MAC destination and source
addresses and before the payload in Ethernet frames. It labels the
frame as being in the VLAN indicated. Use of other than a default
VLAN requires configuration.
Devices at different layers commonly treat VLANs differently but VLAN
treatment is a characteristic that can vary for different devices at
the same layer:
Bridges: Typically data frames sent between VLAN-aware bridges are
VLAN tagged but, since most end stations are not VLAN-aware, those
sent to/from end stations are usually not. The VLAN of an untagged
frame received by a VLAN aware bridge is typically determined by
the port on which it arrives but may be determined by the frame's
protocol or other factors. Unless a VLAN group or the like is
configured, bridges keep data in different VLANs isolated. Bridge
ports can be configured to filter on VLAN.
RBridges: Customer VLANs are treated by RBridges in a manner similar
to bridges. There are differences but they are not relevant to
this document.
Layer 3 Routers: Some Layer 3 routers are VLAN aware and some are
not. They typically treat data in different VLANs arriving at a
port as arriving on different virtual ports. In this case, the
data internal to the Layer 3 router has typically lost its VLAN
tagging and the router may not consider VLAN identity in deciding
which port or ports to output the packet on or whether to drop a
packet. If VLAN unaware, a Layer 3 router treats the VLAN tag as
part of the data; however, that data might not be routed because,
if the VLAN tag Ethertype was visible to the router, it would not
be recognized as a type of Layer 3 traffic to route.
User End Stations: User end stations are generally VLAN unaware and
also might treat a VLAN tag as part of the data; however, in that
case the data would not typically be processed because the VLAN
tag Ethertype would not be recognized as a type of traffic a VLAN
unaware end station is interested in.
When provider bridges and VLANs, discussed in Section 2.3.3, were
added to IEEE 802.1, the previously standardized bridges and VLANs,
discussed above, were retroactively called "customer" bridges and
"customer" VLANs to distinguish them from provider bridges and VLANs.
D. Eastlake, S. Hares, J. Hudson [Page 10]
INTERNET-DRAFT RBridge Compatibility
2.3.3 Provider Bridges and VLANs
"Provider" facilities derive from the concept of a carrier providing
Ethernet connectivity to customers. As a first approximation, they
would like to be transparent to the customer devices and traffic. So,
naturally, Provider Bridges are at a lower layer than customer
bridges. As a result, customer bridges and all higher layer devices
block peering between provider bridges and bound provider bridged
LANs. This is primarily accomplished by (1) provider bridges being
transparent to multicast address 01-80-C2-00-00-00, the address used
for Customer Bridge spanning tree peering and the like and (2)
provider facilities using the multicast address 01-80-C2-00-00-08, a
destination address customer bridges discard, for provider bridge
peering.
Of course, the bits don't know anything about business relationships
so "provider" facilities can be used inside the network of what a
carrier would consider a "customer".
Provider Bridges use VLANs but they use a different tag. The VLAN ID
field is the same size, 12 bits, but the Ethertype is different
(0x88A8) and they are called S-tags, for service tags, and customer
VLAN tags are now commonly called C-tags.
The first type of Provider Bridge specified use of S-tags and S-VLANs
to separate the traffic from different customers or services. If
there are already C-tags in place, this results in two nested VLAN
tags, an S-tag and then a C-tag relative to that S-tag. This is
colloquially known as "Q-in-Q".
To the extent that provider bridged LANs are supplying a service to
multiple different customers, provider facilities want to protect
themselves from customer behavior. They are typically more
configuration dependent than customer bridges. If customer facing
"edge" ports and internally connected ports are rigorously
configured, then the provider bridging should be relatively immune to
customers forging provider control frames or the like. In fact, such
frames need not have been "forged". It can easily be the case that
what is desired is a second order provider or the like, connecting
"customer" LANs that are already using the provider bridging
protocols.
"Q-in-Q", or nested VLAN tags, do not isolate provider bridges from
having to learn customer MAC addresses for transit traffic and use of
S-tags in the obvious way to isolate services limits the number of
services to 4K. Provider Backbone Bridges (PBBs) overcame these
limitations. PBBs use a "MAC-in-MAC" encapsulation so that customer
MAC addresses are nested inside PBB MAC addresses and those customer
MAC addresses need only be learned by edge PBBs. PBBs also use an
expanded tag, called an I-tag, that provides a 24-bit Service
D. Eastlake, S. Hares, J. Hudson [Page 11]
INTERNET-DRAFT RBridge Compatibility
Instance Identifier that can be used, in effect, as a VLAN. PBB can
make use of an outer VLAN tag that uses the same Ethertype as the S-
VLAN tag but is called a "B-VLAN tag" (backbone VLAN) and is used for
different purposes than the S-VLAN, purposes such as traffic
engineering.
Customer and provider bridging are both standardized by IEEE 802.1
and they are more entangled than one might expect for two different
layers. For example, there are "provider aware" customer bridges that
use S-tags on frames they submit to provider bridges to indicate the
service desired for the frame. However, generally, all layers above
customer bridging are S-tag ignorant; they treat an S-tag as just
part of the data
What happens when an RBridge gets a frame with an S-tag? This is a
trick question. At first glance, it seems pretty ugly. RBridges as
currently specified don't recognize S-tags and treat them as part of
the payload. An RBridge campus could ingress such a frame and egress
it, still S-tagged, from another port or ports of the same or some
other RBridge, perhaps causing some confusion.
But, wait a minute, how is this any different from what any provider-
ignorant customer bridge would do if it got a frame starting with an
S-tag? Or what a Layer 3 router might do? In fact, it is pretty much
the same.
Asking this trick question is like asking what happens if you divide
1 by 0. If you have gotten to a place where you are trying to divide
1 by 0, you've already made a mistake. Just so, if you have gotten to
the point where a frame intended for a provider device, as denoted by
an S-tag, is being sent to a customer device that does not understand
S-tags, particularly one that will likely forward it, such as a
customer bridge or an RBridge, your network is already misconfigured.
D. Eastlake, S. Hares, J. Hudson [Page 12]
INTERNET-DRAFT RBridge Compatibility
3. A Prevalent Confusion
When the TRILL Working Group was starting up in the IETF, IEEE 802.1
was working on its Provider Backbone Bridging (PBB) project. It
happens that both protocols do what is called "MAC-in-MAC", although
they do it for different but overlapping sets of reasons. These
reasons include, in the TRILL protocol, providing a place for a Hop
Count and options, and in the PBB amendment to the 802.1Q protocol,
providing a place for a 24-bit Service Instance Identifier and a new
priority field. (There are other differences.) In both cases original
destination and source MAC addresses are nested inside new
destination and source MAC address fields that are used inside the
RBridge campus (TRILL) or Provider Backbone Bridging region (PBB) and
these new address fields are discarded and the original addresses are
restored on exit from that campus or region.
The coincidence of TRILL and PBB both doing "MAC-in-MAC" has been a
source of endless confusion. For years, at essentially every TRILL
Working Group meeting someone would ask a question that made it clear
that, perhaps because TRILL and PBB both did "MAC-in-MAC", the
questioner believed that TRILL *must* be a provider protocol
appropriate for use by carriers connecting parts of customer
networks. But encapsulation, or a "MAC-in-MAC tag", or whatever you
want to call it, has nothing to do with the relative layer of a
protocol in the model discussed in this document. Based on that
model, RBridges, as currently standardized, are customer devices
above the customer bridge layer, while PBBs are provider devices at
the Provider Bridging layer.
For example, there is no problem connecting different parts of an
RBridge campus together through provider bridging. If you used
Provider Backbone Bridges for such provider bridging, as shown below,
you would have two nested levels of "MAC-in-MAC" inside the provider
bridged LAN for the RBridge campus TRILL Data frames. The provider
bridged LAN would look to TRILL like just a transparent part of a
TRILL level link between RBridges.
+---------+ +-----+ +-----+ +---------+
----| RBridge |-----| PBB |-------| PBB |-----| RBridge |----
^ +---------+ ^ +-----+ ^ +-----+ ^ +---------+ ^
| | | | |
Note 1 Note 2 Note 3 Note 2 Note 1
Figure 4
Note 1: Zero or one level of MAC-in-MAC depending on the extent of
the RBridge campus.
Note 2: Inside an RBridge campus. One level of MAC-in-MAC.
Note 3: Inside Provider Back Bridged region that is in turn inside an
RBridge campus. Two levels of MAC-in-MAC.
D. Eastlake, S. Hares, J. Hudson [Page 13]
INTERNET-DRAFT RBridge Compatibility
The RBridges in the above diagram peer with each other through the
PBBs, becoming part of one RBridge campus that encompasses the
entirety of the provider bridge LAN that includes the PBBs shown. The
RBridges are part of the bounds of that provider bridged LAN. If
there are any other RBridges connected elsewhere to that provider
bridged LAN or to customer bridges connected to the that provider
bridged LAN, those RBridges will also be part of that RBridge campus.
On the other hand, if the nesting is reversed, the Provider Backbone
Bridges will, of course, be unable to peer through the higher layer
RBridges and the RBridges will bound any adjacent provider bridged
LAN(s). As a result, for traffic between end stations that are off
the left and right edges of the page in Figure 5 and assuming no
additional RBridges between the RBridges shown and those end
stations, there will be no more than one level of "MAC-in-MAC"
nesting as shown below.
+-----+ +---------+ +---------+ +-----+
----| PBB |-----| RBridge |-------| RBridge |-----| PBB |----
^ +-----+ ^ +---------+ ^ +---------+ ^ +-----+ ^
| | | | |
Note 4 Note 5 Note 6 Note 5 Note 4
Figure 5
Note 4: Zero or one level of MAC-in-MAC depending on the extent of
the PBB region.
Note 5: Native frames with zero levels of MAC-in-MAC.
Note 6: Inside an RBridge campus. One level of MAC-in-MAC.
In Figure 5, because the PBBs cannot peer through the RBridges, they
are each part of a separate PBB region unless there is a path, not
shown, uniting them into a single PBB region.
You can shuffle the boxes around in the above diagrams in other ways,
but this does not reveal anything particularly interesting. For
example:
| | | | | |
+-----+ +---------+ +-----+ +---------+
----| PBB |-----| RBridge |-----| PBB |-----| RBridge |----
+-----+ +---------+ +-----+ +---------+
| | | | | |
Figure 6
Looking at Figure 6, it is certainly possible to confuse yourself,
perhaps if you try to think about the RBridges as simultaneously
being bridges and routers and apply some particular ideas about how
D. Eastlake, S. Hares, J. Hudson [Page 14]
INTERNET-DRAFT RBridge Compatibility
bridge and routers are "supposed" to work. But, if you apply the
simple principles given in this document, it is easy to see what
happens. From the RBridges' point of view, the PBBs are approximately
transparent, so all of the above diagram is part of a single RBridge
campus. From the PBBs' point of view, PBBs cannot peer through
RBridges so the RBridge facing PBB ports are PBB edge ports and the
PBBs shown are parts of one or two PBB regions depending on whether
there is a PBB path between them. (No such path is shown in Figure
6.)
For Figures 4 through 6 you could replace "PBB" and "RBridge" with
any relatively lower layer and relatively higher layer devices with
the same results as to regions and bounds. (The "MAC-in-MAC" comments
above would only apply to the extent that one or both of the devices
types were RBridges or the PBB type of Provider Bridge, the only
devices discussed that do "MAC-in-MAC".) The names of the regions
involved would change as follows, based on the vocabulary used in
this document:
Device Region Name in this document
--------------- ------------------------------
End Station network
Layer 3 router routed area
RBridge campus
Customer Bridge bridged LAN
Provider Bridge provider bridged LAN
D. Eastlake, S. Hares, J. Hudson [Page 15]
INTERNET-DRAFT RBridge Compatibility
4. Shortest Path Bridges
Shortest Path Bridges (SPBs) are being specified by IEEE 802.1
through their [802.1aq] drafts (and in the applicable parts of the
IEEE virtual LAN bridging standard [802.1Q] that is to be amended by
802.1aq). ([802.1aq] is anticipated to become an IEEE Standard
sometime in 2012.)
Shortest Path Bridges have been somewhat of a moving target. They
started as a variety of Provider Bridge operating within the Provider
Bridging layer. Later, a type of SPB based on Provider Backbone
Bridging (PBB) was added. We will refer to these as PBB SPB and non-
PBB SPB. (The IEEE 802.1 abbreviation for PBB SPB is SPBM (where M
stands for MAC Mode) and for non-PBB SPB, it is SPBV (where V stands
for VID (VLAN ID) Mode.) Like previous Provider Backbone Bridges,
PBB SPBs only peer with each other over point-to-point links.
SPBs of either type can forward frames using bridging mechanisms that
are configured to provide least-cost paths. In the earliest versions
of SPB, this was done with many instances of spanning tree protocol
but later SPB drafts specify the use of the IS-IS protocol to
configure bridge-forwarding mechanisms. All versions of SPB so far
have also retained the ability to forward using variations of the
spanning tree protocol. Which method is used for a particular frame
is determined by that frame's VLAN and the SPB's configuration.
Earlier SPB drafts specified only the use of the standard multicast
addresses used for Layer 3 routing for SPB IS-IS. While it might seem
this would interfere with Layer 3 routing, as long as the ports for
PBB SPB are properly configured as to which are edge ports and which
are internal ports, then any Layer 3 IS-IS control frames transiting
a SPB region using the PBB type of SPB will be encapsulated and not
falsely recognized as SPB IS-IS control frames. However, this does
not help the non-PBB version of SPB; so more recent SPB drafts
include the proposed allocation of provider bridging layer multicast
addresses, presumably from within the bridging and link protocols
multicast address block (01-80-C2-00-00-00 to 01-80-C2-00-00-0F), for
use in non-PBB SPB IS-IS.
In addition, recent versions of the SPB draft have suggested that
customer bridging layer multicast addresses be assigned for optional
use in sending SPB IS-IS control frames, presumably also from the
bridging and link multicast address block, and suggest that there
should be a way to have what would appear to be customer bridging
layer SPBs.
(As discussed in Section 2.3.1, for TRILL IS-IS, RBridges as
currently standardized use multicast addresses dedicated to the TRILL
protocol. These addresses do not overlap with the Layer 3 IS-IS
multicast addresses or with any of the bridging and link protocols
D. Eastlake, S. Hares, J. Hudson [Page 16]
INTERNET-DRAFT RBridge Compatibility
multicast addresses.)
D. Eastlake, S. Hares, J. Hudson [Page 17]
INTERNET-DRAFT RBridge Compatibility
5. Conclusions
This document describes a model of switching device layers and
peering that the authors believe corresponds to common ideas of
layers for such devices. Based on this model, RBridges implementing
the IETF TRILL standard are compatible, well behaved devices that
cleanly fit into a specific relative layer of their own.
Also based on this device layer and peering model, the current IEEE
802.1 Shortest Path Bridging (SPB) draft appears to specify similarly
compatible and well behaved devices. SPBs were originally at the
Provider Bridging layer but their specification appears to be
undergoing extension so they may also optionally operate at the
Customer Bridging layer.
As required by the original TRILL WG Charter, a review by the IEEE
802.1 Working Group of the TRILL base protocol specification was
requested before its approval as an IETF standard. This resulted in
the IEEE 802.1 Liaison of 1 March 2009 to the IETF [Liaison] which
states in part:
"By inserting RBridges into a C-VLAN network a network structure
is created that is incompatible with current 802.1Q S-VLAN and B-
VLAN network architecture."
The IEEE 802.1 "S-VLAN and B-VLAN network architecture" is, as far as
the authors can tell, the layer at which Provider Bridges and
Provider Backbone Bridges operate. RBridges work just fine with
provider bridging in accordance with their relative layer (see Figure
3). Thus the authors believe that the IEEE 802.1 Working Group's
assertion of "incompatibility" is incorrect. And the IEEE 802.1
Working Group liaison's subsequent intimation that such mixed RBridge
and bridge networks would be, to use the word chosen by 802.1,
"broken", is equally incorrect.
RBridges as currently standardized and the latest Shortest Path
Bridging draft have similar goals when viewed at a high level of
abstraction. It is true that they achieve these goals through
different mechanisms and can be considered to be in competition;
however, the authors are unable to find any way in which they
currently conflict in a technical sense. Given that SPB is not yet an
IEEE standard and continues to evolve, whether this will be true when
802.1aq is finally approved as an IEEE standard (anticipated to occur
in 2012) cannot, unfortunately, be determined at this time.
D. Eastlake, S. Hares, J. Hudson [Page 18]
INTERNET-DRAFT RBridge Compatibility
6. IANA Considerations
This document requires no IANA actions. RFC Editor: Please delete
this section before publication.
7. Security Considerations
This is an informational document that does not consider security
questions or threats.
D. Eastlake, S. Hares, J. Hudson [Page 19]
INTERNET-DRAFT RBridge Compatibility
8. Informative References
[802] - IEEE 802, "IEEE Standard for Local and Metropolitan Area
Networks / Overview and Architecture", 802-2001, 6 December
2001.
[802.1aq] - IEEE 802.1, "Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment 9: Shortest
Path Bridging", Draft P802.1aq/D4.0, 14 June 2011.
[802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
networks - Virtual Bridged Local Area Networks", IEEE Std
802.1Q-2011, May 2011.
[IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
Intermediate System Intra-Domain Routeing Exchange Protocol for
use in Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2002.
[ITU-X.200] - ITU-T, "X.200 : Information technology - Open Systems
Interconnection - Basic Reference Model: The basic model", July
1994.
[Liaison] - IEEE 802.1,
<https://datatracker.ietf.org/documents/LIAISON/file710.pdf> or
<http://www.ieee802.org/1/files/public/docs2009/liaison-to-
trill-wg-0309.pdf>, 1 March 2009.
[RegAuth] - IEEE Registration Authority,
http://standards.ieee.org/develop/regauth/index.html
[RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol
Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September
2008.
[RFC5556] - Touch, J. and R. Perlman, "Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability Statement",
RFC 5556, May 2009.
[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", RFC 6325,
July 2011.
[RFC6326] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, and A.
Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011.
D. Eastlake, S. Hares, J. Hudson [Page 20]
INTERNET-DRAFT RBridge Compatibility
9. Normative References
This is an empty normative references section to make the nits
checker happy. As an informational document, there are no normative
references. RFC Editor: please delete this section before
publication.
D. Eastlake, S. Hares, J. Hudson [Page 21]
INTERNET-DRAFT RBridge Compatibility
Authors' Addresses
Donald Eastlake, 3rd
Huawei Technologies (USA)
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-333-2270
EMail: d3e3e3@gmail.com
Susan Hares
Huawei Technologies (USA)
2330 Central Expressway,
Santa Clara, CA 95050, USA
EMail: shares@huawei.com
Jon Hudson
Brocade
130 Holger Way
San Jose, CA 95134 USA
EMail: jon.hudson@gmail.com
D. Eastlake, S. Hares, J. Hudson [Page 22]
INTERNET-DRAFT RBridge Compatibility
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
D. Eastlake, S. Hares, J. Hudson [Page 23]