[rbridge] Subcase for RBridges?
Guillermo Ibáñez
gibanez at it.uc3m.es
Wed Nov 2 10:01:34 PST 2005
Eric,
My proposal does not require RBridge to be aware of link type,
functions to work with bridges are implemented by the
B bridge "attached" to RB.It is a potential variant of the RBridge
protocol only to be used in campuses where RBridges are directly
connected between them forming a core and do not allow standard bridges
interposed. Standard bridges are allowed only as Access Layer (any
port hearing standard STPs BPDUs runs STP).
Gray, Eric wrote:
>Guillermo,
>
> I assume that - by point-to-point link - you mean full-duplex
>Ethernet/802. Since we are not trying to address L2 connectivity
>other than Ethernet, that should be the case within the scope of
>discussion on this list.
>
>
>
I mean not shared links. It may work half-duplex or full-duplex.
> It is difficult for any implementation to divine the nature of
>the "wire" connecting it to another implementation - whether RBridge
>or bridge. In many cases, it is possible - for example, by looking
>at port-type information and listening to both RBridge neighbor
>discovery and local STP - but not in every case.
>
>
>
The bridge is aware of the link type and the RSTP protocol state
machines use it.
/" 17.12 RSTP and point-to-point links
The rapid transition of a Designated Port to Forwarding depends on the
Port being directly connected to at
most one other Bridge [it is an Edge Port (17.3, 17.19.17), or is
attached to a point-to-point LAN, rather than
a shared medium]. The adminPointToPointMAC and operPointToPointMAC
parameters (6.4.3) provide
management and signalling of the point-to-point status to RSTP state
machines.
A newly selected Root Port can transition to Forwarding rapidly, even if
attached to shared media."/
> For example, the mysterious "lurking" L2 forwarding device that
>participates in neither RBridge neighbor discovery, nor STP would be
>invisible and - presumably - RBridges would likely be invisible to
>it as well.
>
> In addition, there are a variety of transitional states in
>which it is very likely that an inferred point-to-point link will
>no longer be point-to-point and the RBridges will not be aware of
>that.
>
>
All these functions are in the B bridge attached to the RB, RB does not
need to control them.
The "attached" B as proposed by Radia has many advantages for RB
regarding compatibility in the interaction with standard bridges.
> However, even if all this were not true, what do we gain from
>"special casing" this special case - even if it does turn out to be
>common?
>
>
>
This special casing could be a variant for campuses where RBridges are
all connected together forming a network core,whitout bridges interposed
between them. Standard bridges are only allowed at the outside of the
core. This scenario is better suited for high performance, better
network predictability and faster reconfiguration .
> I assume we're not intending that a frame may use a different
>path, in this special case and not using the next-hop MAC address,
>so it still goes through the same devices. That would be opening
>a different can of worms. The only difference is that frames don't
>get their MAC SA/DA changed at each RBridge. But that's a simple
>operation for typical forwarding hardware.
>
>
Although changing destination address at each hop is not too
complicated, this is something that even routers do not do, they keep
the IP source and destination addresses of packets.
> Given that the forwarding device has to be able to do that,
>there isn't anything to gain from being able to avoid doing so -
>sometimes.
>
> As for what Radia suggested earlier, there's a difference
>between potentially having logical bridges in-line with ports on
>an RBridge, and having a logical bridge connecting the ports of
>an RBridge. But these are simply hybrid implementations and,
>for our purposes, they can be considered separately from the
>requirements for an RBridge.
>
> +------------+
> +------------------------+ | +---+ |
> | | | +--+ B +-+ |
> | +---+ +----+ +---+ | | | +---+ | |
> ---+--+ B +--+ RB +--+ B +--+--- ---+-+ +-+---
> | +---+ +----+ +---+ | | | +----+ | |
> | | | +-+ RB +-+ |
> +------------------------+ | +----+ |
> Hybrid A +------------+
> Hybrid B
>
Is Hybrid B allowed?
> |
> +------+-----+
> | +-+-+ |
> | | B +-+ |
> | +---+ | |
> ---+-+ +-+---
> | | +----+ | |
> | +-+ RB +-+ |
> | +----+ |
> +------------+
> Hybrid C
>
>Each of the above "hybrid" implementations is possible. But from
>our perspective, we want to define the "RB" boxes and we can look
>at each of these as "outside" the "RB" box. From that perspective
>all of these "hybrids" become simple variations of one or another
>of the topology examples we have already discussed.
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: rbridge-bounces at postel.org
>--> [mailto:rbridge-bounces at postel.org]On
>--> Behalf Of Guillermo Ibáñez
>--> Sent: Friday, October 28, 2005 5:09 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: [rbridge] Subcase for RBridges?
>-->
>-->
>--> I have a question regarding next-hop destination RBridge
>--> addressing. It
>--> could be avoided whitin campus cores.
>--> One objection that can be made to RBridges and other
>--> proposals that keep
>--> compatibility with bridged islands is that the
>--> double-encapsulated
>--> frame is addressed to next-hop RBridge instead of to destination
>--> RBridge. This is necessary as, if not, the frame could be
>--> duplicated by
>--> intermediate RBridges that receive copies of the frame.
>--> As in some cases it is foreseable that RBridges will form
>--> the core of
>--> the campus network due to their advantages regarding
>--> segmentation, links
>--> usage, etc, I wonder whether it is worth to consider the subcase of
>--> confined RBridges whithin a core area formed by RBridges
>--> linked by point
>--> to point links. Point to point links are an standard
>--> requirement for
>--> RSTP protocol (required for fast convergence) and common
>--> practice in
>--> campus networks by performance and security reasons.
>--> Ports of RBridges linked to RBridges ( core ports) execute RBridges
>--> protocol with double encapsulation and ports connected to standard
>--> bridges islands (sbridge ports) act as the "B1" standard bridge as
>--> proposed by Radia for RBridge/Bridge optional implementation.
>--> Assuming an scenario like this, RBridges might address directly the
>--> encapsulated frame to destination RBridge and only the TTL
>--> field would
>--> need to be changed at each RBridge.
>--> It is not the general and standard scenario, but it could
>--> be in practice
>--> quite common, given their advantages.
>--> Guillermo
>--> _______________________________________________
>--> rbridge mailing list
>--> rbridge at postel.org
>--> http://www.postel.org/mailman/listinfo/rbridge
>-->
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>
>
More information about the rbridge
mailing list