[Nsi-wg] Query request

Thu Nov 1 12:00:59 EDT 2012

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 at 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 at 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 at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20121101/f220225d/attachment.html>