Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 1 Mar 2001 15:29:53 -0600

Sounds like a no-brainer to me. The handoff signaling was the question and
it looks like an ICMP solution has emerged? 

Where do you propose to put the objects there or have you not resigned
yourselves to accept the ICMP solution (i.e. do you still want to try to
push RSVP)?

I really care more about the function than the WG or the protocol choosen -
pick one.

One advantage (tenous as it may be) of putting the QoS objects in IP itself
is that it pretty much stops the argument about which protocol or WG to use
for what, when more than one function is needed. 

Extremely counter to this is the investment each party has made in existing
signaling solutions. 

With a start from scratch mentality I would put in an IP header as I feel
that it is a network layer function.

Regards,

Glenn

> -----Original Message-----
> From:	Michael Thomas [SMTP:[email-masked]]
> Sent:	Thursday, March 01, 2001 12:33 PM
> To:	Hemant Chaskar
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject:	RE: [seamoby] Hierarchical MIP, QoS, and Handoff
> 
> 
> I don't see how this fundamentally changes
> anything that James brought up. It still has to go
> end to end, and it's still touching every router
> in between MN and CN. 
> 
> What I do see is a lot of reinvention of RSVP
> Rspec and Tspec's for no known reason.  The only
> thing I can see of possible value is the ability
> to piggyback the QoS update with the BU, but even
> if this is the sole goal -- and that it's a worthy
> goal which is not at all apparent to me -- I
> imagine that there are better ways of doing this
> with out reinventing RSVP: like, maybe,
> piggybacking the BU on the PATH, or some such.
> 
> 	     Mike
> 
> 
> Hemant Chaskar writes:
>  > Regarding the issue of round-trip latency in programming QoS forwarding
> 
>  > treatment along new path after change in CoA:
>  > 
>  > This is intrinsic drawback of OPWA model of resource reservation of
> RSVP. In 
>  > the worst case, one round-trip time will include traversals of four
> wireless 
>  > links. This happens when both CN and MN are mobile.
>  > 
>  > Note that this drawback is eliminated in the approach to QoS signaling
> based 
>  > on including QoS Object in hop-by-hop options extension header along
> with 
>  > binding messages (draft-chaskar-mobileip-qos-00.txt). This draft was 
>  > presented in SD and revised version (01) will be submitted soon.
>  > 
>  > Hemant
>  > _________________________________________________________________
>  > Get your FREE download of MSN Explorer at http://explorer.msn.com
>  >

---

From: Michael Thomas <[email-masked]>
Date: Thu, 1 Mar 2001 15:25:10 -0800 (PST)

> yourselves to accept the ICMP solution (i.e. do you still want to try to

   It took me a while to grok what you were talking
   about. I'm still not certain I'm reading it
   correctly.

   The answer about RSVP is no. The RSVP thingy
   probably is still an interesting angle on the
   BURP BOF (though, mainly from a requirements
   angle at this point.)

   But I thought that the handoff signling
   supposedly emerging was the HI/HACK for fast
   handoffs which is orthogonal to what's being
   discussed here.

 > Extremely counter to this is the investment each party has made in existing

   I guess I'd like to keep some semblance of
   modularity where we can find it. I'm innately
   suspicious of the argument "protocol X is 
   can't possibly be used in situation Y because
   it (and it alone usually) is unique." IETF
   protocol are surprisingly resilient all in all.

		Mike