[rbridge] Multiple instance/hierarchical RBridge topologies
Radia.Perlman at sun.com
Fri Dec 22 22:35:44 PST 2006
After talking to a bunch of people, I think I understand a feature, and
here are thoughts on how
to implement it.
The two problems we might solve:
a) ensure that two different RBridged clouds don't accidentally merge
b) allow a hierarchy of RBridged clouds (yes, similar to L2VPN or
provider backbone bridges)
In the case of b) it would be useful to encapsulate data packets with a
customer ID, whereas such
a field would not be necessary for a customer campus/CRED/RBridged-cloud.
IS-IS already has a field "area address" that can be configured to keep
two IS-IS instances separate.
So, for instance,
the default can be area=0, but if there are two different RBridged
clouds that are intended to be kept
separate, but they are physically close enough that someone is afraid
they might accidentally merge, then
you can configure the area address in all of the RBridges
in at least one of the clouds to prevent two alien RBridges from talking to
For hierarchy, we could do the same thing (configure the higher layer
RBridge cloud to have an
area address something other than 0). That way customer RBridged nets
would not accidentally merge
with the core instance. But as I'll explain, I think the backbone
RBridges would need to be slightly
different from the lower-level RBridges.
There are two "community" things that we want to keep separate, and
let's call them "customers" and
"VLANs within customer". RBridges as currently specified keep VLANs
separated. However, if
we have a higher level of RBridges connecting customers, each of whom
are using VLANs, the
core RBridges need to keep separate communities of (customer, VLAN) pairs.
So let's think of a "community" as having a hierarchically assigned
"community" name, which would be
"customer ID" concatenated with VLAN tag, or (customer, VLAN). The rule
is that two endnodes can only
talk to each other if they are in the same tuple (customer, VLAN).
This really results in all the same algorithms as RBridges already do in
terms of filtering so that multicasts
within a VLAN stay within a VLAN, except that it's a bigger field: it's
(customer, VLAN) now.
Therefore, the difference between case a) and b) above is that RBridges
also have to know
how many components are in the community tag. In a) RBridges assume the
specified by the VLAN tag in the inner packet. In b), we need for
RBridges in the backbone to
add another field to specify another level of hierarchy in the tag. In
an earlier note, we were suggesting
using a VLAN tag in the outer header. But perhaps it would be more
cleanly expressed as another
field in the shim header used by the backbone RBridges.
So, here is a suggestion:
Make the "area address" in IS-IS have two parts: (level of hierarchy |
The default is level=0, and name=0.
Backbone RBridges would use level=1, and name could be anything, but all
RBridges in the
same cloud all have
to be configured with the same name (0 would work).
RBridges at level 1 will encapsulate data packets with an extra field
that separates communities. So at level 1, we'd add to the shim a 16-bit
field, that we could think
of as "customer ID". So if the shim header is 6 bytes at level 0, it
would be 8 bytes at level 1, since
it would also have the extra "customer" field.
I don't think we'd ever need more than 2 levels, but we might want to
think about that -- I'd guess
we'd assume 2 "customer ID" fields in the shim at level 2.
At level 1, in the per-VLAN instance which passes around endnode
information and IP multicast membership,
the only difference would be like having a VLAN tag which is 28 bits (12
plus 16), and in theory, one
could have 2^28 instances of IS-IS passing around endnode information
across the backbone.
Comments? I hope I'm being reasonably clear.
More information about the rbridge