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: "Glenn Morrow" <[email-masked]>
Date: Thu, 1 Mar 2001 15:29:53 -0600

Regards,

Glenn

---

From: Roberts Philip-qa3445 <[email-masked]>
Date: Wed, 28 Feb 2001 13:45:17 -0600

> ----------
> From: 	Hesham Soliman  (ERA)
> Sent: 	Wednesday, February 28, 2001 1:42 PM
> To: 	'James Kempf'; [email-masked]'
> Cc: 	[email-masked]
> > (Hoping this gets through the MIP mailing list problems...)
> > 
> 	=> It didn't. I think this is definitely a MIP issue so we should 
> 	discuss it on the MIP list. You need to send your mail to
> 	[email-masked]
> 
> 
Actually, we're currently in the process of moving the MIP mailing list.  You should receive an email on it when it's up later today (hopefully).  Many thanks to Sun for hosting and administering the list going forwards.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Feb 2001 20:42:15 +0100

> In draft-thomas-seamoby-rsvp-analysis-00.txt, some serious problems with MIP
> and RSVP signalling are identified. 
> 
	=> Sure RSVP doesn't handle IP mobility.

> Specifically, when a handoff occurs,
> a round-trip BU must occur before the CN can issue an RSVP PATH message
> to assure QoS over the new route. Aggregated RSVP (see 
> draft-ietf-rsvp-aggr-02.txt)
> doesn't help, because the BU must still propogate to the CN for the CN to issue
> the PATH. All aggregation does is reduce the state in routers internal to the
> aggregation region, it does not reduce signalling requirements over 
> standard RSVP.
> 
	=> Yes.

> There is a case where signalling can be optimized that is identified in
> draft-thomas-seamoby-rsvp-analysis-00.txt. This is the case where the movement
> of the mobile does not involve a change in CoA but rather is handled by 
> installing
> a new host route up to the join router between the old and new path. 
> Establishment
> of the new route is followed by a PATH message from the new join router
> to the MN, and a RESV from the MN back to the join router (pg. 10 in the 
> draft).
> 
> In draft-malinen-mobileip-regreg6-00.txt, a hierarchical MIP mechanism (called
> regional registrations) is defined that works very much like a host route. 
> Routers
> 
	=> No it doesn't. The MN's CoA changes when the MN moves.

> between the new access router and the join router (called a crossover router
> in the draft) examine a BU routing option and the join router reconfigures its
> binding table to take account of the new route. The routers here are defined
> to be special regional aware routers, but the principle is the same.
> 
> Note that in HMIPv6 (draft-ietf-mobileip-hmipv6-01.txt), since the 
> intervening routers between the MAP and the mobile node never see the 
> topology change, the same severe performance penalties w.r.t. RSVP 
> signalling as in the standard
> MIPv6 case should occur.
> 
	=> If you believe a crossover router solves the problem
	then you can see the MAP as the same thing. But the fact
	is neither a cross over router (in draft-malinen-...) nor HMIPv6
	solves that problem. A new PATH needs to be setup anyway
	for the outgoing traffic. The path between the MAP and the 
	CN is unchanged for incoming traffic.

> So, I'm wondering if the regional registration BU routing option could 
> serve as a trigger for redoing the RSVP signalling for QoS? Comments?
> 
	=> I think the problem is much bigger than that. The issue of mobility 
	and QoS needs to be addressed in more detail. Michael's draft (I haven't
	finished it yet) is a very good start. We can't solve it for HMIP only, 
	the problem needs to be addressed for MIP in general.

	Regards,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Feb 2001 20:42:15 +0100

=> Yes.

 Regards,
 Hesham

---

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

Regards,

Glenn

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 28 Feb 2001 20:42:15 +0100

=> Yes.

 Regards,
 Hesham