Subject: RE: [NSIS] mobility-related requirements from nsis-req-08

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 25 Jul 2003 10:20:55 +0100

dear all,

some brief comments (well, brief by my standards anyway):

*) for the sake of my sanity PLEASE don't discuss the reliable 
transport question in this thread. it's confusing enough as it is,
and a totally separate issue.

*) i don't think there has been a formal consensus called on the
'mobility primarily in NSLP' issue/proposal - one reason i posted
my comments in that form (and also raised the issue in all the
recent WG meetings) is to flush out some comments and discussion.
But I think the assumption is that people looking to provide 
explicit support in the NTLP need to (a) define what that support
really is, and (b) explain why the NTLP is a good place to provide
it. There are arguments stretching back over quite a long time
in favour of the 'mainly NSLP' approach, now (if ever) is the
time to challenge them.

*) The idea of of associating flows to a single session is to my
mind a *problem* common to many signalling applications; however,
I expect the *solution* may well not be common. There are two
reasons:
- it is critically dependent on the session id security issue 
(see Hannes' draft) which at the moment is probably NSLP dependent
- what you mean by 'association' is also signalling application 
dependent (do you mean sharing? replacement of one by another? adding
state together somehow? something else?)

*) The next framework will probably broaden the mobility discussion
to include multihoming as well.

*) We know (among the authors of draft-mcdonald-...) that the mobility
handling and session id aspects are not worked out. This will be
picked up as the WG item develops (it will certainly not be addressed
in the first version, however).

*) I don't recall using the term 'universal flow-id'; I was trying to make
the (somewhat informal) point that the NTLP sees the world in terms of
flow-ids and nothing else (a bit like the way a child sees the world
in terms of toys and food and nothing else).

*) I'm not really sure what Xiaoming is suggesting in terms of routing
NSLP messages *other* than on flow-id. The flow-id is essentially
defined as 'the thing which characterises the data path', so routing
on anything else is morally equivalent to off-path signalling. Apart
from anything else, that's currently out scope for NSIS anyway. To take
the concrete example, between the HA and CR, there will be two different
downstream flows and two different upstream flows (and in fact, the CR
may be different between the upstream and downstream flows). The fact that
the two flows within a pair are following the same path is a consequence
of the definition of CR, I'm very opposed to forcing the NTLP to work
out that signalling messages for one CoA should be explicitly routed
the same way as messages for another CoA. You could maybe build an NTLP 
which was tightly integrated with a specific mobility protocol with
this property, but again, that's currently out of scope for NSIS.

cheers,

r.

