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

From: James Kempf <[email-masked]>
Date: Wed, 28 Feb 2001 08:39:45 -0800

(Hoping this gets through the MIP mailing list problems...)

In draft-thomas-seamoby-rsvp-analysis-00.txt, some serious problems with MIP
and RSVP signalling are identified. 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.

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
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.

So, I'm wondering if the regional registration BU routing option could 
serve as a trigger for redoing the RSVP signalling for QoS? Comments?

		jak

---

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

> (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]

> and RSVP signalling are identified. 
> 
	=> Sure RSVP doesn't handle IP mobility.

> Specifically, when a handoff occurs,
	=> Yes.

> regional registrations) is defined that works very much like a host route. 
	=> No it doesn't. The MN's CoA changes when the MN moves.

> signalling as in the standard
	=> 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.

> 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: 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]
> Subject: 	RE: [seamoby] Hierarchical MIP, QoS, and Handoff
> 
> 
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

=> Yes.

 Regards,
 Hesham