[Nsi-wg] Query request

Fri Nov 2 05:20:34 EDT 2012

Hi,

The NSI has chosen to use SOAP and WSDL as its message transport layer. This is a reasonably standard protocol, with support (more or less) in many different languages. For what we aim to do it is pretty good, and it has proven to work pretty well in the past few demos.

You're saying that we should not be projecting lower layer issues into the NSI layer. In my opinion this is exactly what has happened already. And it is also exactly the reason that we are having all these issues.

Reliable message transport layers are readily available off the shelf. TCP makes sure that a packet gets from the source to the destination. On top of that we're using HTTP, which also provides some additional guarantees that the message gets there, including some error codes regarding malformed messages, messages out of order, authentication errors, et cetera.
We've used an additional SOAP layer on top, which provides you with even more guarantees.

Can someone please explain to me that in this scenario we really need to have separate confirmation messages? And even if we do, why do these messages have to be exchanged in a completely separate TCP-HTTP-SOAP session?

I understand that we have a state machine, with transition using confirmation messages. But can't we use any of the TCP/HTTP/SOAP status messages to achieve that?

Jeroen.

On 1 Nov 2012, at 17:00, Jerry Sobieski <jerry at nordu.net> wrote:

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