Subject: [NSIS] Layer split issues

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 28 Nov 2002 13:42:40 -0000

Dear all,

Following the NSIS session in Atlanta, I'd like to stimulate further discussion (and maybe agreement??) on some of the issues around where the NTLP/NSLP boundary should actually go.

It seems to me there are 
1) some options on which there is some agreement
2) some options on which there is some disagreement
3) some options we haven't really discussed yet or at least not properly.

This email is an attempt to summarise (1) (i.e. find out whether I have read the mood right). Separate emails will cover some of the topics under (2). 

[I think (3) includes some real headaches (e.g. mobility handling/reservation identifiers, security attributes, coupled/decoupled aspects) which can reasonably be postponed before (1) and (2) are clearer.]

Message Types
=============

I think we can make a working assumption that the NTLP basically provides a capability like 'send data', without associating that data with creating a reservation, querying something, releasing resources, or whatever. The 'send data' message can go with or against the data flow, and only goes between NTLP peers.

Is this valid? [There may be different variants of 'send data' depending on whether the NTLP can do state management stuff, I'm not prejudging that here.]

[NB. There are potentially confusing comments within the framework about how much the NTLP and NSLP could be coupled/not properly independent layers. This is a historical overhang from when we used to think that the NTLP would have a richer message set. If the NTLP has only a very simple message set, these issues would go away.]

Path Management
===============

What was discussed/not objected in the framework session was (roughly) the assertion that the NTLP processing at each NSIS entity should include getting to the next NTLP peer, and that the NTLP should detect and maybe do something about path changes ("do something" may just be "tell the NSLP it's happened".)

Left to its own devices, the NTLP would then implicitly construct the whole path (although I would content this shouldn't be described as giving the NTLP end to end capabilities). But the NSLP at any node is free to interfere however it wants anyway.

I like this because it puts a large number of hard but signalling application independent, transport and lower layer issues inside the NTLP where they can be solved once. But I think there may be other views as well. Arguments?

Sender/Receiver Issues
======================

The proposal (actually in an individual submission) is that, in so far as the NTLP has 'directionality':
a) it only needs the functionality to get to the next NTLP peer in the sender-->receiver direction (might be called 'sender oriented')
b) by default, it should be able to send its 'data' messages either direction, but as an optimisation, some signalling applications might only ask to send them sender-->receiver.

However, we shouldn't make any restrictions on how (i.e. from which end) any NSLP should trigger the signalling process, request/authorise something, or whatever. In other words, NI and NR are NSLP concepts.

I haven't heard counter-proposals, but the assumption is partly contingent on the path management assumption (so I'm asking).

Is this a reasonable starting point?

Cheers,

Robert H.

(Later, under (2), we get to state management and flow identification, where there are clearly interesting divergences of view.)
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis