Subject: [rbridge] Draft problem statement

From: Konrad.Roeder at T-Mobile.com (Roeder, Konrad)
Date: Thu May 27 20:57:48 2004

Message: 5
Date: Wed, 26 May 2004 17:27:24 -0700
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Draft problem statement
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Erik Nordmark <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

>> 
>> I have a small question on this one. Suppose you have a rather large
>> campus with a rather large number of nodes moving around, and
>> you want to manage the whole thing as a single logical IP subnet.
>> 
>> If all the hybrid router/bridges in such a campus engaged in a
>> link-state routing protocol to keep track of the mobile nodes,
>> wouldn't there be a state and/or traffic scaling issue?
>> 
>I don't think state would be a problem. The database to keep
>track of endnodes would be no larger than if the RBridges were
>actual bridges. And this is very similar to CLNP, which for
>"level 1 routing" kept track of all the endnodes, and I believe
>fairly large level 1 areas were built (does anyone have any numbers?)
>
>But the other issue you bring up I think might be more important.
>I assume by "traffic scaling" you're not talking about
>data traffic, but instead the amount of link state information
>necessary to keep all the routers up-to-date about the
>location of all the endnodes.

>Hopefully the endnodes aren't *that* mobile. It's not being
>designed for mobile ad-hoc networking, but for
>wired networks. So endnode movement won't be
>very frequent. We just want it to be plug-and-play when it
>does happen.

It would be very limiting to state that this protocol is limited
to hard-wired networks only.  Many offices, hospitals, corporate
campusses, etc. are becoming unwired. 

Currently, many 802.11 wireless networks use one large subnet and
rely on a side effect of the protocol to "roam" (or hand-off) from 
one access point to another.  It's just like pulling the ethernet 
plug from a port in your office and walking down the hall and 
plugging back in again as long as the new port still serves up
the same subnet as before.

In wireless networks like airports or hotels, most subscribers
are in one place - at a certain gate or room.  A very small subset
may move from one access point to another.  I don't see why 
RBridge could not be implemented in wireless access points
(which currently are bridges) or in the access layer bridges
switches that the access points connect to.

>But on the other hand, endnodes might get powered down a lot.

In wireless 802.11 networks, this happens a lot too.  People 
simply walk off without closing their sessions.  They expect
that all accounting stops when they turn off their laptops.

>So the question is, how responsive should an RBridge be
>about declaring that it no longer owns an endnode?

>I'd suggest that as soon as an Rbridge discover a new
>neighbor endnode, it should announce it
>in its link state info. However, when it's down, unless it
>see some other RBridge claiming it in its
>link state info, there would be no harm
>in not telling anyone it is down, at least for awhile. If it
>has moved, the RBridge should immediately relinquish it so traffic goes
>to its new home. But if it has just powered down, it might be
>a problem in terms of traffic to let everyone know that.

So what do we do when a link goes down or is shut down?  Do we depend
on link-state age to wait for the link to come back up?  When do we 
advertise the change in the route?

>Radia

Konrad