Ok. This is on my list of NSI version 3 issues:
Fixing the
MTL I didn't want to get into it yet either, but I
had this on my short list waiting for after SC...
The NSI protocol layer should not have to deal with issues
associated with the session layer. NSI just wants to send and
receive messages between NSAs, and have some assurance that the
message was successfully delivered, or not. This has nothing to do
with which message is being sent - it applies equally to all/any
messaging between NSAs. This goes back to the MTL
specification... We should not be projecting these lower layer
issues into the NSI layer.
The problem is, admittedly, that NATs and Firewalls get in the way.
The MTL should hide all of this from the NSI messaging. At the
NSI layer we should not be worried about the replyTo fields as these
are not part of NSI layer or even the MTL layer. For version3 we
should formalize an MTL that delivers messages between NSAs -
period. ...regardless of where those NSAs reside or which messages
are being sent. The basic issue is to construct a session between
two NSAs that can carry messages either way, and at any time, as
long as the session is up. If the session is down, we queue the
message until it is back up. If the message remains queued too
long waiting for the session to re-appear, it times out...and a "MTL
Timeout Error: Undeliverable Message" gets returned to the calling
process. If the the message is delivered to the peer (receipt
acknowledged), but the NSI layer does not receive a response to the
NSI primitive in some period of time, then we get a different
timeout error: "NSI Timeout Error: Unresponsive Peer".
This MTL allows either or both NSAs to establish the session. It
could be configurable for each peer NSA. If I see a remote NSA in
the topology and I want to send a Reserve msg, then I open a session
and keep it open until one of us decide to drop it. If I know of a
neighbor NSA that I would expect to interact with often, I can
immediately bring up a session when I start and hold it open
forever. For Others I bring up sessions only when needed, or maybe
there is a an aggregator somewhere (not adjacent) that I use often,
I can open and hold a session with that NSA, or open one as
needed. But each NSA can configure how they wish to manage their
sessions with other NSAs...indeed, this is in essence part of the
control plane topology we introduced in v2.
This simplifies RAs for mere mortals since they can establish the
session, send and/or receive messages, then drop the session until
the wish to check again sometime later. If an agent wants to be
notified immediately, it holds the session open indefinitely, or it
sets itself outside the FW or NAT with a routable IP address and the
notifying NSA can open a session when required. Or the user agent
can simply periodically open a session and check,...
While this mechanism does not allow two MTLs to reach each other if
both are behind a NAT or FW, this is situation that
essentially prevents *any* sessions from being opened between these
two hosts... and solving this problem is not an NSI or MTL issue -
its a network engineering issue. A publically routable federating
NSA could act as a control plane go between to work around the
fortress walls between many NSAs behind FW and NATs (a classic
peer-to-peer strategy)
The point is that NSI does not need to - and should not be burdened
with - worrying about low level session issues... If the session is
up, it can talk to the remote NSA and new or queued messages are
sent in order. If it is down, messages get queued for a finite
period of time. The MTL insures that the messages are "delivered"
or "not delivered" and deals with the lower layer details. (This MTL
notion is a common feature of many signaling protocols -e.g. ITU
2931 had the SCCP protocol that handled message delivery, routing,
flow control, segmentation, etc. for delivering the actua signaling
messages between the signaling nodes.)
This MTL can employ WS libraries or SOAP functions or other
mechanisms, but NSI layer is not sensitive to them. Thus NSI
becomes independent of those layers... and the MTL interface is all
NSI needs to worry about in terms of sending or receiving messages.
The MTL communications format can be advertised in the topology or
out of band between trusted peers.
This MTL also makes it easy to send messages between any NSAs. And
having the capability to send a message between two NSAs regardless
of their role in the service tree is critical for some of the
advanced tree processing functions we talked about for multi-point,
monitoring, and fault processing, etc. We really REALLY should fix
this and make NSI the master of how it sends messages - not the
underlying code libraires.
But I agree with Inder, this is a topic for the spring when we begin
making v3 features/requirements. Or a beer topic at SC :-)
Jerry
On 10/31/12 10:14 AM, Hans Trompert
wrote:
I'm very much in favor of having the NSI CS 2.0 summary query
implemented as a synchronous call as is in NSI CS 1.0.
HansT.
On 10/31/12 1:37 PM, John MacAuley wrote:
I would be more than happy to move the summary query to a synchronous call and have the detailed query asynchronous. Would definitely help with clients behind firewalls.
Sent from my iPhone
On 2012-10-31, at 6:24 AM, "michalb" <michalb@man.poznan.pl> wrote:
Hello,
This is for reservation query - will there be a synchronous version of that operation (basic query at least)? It is not always possible to listen on query responses and polling would help under such circumstances.
br
michal
-----Oryginalna wiadomość----- From: Jeroen van der Ham
Sent: Tuesday, September 18, 2012 4:37 PM
To: nsi-wg@ogf.org Group
Subject: [Nsi-wg] Query request
Hi,
While thinking about a demonstration scenario for SC, we came upon an interesting use-case for the query command. We are trying to plan workflows on the infrastructure, depending on availability. For that it would actually be useful to know not only if a certain resource is in use, but also when it could become available again.
Would it be possible to add capabilities for the query command to provide something like that?
Jeroen.
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg