Subject: RE: [seamoby] Micromobility Problem Statement

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Jan 2001 06:49:23 -0800 (PST)

> 
> >I am aware of this problem. RSVP is not well suited for mobility
> >support because of the nature of the PATH state and the way it
> >is setup.
> >
> >This doesn't mean there isn't an edge solution, as Steve implied.
> >It does mean that a good solution may require looking at RSVP
> >and RSVP state closely. I don't think resending RSVP path and
> >resv messages is the way to handle QoS mobility in any case.
> >
> 
> I agree. Whether or not QoS state needs to be transferred
> depends on the QoS solution for mobile nodes, and I don't believe
> that is something currently within the charter of the Seamoby group,
> though, IMHO, it should be in *someone's* charter.
> 
My 2 cents on this one:

more signaling != seamless

For that matter, it appears as if diffserv needs to be used in the core. Now,
perhaps some signaling from the mobile is needed to get the edge device to
"reserve" the resources. This information can be transfered in the context
transfer, so no new signaling would be needed by the mobile.

This, of course, also needs to work across domains, so the QoS info transfered
would have to be "generic", and able to be mapped to the local DSCP.

PatC

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Jan 2001 10:07:36 -0800 (PST)

> more signaling != seamless

   There ain't no such thing as a free lunch. Also: it's not
   entirely clear whether L2 blocking is useful here or
   not. If it is, modularity may be the better direction.
 
 > transfer, so no new signaling would be needed by the mobile.

   I don't see how it's our choice to mandate diffserv;
   we're not the protocol police after all. The fact is
   that some networks will be built with Intserv and/or
   Intserv/Diffserv mixes.

 > would have to be "generic", and able to be mapped to the local DSCP.

   Sure. The same goes for signaled QoS too.

	     Mike