Subject: RE: [NSIS] layer split summary? opinions?

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 29 Jan 2003 15:15:00 +0100

Hi Robert

First of all I would like to mention that I am in favor 
of using (a migrating version of) RSVP as NTLP.
Meaning that NTLP should mainly support the transport 
layer features that are at the moment supported by RSVP, 
while transport layer features that are not supported by 
RSVP should not be supported by the NTLP.

Please see my further comments in line:
>> there seems to be either agreement or at least no disagreement that
>> *) the NTLP shouldn't have much more interesting message types 
>> than 'send data' (i.e. shouldn't have a 'reserve' message for example)

Yes, but a certain message for example could be used for "reserve" 
and "refresh" of a NTLP state and another one for "teardown" of the 
NTLP state.

>> *) the NTLP at one node should be able to use information visible 
>> at 'its' layer to send a message to the next NTLP node, rather 
>> than relying on the upper layer to work out routing

If the way of using this information is similar to the way used by 
RSVP, i.e., path-coupled signaling, then I agree!

>> *) the NTLP shouldn't have concepts of sender or receiver 
>> 'initiation' e.g. of a signaling transaction; it only needs 
>> to discover its peers downstream but may need to be able to send messages upstream as well.
>> (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html 
>> for more details).

Agree!

>> as well as these, there is at least in my head a basic assumption that 
>> traditional transport-layer like functionality (segmentation, congestion 
>> control, all the different aspects of reliability and so on) should be in 
>> the NTLP. On the other hand, some people clearly have doubts about 
>> whether these properties are needed for NSIS signalling at all.

I think that such transport-layer like functions should not 
be a part of the NTLP!
Such functions should be accomplished as much as possible by NSLPs.
NTLP should mainly support the transport layer features 
that are at the moment supported by RSVP, while transport layer features 
that are not supported by RSVP should not be supported by 
the NTLP.

>> there are some more difficult questions, where views diverge more strongly:
>> *) can we assume that NSLP peers are connected by a single NTLP 'hop' or 
>> might the connection run over more than one 'hop' concatenated 
>> together? (not assuming a connection oriented model here, just couldn't 
>> think of a better word.) does this non-end-to-end-ness of the 
>> NTLP restrict what functionality we should attempt to give it?

If we want to develop a flexible NTLP that can be used by different NSLPs
I think that we should allow that the connection between two NSLP peers
runs over more than one NTLP "hop".
 
>> *) should the NTLP provide a state management service to signalling 
>> applications (crudely, should it provide a capability like 'create 
>> some state over there' or should it just provide the capability 'send 
>> some data over there')? some people think 'obviously yes' some think 'obviously no'.
>> (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html)

If we consider that the connection between two NSLP peers
runs over more than one NTLP "hop" then I think that the NTLP should 
be able to provide "NTLP" state management. 
Now regarding the state management service to signaling 
applications, I think that it should be left open.
A signaling application may use either the NTLP state management or 
provide its own state management.

>> *) should the NTLP contain some flow identification information 
>> similar to the 5-tuple or not (for NAT and policy routing reasons)? 
>> the framework currently says yes, but there have been objections.
>> (see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html).

If the NTLP will provide "NTLP" soft state management then I think that 
flow identification and state identification information will be necessary!
Moreover, you need the flow identification to be able to differentiate 
between different signaling applications that are
running on the same node and are supported by the NTLP.

>> In addition, there are things we haven't really discussed at all 
>> yet in the context of layer splitting; in particular, the role (or not) 
>> of the NTLP in scoping where messages are allowed to go, detecting 
>> and handling mobility events, what gets modified to cope with the 
>> path-decoupled case, error and failure condition detection and handling.

Again, NTLP should mainly support the transport layer features 
that are at the moment supported by RSVP while transport layer features 
that are not supported by RSVP should not be supported by 
the NTLP.

Best regards,
Georgios

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Jan 2003 09:30:47 -0500

> RSVP should not be supported by the NTLP.

It would be helpful for the discussion if you could state a technical 
reason for this opinion.