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

From: Gabor Fodor <[email-masked]>
Date: Wed, 3 Jul 2002 08:21:30 +0200 (MET DST)

Hi Robert, All,

I apologize if you receive this twice.

------------- Begin Forwarded Message -------------

Hi Robert,

please see some in-line comments :

> -----Original Message-----
> 
> 
> 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.
So from this perspective we probably need to specify how the
westphal-nsis
draft relates to NSIS. Is it so that the draft actually proposes a
specific protocol for the edge and the data path signaling (and also for
the AR-AR case, but that is not NSIS anyway) ?

Once we understand this, and we have a common view on where NSIS should
be with respect to your 3 cases above, we need to re-examine the
proposals in the westphal-nsis draft (and any other solution proposal),
is this correct ?

Then, under the assumption that we go for the "ideal" (i.e. second)
case,
(one of) the issue(s) becomes what we mean with the "same basic
properties".
But in any case, we should definitely avoid the first case.
  
> 
> 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 
Yes, you could, in which case the proposal in the westphal-draft
is one which is (at least in the data path case) a proposal for the
RSVPv2, do I understand this correctly ?

I am not saying it is a good or bad proposal, but we certainly need
to examine a bunch of issues here. Just one example: with RSVPv1
host DS marking is supported by RFC2996 (DCLASS), how is that going
to be in the ICMP based RSVPv2, etc, etc...

> 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.
Yes, in an ideal solution the AR-AR signaling availability could
be seen as an "add on" that improves performance, but even if it
is not available, NSIS does its own job.

NB, it does not mean that the (edge) NSIS and AR-AR will not be
in some respects similar. (That is why I emphasized the importance
of analyzing and comparing the requirements on these two pieces.) 
The more "similar" they are, probably the easier the inter-working
of them will be (in e.g. an AR).

> 
> 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?
As I said, ideally CT would improve performance, but I do not
think that (edge) NSIS should rely on the availability or existence
of it. And since rohc is very important, I think that it should
be used and therefore probably your second alternative is more
reasonable.  

> *) 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?
> 
Very good point, and I currently do not see where that "universe" is
really discussed, are they in the scope of seamoby ? In any case,
to me it looks like that NSIS will probably need to interwork with the
AR-AR
part.

> cheers,
> robert h.

/Gabor

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

------------- End Forwarded Message -------------

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

---

From: [email-masked]
Date: Wed, 3 Jul 2002 10:48:35 -0400

Hi,

-------------------------------------clip---------------------------------------

[Hemant] I think that the features fundamental to all (layer 3) mobility protocols are: (i) somehow layer 3 routing of packets through the network changes, and hence, we need to establish QoS along the new packet path. (ii) The old and new paths can intersect at some crossover router (QC actually) which may be a priori unknown. (iii) Movement of one endpoint may change packet paths in both directions. (iv) QoS must be established ASAP after the node is ready to send packet from the new point of attachment. (v) Security considerations. Any NSIS solution that claims to work with layer 3 mobility needs to address these issues independently (i.e. without relying on the specific features of a particular mobility management protocol). At the same time, NSIS has to address specific featurs of Mobile IP, such as (vi) CoA may change after handoff. (vii) Sensitivity to Mobile IP companion protocols (fast handoff, CT and CARD). This is because, realistically, Mobile IP will be the most (!
only?) dominant layer 3 mobility protocol for the foreseeable future.  

-------------------------------------clip---------------------------------------------
[Hemant] Thanks, Hemant.

/Gabor

---

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

hi,

[snip clip ...]

> [Gabor] Once we understand this, and we have a common view on where 
> NSIS should
> [Hemant] I think that the features fundamental to all (layer 
> 3) mobility protocols are: (i) somehow layer 3 routing of 
> packets through the network changes, and hence, we need to 
> establish QoS along the new packet path. (ii) The old and new 
> paths can intersect at some crossover router (QC actually) 
> which may be a priori unknown. (iii) Movement of one endpoint 
> may change packet paths in both directions. (iv) QoS must be 
> established ASAP after the node is ready to send packet from 
> the new point of attachment. (v) Security considerations. Any 
> NSIS solution that claims to work with layer 3 mobility needs 
> to address these issues independently (i.e. without relying 
> on the specific features of a particular mobility management 
> protocol). At the same time, NSIS has to address specific 
> featurs of Mobile IP, such as (vi) CoA may change after 
> handoff. (vii) Sensitivity to Mobile IP companion protocols 
> (fast handoff, CT and CARD). This is because, realistically, 
> Mobile IP will be the most (!

I can agree with all of this (i)-(v), and in fact i would say (vi) as well is common to most mobility protocols, at least those which have to be able to operate on a macro scale. We have a similar list in our framework document. This means that we have the same views about what data path signalling problems NSIS has to solve.

What I'm not certain about is whether the scope of (vii) is clear, and the extent to which (vii) is Mobile-IP specific. This is why I am confused about the edge signalling part of the proposal.

(This is what I tried to say in a previous email, but possibly in a somewhat opaque way.)

Cheers,

Robert H.

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