Subject: RE: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 2 Jul 2002 10:38:53 +0100

hi Gabor, Cedric, all,

I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been doing.

Background comment: There's an obvious range of choices for us about how much to link an NSIS solution with some mobility scheme. I'd try to summarise the approach we took in our latest framework informally as:
"To use NSIS you have to be using XXX mobility protocols or it won't work" - not OK.
"NSIS can be implemented so it works well with YYY mobility protocols and any others with the same basic properties" - the ideal case.
"You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but not what we're going to look at first.

In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.]

In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't be needlessly different from the wired case, especially from the application perspective. The second is an optimisation, probably intra-domain, and might not even be implemented (or might fail). So, my dream solution would be to have an NSIS protocol which provided an MN-AR component which always worked, but which worked better if a separate AR-AR protocol (not part of NSIS) was available. We started the discussion in this direction in 5.3.5 (of draft-hancock-nsis-fw-00); so far as I can tell, the conceptual model is rather different from the one here, even if it's just an issue of which protocol owns which messages.

In case this all comes across as wildly vacuous, here are two lesser but concrete questions:
*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the compression to use CT if available, invisibly to NSIS?
*) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be inevitable?

cheers,

robert h.

> -----Original Message-----
> From: Gabor Fodor [mailto:[email-masked]]
> Sent: 01 July 2002 18:32
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] Re: Comments on
> draft-westphal-nsis-qos-mobileip-00.txt
> 
> 
> Hi Cedric, 
> 
> Thnaks for your answers, I would like to discuss
> one of your points here, which I believe
> is important:
> 
> [...]
> 
>  
> > 
> > [GF]
> > 4
> > I am not sure that it is meaningful at this point to start
> > discussing specific solution approaches. You seem to propose
> > to use ICMP as a design base for both edge signaling and for
> > context transfer (AR to AR). At least for the edge signaling,
> > we need to consider the edge specific requirements before
> > we start discussing what existing or new protocol can be the
> > design base for that.
> > [GF]
> 
> > Let me explain a bit here: the design base for edge signaling and
> > context transfer is
> > really 'A context transfer protocol for seamless mobility',
> > draft-koodli-seamoby-ctv6-03.txt.
> > Earlier version of draft-koodli-seamoby-ctv6 were ICMP 
> based. However,
> > it is more general in this latest version, and not 
> necessarily ICMP. As
> > a consequence, we mention ICMP
> > as a possible illustration. The main point is that QoS signaling is
> > redundant with context transfer, one object being 
> transferred being QoS
> > context, and that CT signaling will do the job for the MN to AR QoS
> > signaling. 
> > We will clarify this point.
> 
> [GF]
> We need to understand and analyze better the requirements on the edge
> and the CT signaling protocols. You make a good point : the 
> QoS signaling
> is to a great extent redundant with context transfer 
> (which makes the re-use of the same design attractive), but there
> may as well be important differences that are connected to the
> wireless interface itself. I believe that there are scenarios where
> transferring the context from AR1 to AR2 is not sufficient to exercise
> admission control at and make the mecessary configurations of the new
> wireless link. I think we need to list the requirements for the edge
> protocol and go check how those are fulfilled 
> with differenet alternatives.
> [GF]
> 
> /Gabor
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Cedric Westphal <[email-masked]>
Date: Tue, 02 Jul 2002 12:39:44 -0700

Hi  Robert,

I added Hemant to the cc:-list. I'll give my best shot at answering your 
comments.

>I'd like to throw in some cents from a frameworker's perspective, about the basic approaches to 'data path' and 'edge' signalling, and how this draft might relate to the framework stuff we have been…
thanks. Hopefully our draft will fit in this framework:-)

>"You can build an integrated locally-applicable protocol which does the job of NSIS and some aspect of mobility management and fits into the rest of the NSIS framework" - logically conceivable but n…
Our attempt in this draft was to present a somewhat restricted 
framework: QoS establishment for e2e can be down with existing tools 
(RSVP + slight modifications); edge signaling (for establishment or 
during handoff) can be done with tools under construction (context 
transfer); so NSIS should focus on the QoS re-establishment after a 
handoff. So our main working assumption is to deal with mobility.

