Subject: [NSIS] another attempt on NTLP peer-peer definition

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Feb 2003 09:29:18 -0000

dear all,

Having read the mails on the 'consensus probe' thread, and absorbed the ones relevant to the original question, here is a revised attempt on the same subject:

It's clear that the signalling exchanges considered by NSIS can go a long way across a network, visiting a sequence of NSIS entities (NEs). The protocol stack carrying the signalling is divided into a common layer (the NTLP) and signalling application specific layer (an NSLP).

============================================================================================

It is a working assumption that the protocol mechanisms of the NTLP operate only between adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger scope issues (including e2e aspects) are left to the upper layers.

When a signalling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path (up- or down-stream), where it is received and the responsibility of the NTLP ends. Note that there is no constraint on whether the message is sent directly addressed to the next NE, or addressed to the flow endpoint and intercepted along the path; both addressing models are possible and necessary in some circumstances, and the details are left to the protocol design stage. The key point is that the NTLP at a given NE does not use any knowledge about addresses/capabilities/status/etc. of any NEs other than its direct peers.

The receiving NE may decide to forward the message directly, invoking the NTLP again; or, it may give the message to a signalling application for further processing which then generates another message to be sent via the NTLP. In this way, larger scope (including end-to-end) message delivery can be automatically achieved.

This definition relates to NTLP operation. It is not intended to restrict the abiliity of an NSLP to send messages by other means. For example, an NE in the middle or end of the signalling path could send a message directly to the other end as a notification of or acknowledgement for some signalling application event. However, it appears that the issues in sending such messages (endpoint discovery, security, NAT traversal and so on) are so different from the direct peer-peer case that there is no benefit in extending the scope of the NTLP to include such non-local functionality; instead, an NSLP which requires such messages and wants to avoid traversing the path of NEs should use some other existing transport protocol - for example, UDP would be a good match for many of the scenarios that have been proposed.

=============================================================================================

OK, there hasn't been much discussion on the proposal in the final paragraph. However, my impression is that the people who want to use such notifications don't want to use any interesting functionality in the NTLP anyway, so something simple like plain UDP would be 'good enough' for them. In any case, splitting this from the rest of NTLP requirements seems reasonable to me - any other views?

