Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt

From: [email-masked]
Date: Tue, 28 Oct 2003 15:42:59 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title		: Next Steps in Signaling: Framework
	Author(s)	: R. Hancock
	Filename	: draft-ietf-nsis-fw-05.txt
	Pages		: 45
	Date		: 2003-10-28
	
The Next Steps in Signaling working group is considering protocols 
for signaling information about a data flow along its path in the 
network. Based on existing work on signaling requirements, this 
document proposes an architectural framework for such signaling 
protocols. 
This document provides a model for the network entities that take 
part in such signaling, and the relationship between signaling and 
the rest of network operation. We decompose the overall signaling 
protocol suite into a generic (lower) layer, with a separate upper 
layers for each specific signaling application. An initial proposal 
for the split between these layers is given, describing the overall 
functionality of the lower layer, and discussing the ways that upper 
layer behavior can be adapted to specific signaling application 
requirements. 
This framework also considers the general interactions between 
signaling and other network layer functions, specifically routing and 
mobility. The different routing and mobility events that impact 
signaling operation are described, along with how their handling 
should be divided between the generic and application-specific 
layers. Finally, an example signaling application (for Quality of 
Service) is described in more detail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nsis-fw-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nsis-fw-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Ling Kim Hui" <[email-masked]>
Date: Fri, 31 Oct 2003 16:06:51 +0800

Hi Mr Hancock and all,
 
    I think this latest framework draft is a good piece of work.  I have
some comments and wish to seek some clarifications.  Thanks in advance!
 
* In section 3.1.2, it is mentioned that in the path-coupled case,
signaling messages do not have to reach all the nodes on the data path.
Does it mean that signaling will be able to skip some of the NEs on the
data path, bypassing even the NTLP layer?

* In section 3.2.5 (pt 4), we consider a case of route change when a
peer has failed or become available. Consider the case of a peer
failure, in the event of a NE failure (NTLP not accessible) instead of a
whole node failure (normal operations of a router such as routing are
still available). Is this case classified as a route change? If not, how
can we differentiate this from a real route change (failure of the
entire node)?

* In section 3.3.1, "Where signaling is looking for the last (nearest to
receiver) NE on the data path, receiver oriented signaling is most
efficient". Looking in another perspective, the receiver oriented
signaling needs to discover the last NE (the first NE with respect to
the sender) on the data path in the reverse direction. It seems to me
that signaling in either directions will encounter similar difficulties.
Can I seek clarification on this issue?

* In section 4.2 paragraph 2, "With peer-peer addressing, an NE will
determine the address of the next NE based on the payload of the message
(and potentially on the previous NE)." It is possible that some
information in the payload is accessible to NSLP only. Therefore the
function requires some interaction between NTLP and NSLP. Would there be
a clear definition of what is the information necessary to be accessible
by the NTLP in the payload for the peer discovery? For example, flow
classifiers (so that NTLP could interact with routing protocols)?

* In section 4.6.2 paragraph 2, "In addition, the session identifier can
be used by the NTLP to demultiplex received signaling messages between
multiple instances of the same signaling application, if such an
operational scenario is supported." The demultiplex of the multiple
instance of the same signaling application should be done at the NSLP
layer. What's more, this cannot replace the Signaling Application
Identifier, since there will be no Session Identifier exists on a NE
before any session was setup even though the NSLP is installed on the
node. 

Recommended change: Remove this statement.

* In section 4.6.3 paragraph 2, "No position is taken on the form of the
signaling application identifier, or even the structure of the signaling
application 'space' - free-standing applications, potentially
overlapping groups of capabilities, etc." The Signaling Application
Identifier should be defined and managed by the NSIS framework, like the
protocol number for IP. Otherwise, it will lose the capability for
interoperation. E.g. If QoS NSLP from vender A take a form a of the
identifier, and QoS NSLP from vender B take a form b of the identifier,
they will never be able to interoperate even though they are
implementating the same protocol.

Recommended change: Replace statement with "Format of the signaling
application identifier will be defined and mantained by the NSIS
framework."

Thank you very much for your time and attention.

Regards,

Kim Hui

---

From: "Ling Kim Hui" <[email-masked]>
Date: Fri, 31 Oct 2003 16:07:44 +0800

Hi Mr Hancock and all,

Regards,

Kim Hui

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 31 Oct 2003 09:38:45 -0000

hi Kim Hui,

thanks for these comments.
i'm hoping most of them can be viewed/handled as clarifications
(i think it's difficult to make substantive changes on our own 
now the WG last call has completed, but i'll try to work in whatever is 
necessary when I do updates following AD/IESG review.)

