Subject: what is edge signalling? (was: RE: [NSIS] Re: Comments on draft-w estphal-nsis-qos-mobileip-00.txt)

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 3 Jul 2002 16:37:00 +0100

Hi Cedric, Gabor, Hemant, all ...

An attempted response to the edge related questions.

(So far as I can tell, we don't see any mismatch in terms of scope or intention between this and our [individual] NSIS framework i-d; we tried to define a generic model for what has to be done in 5.4 of our draft, and I don't think this solution is any more specific to MIP than that. The main issue might have been the flow classification addresses, but you are assuming CoA like us.)

On the 'edge signalling' case, I guess the main point is that I'm confused about the scope of seamoby CT. Specifically regarding MN-AR signalling (no issue about the AR-AR part):
a) the koodli draft talks about a MN-AR CTIN message to be sent around the time of handover, which I read as the MN saying "please prepare to transfer some context". 
b) your draft talks about an MN-AR CIN message to be sent around the time of flow initiation, which I read as the MN saying "here are the QoS requirements for my flow which I may later want to transfer".

(a) is what I thought CT was restricted to, and our fw considers interworking with such a function (5.3.5). (b) seems to overlap with NSIS end-to-edge case (3.2.3). Have I missed the point? do we expect a host to use different QoS signalling in the special case that it is connected to a CT-capable network (and what if we consider the scenario MN-->MR like in NEMO?) [without me understanding this aspect, i probably can't ask sensible questions about signalling reduction or resource formats.]

cheers,

robert h.

[prior messages - format plain-textified]

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: 02 July 2002 20:40
To: Hancock, Robert
Cc: 'Gabor Fodor'; [email-masked]; [email-masked]
Subject: Re: [NSIS] Re: Comments on draft-westphal-nsis-qos-mobileip-00.tx t

Hi  Robert,

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

Hancock, Robert wrote:

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

[cw]
Hopefully our draft will fit in this framework:-)

[reh]
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.

[cw]
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. 

[reh]
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. 

[cw]
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:-)

[reh]
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.]

[cw]
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.

[reh]
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.

[cw]
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

[reh]
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?

[cw]
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.

[reh]
*) 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?

[cw]
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.

[snip]
========================================================================================
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: Wed, 03 Jul 2002 11:59:15 -0700

Robert,

>(a) is what I thought CT was restricted to, and our fw considers interworking with such a function (5.3.5). (b) seems to overlap with NSIS end-to-edge case (3.2.3). Have I missed the point? do we ex…
Oh, I see. We can go two ways; either [seamoby] goes (b), and then the 
edge signaling can be leverage from them, or [seamoby] goes (a), and the 
edge signaling can be leveraged from there only during handoff, and some 
other signaling should be created for session initiation.

I do believe that a host will use different signaling if it's connected 
to a (pick from: CT-capable/wireless/wired) network. I understand now 
the mention you made yesterday about 'rohc world': well, I understand it 
as, 'is CT a layer 3 problem?' Meaning, do we want to define a QoS 
signaling stack that's the same for all environments, and get modified 
at the link layer, depending on the environment characteristics? Or, to 
get back to your (a) and (b)s: do we want the CT mechanism to acquire 
context the same way say rohc acquires compression state? It's an 
interesting idea, but I'd rather go with (a) personally.

Cheers,

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