(One motivation for looking only at the hop-by-hop functionality as a single protocol is that if there are any options or variants in design approach - or, worse, in basic functionality - it is easier to manage the resulting complexity if it only impacts direct peers rather than potentially the whole network. It also makes it easier to deploy new versions. Obviously we'd rather get it right first time and with no options, but I'm somehow sceptical that that's possible...)

Cheers,

Robert H.

PS this seems to be a simple concept, so why does the definition have to be so long? Better words possible?
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 25 Feb 2003 10:39:05 +0100

Hi Robert

Regarding the following paragraph:
"Note that there is no constraint on whether the message is sent 
directly addressed to the next NE, or addressed to the flow 
endpoint and intercepted along the path; both addressing models 
are possible and necessary in some circumstances, and the 
details are left to the protocol design stage."

Are you denoting the addressing model where the message is sent 
directly addressed to the next NE as peer-to-peer addressing
and the addressing model where is addressed to the flow 
endpoint and intercepted along the path as end-to-end 
addressing?

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: dinsdag 25 februari 2003 10:29
To: [email-masked]'
Subject: [NSIS] another attempt on NTLP peer-peer definition

dear all,

Cheers,

Robert H.

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Feb 2003 09:45:55 -0000

georgios,

indeed this is the terminology that the framework uses (in the -01 version in section 3.3.4, although we know that numbering will change soon...)

i tried to write the email so it was a bit more self-explanatory.

r.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 25 February 2003 09:39
> To: Hancock, Robert; [email-masked]'
> Subject: RE: [NSIS] another attempt on NTLP peer-peer definition
> 
> 
> Hi Robert
> 
> Having read the mails on the 'consensus probe' thread, and 
> absorbed the ones relevant to the original question, here is 
> a revised attempt on the same subject:
> 
> It's clear that the signalling exchanges considered by NSIS 
> can go a long way across a network, visiting a sequence of 
> NSIS entities (NEs). The protocol stack carrying the 
> signalling is divided into a common layer (the NTLP) and 
> signalling application specific layer (an NSLP).
> 
> It is a working assumption that the protocol mechanisms of 
> the NTLP operate only between adjacent NEs (informally, the 
> NTLP is a 'hop-by-hop' protocol), whereas any larger scope 
> issues (including e2e aspects) are left to the upper layers.
> 
> When a signalling message is ready to be sent from one NE, it 
> is given to the NTLP along with information about what flow 
> it is for; it is then up to the NTLP to get it to the next NE 
> along the path (up- or down-stream), where it is received and 
> the responsibility of the NTLP ends. Note that there is no 
> constraint on whether the message is sent directly addressed 
> to the next NE, or addressed to the flow endpoint and 
> intercepted along the path; both addressing models are 
> possible and necessary in some circumstances, and the details 
> are left to the protocol design stage. The key point is that 
> the NTLP at a given NE does not use any knowledge about 
> addresses/capabilities/status/etc. of any NEs other than its 
> direct peers.
> 
> The receiving NE may decide to forward the message directly, 
> invoking the NTLP again; or, it may give the message to a 
> signalling application for further processing which then 
> generates another message to be sent via the NTLP. In this 
> way, larger scope (including end-to-end) message delivery can 
> be automatically achieved.
> 
> This definition relates to NTLP operation. It is not intended 
> to restrict the abiliity of an NSLP to send messages by other 
> means. For example, an NE in the middle or end of the 
> signalling path could send a message directly to the other 
> end as a notification of or acknowledgement for some 
> signalling application event. However, it appears that the 
> issues in sending such messages (endpoint discovery, 
> security, NAT traversal and so on) are so different from the 
> direct peer-peer case that there is no benefit in extending 
> the scope of the NTLP to include such non-local 
> functionality; instead, an NSLP which requires such messages 
> and wants to avoid traversing the path of NEs should use some 
> other existing transport protocol - for example, UDP would be 
> a good match for many of the scenarios that have been proposed.
> 
> OK, there hasn't been much discussion on the proposal in the 
> final paragraph. However, my impression is that the people 
> who want to use such notifications don't want to use any 
> interesting functionality in the NTLP anyway, so something 
> simple like plain UDP would be 'good enough' for them. In any 
> case, splitting this from the rest of NTLP requirements seems 
> reasonable to me - any other views?
> 
> (One motivation for looking only at the hop-by-hop 
> functionality as a single protocol is that if there are any 
> options or variants in design approach - or, worse, in basic 
> functionality - it is easier to manage the resulting 
> complexity if it only impacts direct peers rather than 
> potentially the whole network. It also makes it easier to 
> deploy new versions. Obviously we'd rather get it right first 
> time and with no options, but I'm somehow sceptical that 
> that's possible...)
> 
> Cheers,
> 
> Robert H.
> 
> PS this seems to be a simple concept, so why does the 
> definition have to be so long? Better words possible?

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 25 Feb 2003 10:58:14 +0100

Hi Robert

Okay, I think that we are using then the same definitions.
Now regarding NTLP. 

Suppose that the NTLP is a hop-by-hop protocol.

Are you then assuming that both types of addressing
peer-to-peer addressing and end-to-end addressing 
can be applied in such a NTLP hop-by-hop protocol?

When peer-to-peer addressing is used, are you considering 
that the NTLP protocol will have to be terminated and re-initiated 
at each hop by the NSLP?

When end-to-end addressing is used, are you also considering 
that the NTLP protocol will have to be terminated and re-initiated 
at each hop by the NSLP?

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: dinsdag 25 februari 2003 10:46
To: Georgios Karagiannis (ELN); [email-masked]'
Subject: RE: [NSIS] another attempt on NTLP peer-peer definition

georgios,

r.

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Feb 2003 10:57:50 -0000

hi georgios,

> can be applied in such a NTLP hop-by-hop protocol?

as i say, it's a design choice (i.e. for later). rsvp uses both (p2p always for resv, p2p or e2e for path). i think it's hard to rule out either.

> that the NTLP protocol will have to be terminated and re-initiated 

i don't know what these questions mean in practice. can you phrase them as comments on the text below?

cheers,

r.

> indeed this is the terminology that the framework uses (in 
> the -01 version in section 3.3.4, although we know that 
> numbering will change soon...)
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 25 Feb 2003 12:09:19 +0100

Hi Robert

Okay, I have a comment regarding the following text:

"it is then up to the NTLP to get it to the next NE 
along the path (up- or down-stream), where it is received and 
the responsibility of the NTLP ends."

When end-to-end addressing is used, are you assuming that
the responsibility of the NTLP will end at each hop?

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: dinsdag 25 februari 2003 11:58
To: Georgios Karagiannis (ELN); [email-masked]'
Subject: RE: [NSIS] another attempt on NTLP peer-peer definition

hi georgios,

cheers,

r.

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Feb 2003 11:16:46 -0000

hi georgios,

> the responsibility of the NTLP will end at each hop?

i don't see the addressing model makes any difference here. the possible behaviour is described in the paragraph following the one with the sentence you quote. do you think that description is incorrect? (i think it's basically the same behaviour as rsvp with the necessary changes to support non-end-to-end operation and the fact that not all nodes will support all signalling applications.)

> as i say, it's a design choice (i.e. for later). rsvp uses 
> both (p2p always for resv, p2p or e2e for path). i think it's 
> hard to rule out either.
> 
> > 
> i don't know what these questions mean in practice. can you 
> phrase them as comments on the text below?
> 
> cheers,
> 
> r.
> 
> > 
> > 
> > Best Regards,
> > Georgios
> >  
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Feb 2003 12:50:05 -0000

georgios,

the difference between the two versions seems to me to be sub-microscopic in the level of precision involved; it wouldn't affect the protocol definition at all, but only the terminology you used to configure an entity that implemented it. i have no trouble living with it if others are happy.

r.

> Sent: 25 February 2003 12:44
> Do you mean that you will agree with the following text:
> 
> "The NTLP in the receiving NE may decide to forward the message 
> directly, or, it may give the message to a 
> generates another message to be sent via the NTLP."
> 
> Best regards,
> Georgios
> 
> 
> Sent: dinsdag 25 februari 2003 12:17
> i don't see the addressing model makes any difference here. 
> the possible behaviour is described in the paragraph 
> following the one with the sentence you quote. do you think 
> that description is incorrect? (i think it's basically the 
> same behaviour as rsvp with the necessary changes to support 
> non-end-to-end operation and the fact that not all nodes will 
> support all signalling applications.)
> 
> > 
> > Best Regards,
> > Georgios
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Feb 2003 22:35:55 -0000

hi tom,

> That's saying that some entities are just relay points at the 
> NTLP level.  
Indeed.

> Is this necessary, or can the NTLP use routing capabilities already 
> in place to deliver to the target peers?
The NTLP does use standard IP routing to do this; if a packet with an NSIS message inside hits an NSIS-unaware node (a plain old router) it just gets forwarded like any other IP traffic.

The issue you raise is that there may be nodes which are NSIS-aware but which still aren't interested in this particular message. (Half-plausible example: an RSVP PATH-like message with the router alert option carrying a firewall pinhole request is intercepted by a node which only understands QoS.) The message then has to be relayed at the NTLP level.

Hope this helps,

Robert H.

PS Actually it is possible to design signalling frameworks which avoid this problem. But you need a very connection-oriented approach for most of the signalling and a separate sophisticated capability-aware peer-discovery mechanism. I find the picture attractive, but I doubt it will be our first step.

> 
> Georgios Karagiannis (ELN) wrote:
> > Hi Robert
> >