Subject: Re: [seamoby] QoS and Mobile IP (was...)

From: James Kempf <[email-masked]>
Date: Thu, 22 Feb 2001 10:13:24 -0800 (PST)

Hi Mike,

>   I should have looked at my flows again before being
>   too flip.. it's more complicated than my "hopeless"
>   remark.
>
>   As it turns out, I believe that HMIP has the same
>   properties as both the CN and HA cases, meaning
>   that once the MAP sees the movement, it should issue
>   a PATH on the new (tunnel) interface. Since
>   the MAP is assumedly topologically closer, it
>   ought to converge faster. The MN->CN direction
>   would require MN to issue a PATH which would 
>   join at MAP, assumedly.
>
>   Also, there is the issue of dimensioning the 
>   tunnel itself which seemingly requires a
>   separate reservation. This is the same issue
>   as with FMIP though.
>
>   I do believe that all of these are helped by
>   CT though. However, with CT, I'm not entirely
>   sure what the benefit of HMIP is if any.
>

Is this true of aggregated RSVP as well?

As I'm sure you are aware, there are severe scalability problems with
RSVP as it is currently used that may preclude using it in large
scale networks. Aggregated RSVP helps solve those problems.

		jak

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Feb 2001 10:28:08 -0800 (PST)

> scale networks. Aggregated RSVP helps solve those problems.
 
   I'm not sure what "this" is refering to, but
   RSVP aggregation certainly adds an additional
   layer of fun. However, if the aggregation is
   done at or farther toward the core as AR or
   MAP, it probably doesn't change anything. I 
   have no clue what would happen if the
   aggregation is done before that -- may be 
   a "don't do that" situation though.

	    Mike