Subject: RE: [NSIS] Review of NTLP proposals

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 14 Jul 2003 08:28:50 +0100

Brian, Henning, all,

Up to now I think we have been discussing multihoming rather implicitly,
as something which - along with IP or higher layer mobility - can cause
the general problem that the relationship between application-layer session 
and [micro]flow to be more than just a simple 1:1 relationship. That's what
the session identifier functionality is about.

However, I don't see that the NTLP should have a role in trying to 'solve'
the multihoming problem, because the correct solution almost certainly 
depends on the demands of the signalling application (at the moment, the
framework assumes that handling IP address change is a signalling application
responsibility, essentially for the same reason). The NTLP should think
in terms of single flows defined by fixed N-tuples, and anything cleverer has to
be pushed upstairs, IMHO.

cheers,

Robert h.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Sunday, July 13, 2003 12:59
> To: Henning Schulzrinne
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Review of NTLP proposals
> 
> 
> Henning Schulzrinne wrote:
> > 
> > Brian E Carpenter wrote:
> > 
> > > Well, Mobile IP is certainly in the set of solutions that 
> don't quite
> > > solve the multihoming problem (excuse the sarcastic tone, 
> but we really
> > > do have a challenge in meeting all the conflicting 
> requirements for
> > > multihoming, hence the churn in the multi6 WG). So there 
> is linkage, but
> > > the scenarios are not isomorphic.
> > 
> > You're extrapolating :-) I wasn't specifically talking 
> about mobile IP,
> > but the general problem that a node changes IP addresses 
> (which mobile
> > IP may then hide from, say, TCP). For example, in some versions of
> > application-layer mobility, there is no mobile IP at all, 
> but rather,
> > changes in IP address are signaled at the application 
> layer. At least
> > with binding updates, the path would change.
> 
> Certainly. SCTP is fun to think about in a multihoming world.
> 
> > 
> > > In any case I think you need to discuss whether crypto overhead is
> > > a significant concern. Also whether IPSEC flows can actually get
> > > useful benefit from an NSIS environment which they can't 
> get from RSVP).
> > 
> > Your comment seems to reflect a view of IPsec as an NSIS 
> *user*; I was
> > thinking of the inverse - NSIS as an IPsec (or TLS) user to 
> protect the
> > upper-layer signaling information from intercept and modification.
> 
> Both ways round are interesting.
> 
>    Brian
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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