> -----Original Message-----
> From: Ling Kim Hui [mailto:[email-masked]]
> Sent: Friday, October 31, 2003 08:07
> To: [email-masked]
> Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt
> 
> 
> Hi Mr Hancock and all,
> 
>     I think this latest framework draft is a good piece of 
> work.  I have some comments and wish to seek some 
> clarifications.  Thanks in advance!
> 
> * In section 3.1.2, it is mentioned that in the path-coupled 
> case, signaling messages do not have to reach all the nodes 
> on the data path. Does it mean that signaling will be able to 
> skip some of the NEs on the data path, bypassing even the NTLP layer?

the main purpose of 3.1.2 is to say that if a node is not a signalling
node (just a routing node) you don't have to make signalling go through
it. (i see that the phrasing of the first sentence might make it seem
like node=NE which is not intended.)

the question of how to handle bypassing intermediate nodes which are
signalling aware is discussed in 3.2.3, including whether or not the NTLP
should be involved there. however, it is left open by the framework,
since we can't really decide what is possible without going into the
actual protocol design.

> 
> * In section 3.2.5 (pt 4), we consider a case of route change 
> when a peer has failed or become available. Consider the case 
> of a peer failure, in the event of a NE failure (NTLP not 
> accessible) instead of a whole node failure (normal 
> operations of a router such as routing are still available). 
> Is this case classified as a route change? If not, how can we 
> differentiate this from a real route change (failure of the 
> entire node)?

i consider this as coming under the broad heading of route changes.
there are actually several different categories of route change
anyway (different peer because of topology change, different peer
because of NE failure but no rerouting, same peer but different
ingress or egress interfaces, same peer but different intermediate
routers, ...)

exactly how each case is distinguished and handled will have to be
done during protocol design. different protocol designs and indeed
different implementations will be able to do different types of 
route change handling, so the framework can't really define this.

> 
> * In section 3.3.1, "Where signaling is looking for the last 
> (nearest to receiver) NE on the data path, receiver oriented 
> signaling is most efficient". Looking in another perspective, 
> the receiver oriented signaling needs to discover the last NE 
> (the first NE with respect to the sender) on the data path in 
> the reverse direction. It seems to me that signaling in 
> either directions will encounter similar difficulties. Can I 
> seek clarification on this issue?

this is probably not well phrased. it refers to the case where
the signalling application needs to involve the NE closest to
the flow receiver. finding this NE may need a message from the
sender, but the actual signalling application negotiation is
most efficiently carried out between NE and receiver (which is
receiver initiation, loosely).

> 
> * In section 4.2 paragraph 2, "With peer-peer addressing, an 
> NE will determine the address of the next NE based on the 
> payload of the message (and potentially on the previous NE)." 
> It is possible that some information in the payload is 
> accessible to NSLP only. Therefore the function requires some 
> interaction between NTLP and NSLP. Would there be a clear 
> definition of what is the information necessary to be 
> accessible by the NTLP in the payload for the peer discovery? 
> For example, flow classifiers (so that NTLP could interact 
> with routing protocols)?

the information is the flow id (4.6.1). we specifically don't
call this the flow classifier, since the NTLP isn't interested
in packet classification; another name for the flow id would
be 'flow routing information' (which is what the NTLP draft calls
it). the NSLP might use the flow id as part of a packet classifier.

> 
> * In section 4.6.2 paragraph 2, "In addition, the session 
> identifier can be used by the NTLP to demultiplex received 
> signaling messages between multiple instances of the same 
> signaling application, if such an operational scenario is 
> supported." The demultiplex of the multiple instance of the 
> same signaling application should be done at the NSLP layer. 
> What's more, this cannot replace the Signaling Application 
> Identifier, since there will be no Session Identifier exists 
> on a NE before any session was setup even though the NSLP is 
> installed on the node. 

the demultiplexing possibility is mainly related to load 
sharing if you need to achieve some very high level of
signalling application processing in a single node. there is
(I hope) no suggestion that the session id could replace
this signalling application id.

> 
> * In section 4.6.3 paragraph 2, "No position is taken on the 
> form of the signaling application identifier, or even the 
> structure of the signaling application 'space' - 
> free-standing applications, potentially overlapping groups of 
> capabilities, etc." The Signaling Application Identifier 
> should be defined and managed by the NSIS framework, like the 
> protocol number for IP. Otherwise, it will lose the 
> capability for interoperation. E.g. If QoS NSLP from vender A 
> take a form a of the identifier, and QoS NSLP from vender B 
> take a form b of the identifier, they will never be able to 
> interoperate even though they are implementating the same protocol.
> Recommended change: Replace statement with "Format of the 
> signaling application identifier will be defined and 
> mantained by the NSIS framework."

formally, the f/w is not a standards track document, so it 
cannot define and manage identifier formats in this way. at
the moment it seems likely that the session id will be an
object in the NTLP, so the NTLP specification will pin this down
and the sort of problems you indicate cannot arise.

> Thank you very much for your time and attention.

it was a pleasure!

r.

> Kim Hui

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