Re: Re: [NSIS Mobility draft] Updating from -07 to -08

Hi Jukka,

Jukka MJ Manner wrote:
> Me and Nuutti Varis, our GIST expert, had a chat yesterday and we tried to 
> figure out what could be a good option. I think the problem lies 
> elsewhere, it is not a (QoS) NSLP problem.

Yep. We (Martin Roehricht, Max Laier and me) also discussed mobility
scenarios a lot in the past days and came to the conclusion that it
would be good to solve mobility issues at GIST layer as much as possible
since it is the appropriate place for message routing issues.

> When the IP address does not change (with MIP the e2e BU solves the 
> problem), the point is that even if we would be able to send a message 
> upstream, we still need the routing towards the MN to be in place. There 
> must be some routing protocol in place that sets up e.g. a new host route 
> to the MN when it has moved. This protocol must be coupled with GIST, 
> i.e., GIST must be able to get a notification from a routing change. This 
> would be a cross-over router having the MN state. Once the node gets a 
> hint that the next peer for a MN has changed, it can reissue a RESERVE 
> towards the new path.
> 
> Thus, I would say that we should not invent an NSLP solution to a mobility 
> management protocol issue. We just need to note that GIST must be able to 
> see when routes change, to set up the new route on the downstream.

The problem is that we need some linkage between the data path
and the control path (QoS NSLP). Usually path-coupled signaling
tries to solve this, but if no signaling message for the new
flow is generated, path-coupled signaling would not help. I see the
following setups (assuming that both ends support QoS NSLP):

- Application is mobility-aware and tries to manage mobility itself
  (no use of MobileIP, but e.g., SIP mobility)
  => no problem then because, RESERVE and QUERY message can be generated
  as soon as the MN moves. The CN can be notified by some application
  level signaling protocol.

- MN and CN are using MobileIP and route optimization
  => mobility events should be reported to GIST which in turn should
  notify the affected NSLPs. They can initiate new RESERVE/QUERY
  messages upon such a NetworkNotification. This works for all four
  cases.

- MN uses MobileIP, CN is not using MobileIP or does not support RO.
  => Then the home agent must split the reservations and
  could act upon receiving binding updates by re-initiating
  reservations for the tunnel to the MN as in the previous
  case.

Regards,
 Roland