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

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 7 Dec 2007 00:14:42 +0200 (EET)

Hi Roland,

I'm finally trying to figure this thread. :)

See one comment below.

Jukka

On Thu, 15 Nov 2007, Roland Bless wrote:

> Hi Jukka,
> 
> [I'm taking this to the list now...]
> 
> Jukka MJ Manner wrote:
> > I think we are talking about the same thing. The main point is that if IP 
> > addresses change, the MRI is invalidated, and the QNI must then, in one 
> > way or another be notified. There must be (otherwise nothing works) some 
> > mobility signaling where the QNI gets to know the new IP of the MN, and 
> > can then reissue a RESERVE with a new MRI.
> 
> Ok, however, I believe that your proposed solution doesn't work:
> you proposed to send a NOTIFY towards the CN. This will require usage
> of the new flow's MRI and the resulting GIST Query must be sent in
> _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream.
> Now there is the problem of choosing the correct encapsulation for the
> Query: only _upstream_ Q-mode encapsulation would be an option, but this
> is not appropriate to use in this case due to its limited applicability
> to certain environments. Even if the MN could send the NOTIFY to its
> new access router (QNE4 below), there is no routing state installed yet
> in upstream direction in QNE4, i.e., it doesn't know any next peer
> in upstream direction, so only upstream Q-mode could be used, but that
> is not really applicable in this case. So only the last paragraph of
> section 4.3.3 applies:
>    o  If no routing state exists, GIST can attempt to use Q-mode as in
>       the Query case: either sending a Data message with the Q-mode
>       encapsulation, or using the event as a trigger for routing state
>       setup (see Section 4.4).  If this is not possible, e.g. because
>       the encapsulation for the MRM is only defined for one message
>       direction, then this is an error condition which is reported back
>       to the local signalling application.
> 
> So an error will be reported back to the application.
> As a conclusion: sending a NOTIFY in upstream direction does not
> work along paths that have no routing state yet.

[JM]: If the CN requests reliable or secure transport, GIST will send an 
empty Query to the next, set up routing state, and only then send the 
NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in 
question, so should it send an error back, or forward the message in the 
same way towards the CN? 

[JM]: Yet, also with unreliable/unsecure transport, what would happen, if 
QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it 
doesn't know about, so it could as well forward the message further, 
right? The message will eventually hit a QNE (or eventually the CN), who 
then knows about the SID.

> 
> > The asymmetric paths is a real problem, especially if the MN switches e.g. 
> > interface technologies, goes from WLAN to WiMAX, and changes operators at 
> > the same time. In that case the QUERY will hit some node, the QNI at the 
> > latest, which can then send the RESERVE towards the new location of the 
> > MN.
> 
> We will come back later with more detailed comments about the mobility
> scenarios.
> 
> Regards,
>  Roland & Martin (Roehricht)
> 
> > 
> > Jukka
> > 
> > On Fri, 9 Nov 2007, Roland Bless wrote:
> > 
> >> Hi Jukka,
> >>
> >> see comments below.
> >>
> >> Jukka MJ Manner wrote:
> >>>> <snip>
> >>>>> [MN]   [QNE1] --- [QNE2] ---\
> >>>>>  |                           \
> >>>>>  |                           [QNE3] --- [QNE6] --- [QNE7] ---
> >>>>>  |                           /
> >>>>>  V                          /
> >>>>> [MN]   [QNE4] --- [QNE5]---/
> >>>>>
> >>>> <snip>
> >>>>> - MN moves, gets a hint from GIST that routing has changed
> >>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02
> >>>>> - QNE4 will receive it, and forward it, same with QNE5
> >>>>> - The NOTIFY will hit QNE3, which notes that the message for a known 
> >>>>>  session comes from a new SII-Handle.
> >>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to 
> >>>>>  QNE5
> >>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it
> >>>>> to the MN
> >>>>> - The MN gets the RESERVE and replies with a RESPONSE
> >>>> - In order to send NSIS message hop by hop for upstream direction (MN->
> >>>> QNE4->...->QNE7... in the figure below), GIST state need to be
> >>>> established in advance, and this GIST state is established for
> >>>> downstream direction (e.g., QNE3 aware of route change and perform route
> >>>> change process towards MN in the new location). But if this is possible,
> >>>> I guess "make it faster" operation (operation above) does not make sense,
> >>>> because QNE3 (CRN) will able to do new reservation and teardown without
> >>>> receiving NOTIFY from MN.
> >>>> - How MRI update can be done in this case?
> >>>
> >>> In order for the MN to send the NOTIFY, each GIST hop will need to set up 
> >>> state upstream. This state establishment will result in a QUERY hitting 
> >>> QNE3, which will decide to peer. The SID is known, thus, the QNE3 will 
> >>> consider this a re-routing event, and perform the signaling as above. This 
> >>> should work? QNE3 will not know about the re-routing until QNE1 figures 
> >>> out the MN has disappeared, and QNE1 starts tearing down the reservation.
> >> Sorry, but I don't get the point here and I doubt that its working
> >> correctly. what is the exact scenario?
> >>
> >> - MN is QNR and data receiver?
> >> - Reservation is sender-initiated?
> >> - MN uses Mobile IP?
> >>
> >> I see the different cases now:
> >> a) MN gets a new IP address and default route
> >> b) MN performs mobility management signaling (Bindung Update)
> >>
> >> Is it that GIST will already detect a route change by a)
> >> or will the route be changed by b)?
> >>
> >> With the current proposal I have the following issues:
> >> * In case of a) it may be the case that QNE3 is not even hit by a Query
> >>   sent upstream due to asymmetric paths.
> >> * The MRI must get updated along the whole path, especially for
> >>   profile update in the first hop router at the QNI.
> >> * QNE3 tries to automatically reserve resources as they were before the
> >>   handover. This is especially inappropriate in case of vertical
> >>   handovers when the QSPEC should be changed. Therefore it would be good
> >>   that the QNI is involved in re-issuing a RESERVE.
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 7 Dec 2007 00:26:21 +0200 (EET)