How to deal with mobility? I agree with you that "NSIS can be 
implemented so as to work well with YYY mobility protocols and other 
with the same properties". So the question is to figure out what set of 
properties the protocol YYY and others have that are of interest for 
NSIS. The mobility protocols used in our proposal are mobile IP and 
context transfer.

There is little dependence on MIP in our framework. The second one is 
somewhat redundant with NSIS, and there has been a thread on this list 
cross-posted on seamoby about it.  We suggest that as CT
and NSIS share the same properties on the edge (CT by signaling which 
QoS context should be transfered, and nsis by signaling QoS itself), 
NSIS has no need signaling over the air interface whenever CT is 
available. However, as your first statement suggests, "Use NSIS with CT 
or it won't work" is unacceptable, as CT is not always successful or 
available.

>
>
>In the data path case, we tried to state what were the requirements for NSIS signalling, regardless of what data path update (mobility) solution was used. So far as I can tell, the solution here would fit with that - in other words, you could make it part of NSIS without restricting oneself to Mobile IP as the only supported mobility mechanism. 
>
The update on the data path is pretty much independent of mobility 
protocols. Let me state why: the trigger is a message independent of the 
mobility protocol. The mechanism to identify the crossover router is 
also independent of the mobility protocol, but based on the QoS session 
id jointly with a flow filter. I haven't looked at the details, but I 
would think it could be not based on Mobile IP. However, I for one want 
to make sure that it works well with MIP:-)

>That's important, since the crossover router could be anywhere in the Internet, so it's hard to make the selection of the approach to path update handling a local choice. I'd be happy to have this impression confirmed (since the title of the draft gives the opposite impression, and it may be that I'm missing something). [NB I have other questions about the data path component, which I find very interesting, but they're one level of detail further down, so I'll ask them separately.]
>
The title expresses the incremental approach we  considered. I think if 
you can get something to work with MIP (without dependencies) then MIP 
is general enough in principles to extend it to other mobility. I admit 
not having examined other mobility solutions, even though it seems to me 
we did not lose generality by assuming MIP as mobility.

>In the 'edge' case, I think we should draw a clear line between MN-AR signalling and AR-AR signalling. The first is required in all cases, probably crosses a domain boundary, and (I think) shouldn't…
Don't you think that the MN-AR signaling changes if there is an AR-AR 
signaling?
It does change as CT will add its own signaling to trigger the AR-AR 
signaling (which
contexts are transfered and such). I agree on the other hand that if no 
AR-AR signaling is available (not implemented/failure) then the MN-AR 
should be aware/able to recover

>*) should we rely on CT supporting NSIS directly to do over-the-air signalling reduction, mainly at handover? or should we rely on something from the rohc world as a general solution, and allow the…
First, by 'rohc world', do you mean some 'resource signaling protocol 
compression'?
I think we have to look back to the thread with seamoby. But my 
impression was that
seamoby would do QoS ct independently of NSIS, and that NSIS was not 
taking up redundant work with theirs.  As such, I'd use the first 
solution whenever CT is available.
The signaling compression interworking with CT is a neat idea, but seems 
much more difficult.

>*) is it useful if the [opaque] resource descriptions (NSIS fw term) and QPT/QoS object (draft-westphal-... terms) come from the same universe? or do we accept that interworking these is going to be…
Well, the terms are from draft-koodli-seamoby-ct-03.txt.
[seamoby] is chartered to define context transfer protocol for QoS, and 
NSIS will not
recreate anything new there. So interworking these is not inevitable, 
but should be the primary choice.
Thanks for your comments,

Cedric.

>------------------------------------------------------------------------
>
>The information contained in this e-mail and any attachments is confidential to Roke 
>Manor Research Ltd and must not be passed to any third party without permission. This 
>communication is for information only and shall not create or change any contractual 
>relationship.
>