Subject: [NSIS] general comment on tunnel handling (was: RE: mobility-related req uirements...)

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 28 Jul 2003 16:26:49 +0100

Dear all,

I thought I'd make a general comment on assumptions about tunnel 
handling in NSIS. Although these assumptions have been mentioned
randomly from time to time, they aren't [yet] documented anywhere,
and probably should be made explicit.

The basic assumption is that if some node in the network
is encapsulating IP packets (for some flow) and sending them to 
a remote tunnel endpoint inside a tunnel, then the 'default' state of 
affairs is that any signalling traffic for that flow is encapsulated
and tunnelled to the same endpoint. If you want to signal about the
tunnel, that means that the tunnel origin (ideally, both endpoints)
have to be NSIS-aware and that they generate logically separate 
signalling for the tunnel (i.e. the tunnel is a new flow).

I've been not worrying about this assumption very much because it
seems to be 'natural' given the way the rest of the framework is
described, and also conceptually the same as RSVP tunnel handling 
(RFC2746). Obviously there are details about which layer of NSIS
should carry information binding inner flows to outer tunnels, if
that information needs to be carried, which I think can be left open
for now.

If there are objections to this view, please say so (and why).

cheers,

robert h.

> -----Original Message-----
> From: Xiaoming Fu [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 11:19
> To: Charles Q. Shen
> Cc: [email-masked]; Hancock, Robert; Paulo Mendes
> Subject: Re: [NSIS] mobility-related requirements from nsis-req-08
> 
> 
> Charles,
> 
> > 
> > Again I am a bit confused about the notion of universe 
> flow-id and the
> > (supposed to be unique) session ID here. 
> I think Robert's concept on *universe* flow-id doesn't need to be 
> unchanged during a session; if I understand correctly, he only meant 
> "universe" for signaling session at one time.
> 
> > Also are you talking about tunneling?
> 
> So far in this thread, not yet. However, in my view, IP-in-IP 
> tunneling 
> is an important issue for NSIS-mobility to work out. Re-routing and 
> local repair issues in the data path changed by mobile IP may 
> introduce 
> problems other than (routing header + destination option in case of 
> MIPv6) - imagine what if a message is encapulated into tunneled :-); 
> reverse tunneling could be more complicated. My ideal model 
> is that NTLP 
> should be aware of any tunnel entry and exits, and route NSIS message 
> when entering and inside a tunnel differently from the case 
> outside the 
> tunnel.
> 
> Cheers,
> Xiaoming
> 

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