> -----Original Message-----
> From: Charles Q. Shen [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 09:46
> To: 'Paulo Mendes'
> Cc: 'Xiaoming Fu'; Hancock, Robert; 'Marcus Brunner';
> [email-masked]; [email-masked]
> Subject: RE: [NSIS] mobility-related requirements from nsis-req-08
> 
> 
> Hi Paulo, comments inline.
> 
> > 
> > Hi Charles,
> > 
> > 
> > Charles Q. Shen wrote:
> > 
> > >Hi all,
> > >
> > >We have had a long debate on whether reliable transport (if 
> > applicable) 
> > >should reside in NSLP or NTLP.
> > >
> > Reliable transport in a session protocol, instead of a 
> > transport protocol?!!
> 
> I was referring specifically to the comments such as " 
> [Robert] However,
> even if we agree that a signalling application
> needing reliability needs it between (say) adjacent NSLP peers rather
> than simply end-to-end, there is still the 
> question of which layer it should be provided at (NTLP or within each
> application)." But I have no intention to create more debate on this
> topic :)
> 
> > 
> > >It seems here comes another topic: should
> > >mobility-awareness be built in NSLP only or also in NTLP? 
> I noticed 
> > >that Robert and John have explicited said it should be an 
> NSLP issue 
> > >only. This sparks my curiousity to ask: "Is it already a WG 
> > consensus 
> > >or is it true that many people still haven't got time to 
> think about 
> > >it?"
> > >
> > >IMHO it would be good to make it an NSLP issue only, if possible. 
> > >However, I would like to see more proof as details being 
> worked out. 
> > >(Although it might still be arguable how detail about 
> > NSIS-mobility we 
> > >should get into at this time).
> > >  
> > >
> > I think that avoiding redundant functionalities is a good 
> > goal. Having 
> > this in mind,
> > I think that only makes sense to include within NTLP 
> functionalities 
> > that are common
> > to different NSLPs.
> > In the specific case of mobile session IDs, as said in the 
> framework 
> > draft, it is desirable
> > to update the flow:session mapping during the session 
> > lifetime. If this 
> > mapping
> > is only needed to manage resources of mobile sessions, then 
> it makes 
> > sense to be the
> > QoS-NSLP protocol to keep the mapping info. If this mapping 
> > is required 
> > by other NSLPs,
> > the state should be kept by the NTLP: Henning's NTLP 
> proposal already 
> > mention a forwarding
> > state table that includes the session-ID and the 
> destination address.
> > 
> 
> I think Robert's opinion (from his comments dated 7/17/03) is to let
> NTLP handle "re-routing" only while the association of n flow-id to
> possibly one session id is left to NSLP. The question is then "is this
> association a common function to different NSLPs?" If it is, then it
> seems make sense to me to consider puting it into NTLP as 
> well. Another
> comment is, maybe we should call the topic "the association of flow-id
> with session-id", instead of "mobility", before the former covers more
> than mobility, (eg. Multi-homing?). 
> 
> > >Xiaoming, frankly I do not completely understand your 
> > example yet. Does 
> > >Robert mean that the flow-id (which very likely contains IP 
> > addresses) 
> > >will change after the handoff (and the presumed session ID will be 
> > >retained)?
> > >  
> > >
> > In the framework draft you can read  "A flow is defined by a packet 
> > classifier
> > (in the simplest cases, just the destination address and 
> topological 
> > origin are needed).
> > In general we assume that when discussing only the data 
> flow path, we 
> > only need
> > to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple or 
> > equivalent)." Hence, this clarify that a flow-ID contains IP 
> > addresses, and so the 
> > flow-ID changes
> > when the care-of address of the mobile device changes.
> > In what concerns the session-ID, it must *not* change due to 
> > a handover: 
> > only this
> > way the cross router can be found, the state related to the 
> > flow in the 
> > old path (old flow-ID)
> > can be released, and resources in the common path (from 
> correspondent 
> > node to cross router)
> > can be used more efficiently.
> > 
> > 
> 
> Thanks. I apologize. I should have used "Doesn't" instead of "Does"
> because that is also my understanding.
> 
> > Robert, this lead me to a comment to the QoS-NSLP draft, 
> > where section 
> > 4.3 pays some attention to
> > the need of using session-ID to allow resources to be 
> shared over the 
> > network region where
> > different flows of a mobile session share the path. But, this 
> > section is 
> > lacking some reference
> > to the need of a session-ID to identify the cross router and 
> > to release 
> > resources in the old path.
> > 
> 
> As one possible reference, we tested and proved the concept in our
> RSVP-MIP test-bed 
> http://www.cs.columbia.edu/~charles/publication/draft-shen-nsi
s-rsvp-mob
ileipv6-00.txt

Regards,

Charles

> Cheers,
> Paulo
> 
> >Thanks and regards,
> >
> >Charles
> >
> -- 
> Paulo Mendes
> DoCoMo Communications Laboratories Europe GmbH
> Landsberger Str. 312
> 80687 Munich, Germany
> Tel. +49-89-56824-226
> Fax. +49-89-56824-300
> E-mail: [email-masked]
> http://www.docomoeurolabs.de/
> 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 25 Jul 2003 11:47:33 +0200

Robert,

Thanks for your clarification. I really appreciate a framework view on 
discussions on mobility issues, and agree with you to first explore what 
is necessary for NTLP to support mobility, if needed.

I followed up your previous mail regarding universe flow id because this 
is also (for both you and I) meant how to route the NSIS messages. 
Actually, in a previous version of fw draft it stated either way of 
using flow-id:
     *) Use a flow identification based on low level IP addresses (e.g.
    the Care of Address) and other 'standard' fields in the IP header.
    This makes least demands on the packet classification engines within
    the network. However, it means that even on a part of the flow path
    which is unchanged, the reservation will need to be modified to
    reflect the changed flow identification (see section 5.3.3).

     *) Use a flow identification that does not change (e.g. based on
    Home Address); this is the approach assumed in [23]. This simplifies
    the problem of reservation update, at the likely cost of considerably
    complicating the flow identification requirements.

This can also answer some discussions. My worry, however, is that 
flow-id might be insufficient to address the NSIS messages in mobility 
scenarios, not talking about the mobility-coupled issue; I was trying to 
discuss in the context of decoupling NSIS signaling from MIP signaling.

Hancock, Robert wrote:
> on anything else is morally equivalent to off-path signalling. 

At least I can tell, if we use some on-path LMM schemes (e.g., fast 
handover, HMIP), this flow-id could be insufficient to route NSIS 
messages. In such cases, data path in the new segment(s) may not be 
fully characterized by the flow-id (3/5 tuple?).

Cheers,
Xiaoming