Hi Roland, Hong, Takako,

What you are discussing is the case of MIP, and sure, here the binding 
update helps as the upstream trigger. But if we do not employ MIP? What 
about mobility within a local domain without MIP. In such a case, the MN 
IP will not change, but we need the upstream trigger to set up the 
signaling path efficiently. In that case, the upstream NOTIFY is our only 
help, I'd say.

(In this scenario, the IP address could actually change, too, and we use 
e.g. SIP to re-bind the session and data streams. This comes back to the 
MIP case, though - some e2e signaling exists to provide a new IP address 
of the MN, and this would be coupled somehow with the NSIS protos.)

rgs,
Jukka

On Fri, 16 Nov 2007, Roland Bless wrote:

> Hi Hong, Takako and all,
> 
> we were writing up another e-mail, but I guess your analysis is
> mostly correct. I'll try to summarize our (Martin and I) comments
> as follows:
> 
> We (Martin an I) have some major comments about the draft and are
> willing to contribute to it.
> First, we find that we basically should distinguish four cases:
> 1.) MN is sender, sender-initiated reservation
> 2.) MN is sender, receiver-initiated reservation
> 3.) MN is receiver, sender-initiated reservation
> 4.) MN is receiver, receiver-initiated reservation
> 
> It seems that only case 1.) is currently discussed in section 4
> and we think it would be good to systematically discuss
> the other cases, too.
> 
> In case that MobileIPv6 is used it boils down to
> the following cases as Hong described already. We assume
> that the MN changes its address and the we distinguish
> two flows:
> cases 1.)+2.) (MN-Sender)   f_o: old-CoA -> CN, f_n: new-CoA -> CN
> cases 3.)+4.) (MN-Receiver) f_o: CN -> old-CoA, f_n: CN -> new-CoA
> 
> Case
> 1.)
> - MN changes its IP address, obtains new-CoA
> - QoS NSLP must become aware of the handover, so that the
> - MN simply initiates a new RESERVE for the new flow f_n
> 
> 2.)
> - MN changes its IP address, obtains new-CoA
> - QoS NSLP must become aware of the handover, so that the
> - MN initiates a new QUERY(RESERVE-INIT) for the new flow f_n
> 
> 3.)
> - MN changes its IP address, obtains new-CoA
> - MN performs mobility management signaling, i.e. binding update
>   to the CN.
> - CN becomes aware of the handover (this is the important part)
>   so that the NSLP can initiate a new RESERVE.
> 4.)
> - MN changes its IP address, obtains new-CoA
> - MN performs mobility management signaling, i.e. binding update
>   to the CN.
> - CN gets aware of the handover, NSLP sends a new
>   QUERY
> 
> The important part for all four cases is that
> the QoS NSLP becomes aware of the handover. There
> are several possibilities for the trigger, but I
> think we should use a new GIST API primitive for
> the notification (but probably as mobility extension
> of GIST not within the current proposed draft).
> You wrote that GIST will trigger the NSLP,
> but I don't think that there is currently such
> a possibility:
> new binding update actually changes an existing flow
> f_o into the new f_n. So the only existing primitive
> would be to indicate
> NetworkNotification(QoS-NSLP, MRI(f_o), Routing-Status-Change=Bad)
> for the old flow. But we need to get the new MRI
> in order to send the NSLP message. One problem is that
> GIST doesn't have any state for the new flow f_n.
> So I would propose to have a new NetworkNotificationType,
> like MRI change:
> NetworkNotification(QoS-NSLP, MRI(f_o), MRI(f_n))
> The problem is, however, that an updated IP address
> (due to mobility management) may affect several GIST
> flows.
> 
> An alternative would be a trigger caused by the
> application itself, e.g., due to application level
> signaling. It would be similar to the fact that
> we need such a trigger anyway for receiver-initiated
> reservations in order to let the sender issue an initial
> Query. I guess we need to support both possibilities
> for cross layer info.
> 
> Concerning your mentioned option of directly sending
> a NOTIFY to the other end: that's also an alternative
> that I discussed with Martin. Our proposed EST-MRM
> would probably enable a node to do so, i.e., a NOTIFY
> indicating a handover event could be sent directly
> to the other end.
> 
> Now for some further comments to the draft:
> 
> Further comments on section 4.2:
> I propose to change the name of "State Update"
> at least to "Localized State Update", because
> my intuitive understanding of State Update is
> that is denotes the process to update the flow's state
> along the whole path.
> 
> With respect to section 4.2.1 we want to remark that
> usually the main difference between mobility/handover
> scenarios and re-routing as describe in appendix A is:
> in the basic mobility scenario the MRI changes: the
> MN gets a new care-of-address and thus we have a new flow
> (we denote this as f_n). In contrast to this, a re-routing
> by route changes will usually not lead to a change of
> the MRI. So normally only the CRN can determine at
> NSLP level that a handover happened by detecting two
> different MRIs (f_o=old flow and f_n=new flow) belonging
> to the same SID. GIST does not really care about the SID,
> so this relation must be handled at the NSLP
> level.
> 
> Furthermore, I would propose to rephrase the last
> paragraph of section 4.2.3 as QoS NSLP does not allow
> to sent RESERVEs towards the QNI. Thus, there is no
> option to do it differently.
> 
> Best regards,
>  Roland and Martin
> 
> Hong Cheng wrote:
> > Hi Roland and Jukka,
> > 
> > This seems like some interesting discussion that should be used to
> > update the MIP operation part in the draft.
> > 
> > Based on the description, I don't think a NOTIFY from MN is necessary
> > when the other end (CN or HA) is a QNE.
> > 
> > When MN is the Data Sender, it should work this way:
> > - MN changes its IP addr, e.g. obtain a new-CoA;
> > - MN sends a QUERY(RESERVE-INIT)towards the CN/HA with the new MRI (if
> > it's QNR); or
> > - MN sends a RESERVE towards the CN with the new MRI (if it's QNI)
> > 
> > When MN is the Data Receiver, and the CN/HA is a QNE, it should work
> > this way:
> > - MN changes its IP addr, e.g. obtain a new-CoA;
> > - MN does Mobility Management signaling to inform CN/HA of new-CoA
> > (otherwise data path would not change, remember CN/HA is the data sender);
> > - CN/HA is triggered by GIST to send QUERY towards MN using new MRI;
> > - MN sends RESPONSE (if it's QNR) or RESERVE (if it's QNI); and
> > - CN/HA sends RESERVE if it is QNI.
> > In the above step 3, CN/HA sends QUERY instead of RESERVE directly(if
> > CN/HA is QNI) because the path condition may change as MN changes
> > location (as indicated in your earlier email, WiFi and WiMAX may
> > provides different throughput). However, if time is a concern, CN/HA can
> > always use back the old QSPEC for a direct RESERVE first.
> > 
> > The situation will become a bit more interesting when the CN/HA is not
> > QNE. In this case, how the MN does the update worth some discussion.
> > 
> > If MN is the Data Sender, same operation as above should be able to work.
> > 
> > If MN is the Data Receiver, there are problems in signaling as indicated
> > in Roland's email, especially when we assume the routing is asymmetric.
> > There are two possible ways:
> > - If MN knows the QNI/QNR addr, it can send a NOTIFY/QUERY directly to
> > it. However, in the current QoS NSLP spec, there is no way for the MN to
> > know that info. Should we fix this, e.g. as a special mobility/proxy
> > INFO-Element?
> > - Get some help from the CN/HA (the data sender). Possibly to
> > encapsulate the NOTIFY to CN/HA, and get them to send it via Data Path.
> > This is like sending a special PING to the CN/HA.
> > 
> > What do you think?
> > 
> > 
> > Roland Bless wrote:
> >> Hi Jukka,
> >>

---

From: Roland Bless <[email-masked]>
Date: Fri, 07 Dec 2007 16:17:26 +0100

Hi Jukka,

see comment inline.

> [JM]: If the CN requests reliable or secure transport, GIST will send an 

I don't know what it has to do with reliable and secure transport?

> question, so should it send an error back, or forward the message in the 

Please read the above text again. The problem lies in the fact that
you have to send a GIST-Query _upstream_ and no routing state exists
yet. So even if an MA exists, it cannot be used.
This could only be done with _upstream_ Q-mode encapsulation, but this
is definitely not applicable in a general way.

> then knows about the SID.

See above. The GIST Query has to find its way first. This is the real
problem.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 15 Dec 2007 15:15:08 +0200 (EET)

Hi,

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.

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.

rgs,
Jukka

---

From: Hong Cheng <[email-masked]>
Date: Mon, 17 Dec 2007 11:49:41 +0800

Hi Jukka,

Generally, I would agree with you that the NSLP should not be used to
replace the mobility management protocol.

Regarding your analysis, I would like to clarify some points. Please see
 inline:

Jukka MJ Manner wrote:
> When the IP address does not change 

[Cheng] I think this is a different scenario than what we were
discussing earlier. The case seems more of a re-routing issue than a
mobility issue (which belongs to a different section). GIST should have
dealt with the normal re-routing case. In case there are other protocols
involved, different considerations would apply (see below).

> (with MIP the e2e BU solves the problem),

[Cheng] The MIP BU should solve the routing aspect of the problem.
Possible NSIS operation sequence has been detailed in several earlier
emails. However, as Roland pointed out, the description in the draft
might be insufficient about the NSIS mechanism, e.g. the GIST API to
inform NSLP of the new MRI after change of MIP Binding Cache, etc.

> the point is that even if we would be able to send a message 

[Cheng] Can you share a bit more on what is the use case/scenario you
have in mind? (when MN moves but IP address does not change) Usually, to
achieve this, some sort of tunneling needs to be used, e.g. network
based local mobility management. If this is the case, the nodes involved
would be totally different, and the analysis should also be different.
It does not have to be the crossover router that issues the RESERVE. The
tunnel signaling interaction must be considered here as well.

cheers

Cheng Hong

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 17 Dec 2007 21:10:20 +0200 (EET)

Hi,
a few answers below.

Jukka

> inform NSLP of the new MRI after change of MIP Binding Cache, etc.

[JM]: This may be so, I haven't thought about how the GIST API fits with 
MIP. I trust Roland that there is a problem.

> tunnel signaling interaction must be considered here as well.

[JM]: You could per-host forwarding within a local domain based on 
tunnels, or you could update just per-host routes in the domain routers. 
Both have their interactions with GIST. I don't think we should try to 
figure out all possible local (micro) mobility schemes and see how they 
would work. Just the general considerations are enough, IMO.

---

From: Roland Bless <[email-masked]>
Date: Wed, 19 Dec 2007 15:58:36 +0100

Hi Jukka,

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

> 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