Hi Dimitris-

Yes this would be a possibility...and it does speak to many of the key MTL requirements (but not all).    But to be clear - this would still be part of one of the MTL Bindings - not strictly part of NSI framework itself.   So this might be something in the SOAP/WS-RM/HTTP/SSL binding (not sure where it resides in the stack..)..  I think the common NSI functionality (what might be called a Generic Transport Layer) *would* be to define what the MTL does for the NSI layer - and this could include the functional  capabilities you mention.   But we may need to investigate further things like persistent/journaled messaging...such that there is a recovery mechanism that the NSI layer can rely upon.   (I don't know that we have considered this issue in detail yet...but we should - at least as part of v3.)

It is important, I think, to have the NSI layer describe what the MTL does using terminology that is specific to NSI.   If we define the lower layer interface by simply requireing another specific standard like WS-RM, we inextricably link NSI to those specific standards and versions and we become subject to them...and they are beyond our control.    But if we describe the MTL-NSI interface *generically* by functional capability, independent of specific standards, we allow NSI to function based upon the capabilities we want it to see - rather than the capabilities some other standard may or may not offer or continue to support.   For instance,  we can define the interface as an "a FIFO queue driven in-order reliable delivery of messages between NSAs", but if every message cannot be delivered, how should the MTL deal with this so that NSI can maintain consistent Connection state?  How do the NSI protocols *want* the MTL to deal with this?   We can define the interface between the NSI layer and the MTL, we cannot define the other standards...so we may need more than the other standards offer, or they may change.   So we allow the other standards to be used as part of the lower layer bindings that address the generic NSI requirements and we describe those other bindings in detail as part of the "protocol specific transport layer" of the MTL.   i.e. the Generic Transport Layer is what NSI sees and feels, the Protocol Specific Transport Layer fulfills those genric requirements with specific other protocols.

Thus we allow other bindings to be defined that may be desirable down the road, and we unlink NSI protocol functioning from other specific transport mechanisms that are only required to simply transfer messages between NSI agents.  (For instance, a user  application interface might prefer the current WS based bindings largely because it allows arbitrary agents to communicate through firewalls and NATs, where as a high volume public NSAs with peerings to other public high volume NSAs with routed may prefer a simpler binding that works where NATs are not an issue or where performance is more important.  Thus different bindings can be used, but the NSI protocol(s) themselves remain that same.)  

This really simplifies the NSI protocols immensely.

...my thoughts on the issue...
Jerry




On 2/6/13 2:00 PM, Dimitris Kalogeras wrote:
Hi Jerry, Jeroen et. al

There is a WS- standard called WS-RM (Reliable Messaging) which, I believe, provides the requirements you mention.

In WS-RM franca there are  logically two of these agents - the RM Source (RMS) and the RM Destination (RMD). They may be implemented by one or more handlers in any given SOAP stack.

The RM Source:

*Requests creation and termination of the reliability contract
*Adds reliability headers into messages
*Resends messages if necessary

The RM Destination:

*Responds to requests to create and terminate a reliability contract
*Accepts and acknowledges messages
*(Optionally) drops duplicate messages
*(Optionally) holds back out-of-order messages until missing messages arrive

So I assume that NSI can request to be transmitted on top of a  WS-RM "stream".

Cheers,
Dimitris

On 6/2/2013 4:20 πμ, Jerry Sobieski wrote:
Hi Jeroen-

I don't think we need to define the MTL Interface in a particular language (C, or C++, Java, Python, etc.)   But for the NSI Standard Specification, we should define the functional interface between the NSI layer and the MTL in order to bound what NSI protocols (in the standards documents) can safely assume will always be available to them...regardless of particualr transport protocol bindings.

This means that the NSI layer will know -for instance- that an NSA ID is always sufficient to deliver a message to another NSA.    Or, all NSI protocols know that they can request notification of a successful send as well as notification when a send fails, or that they can set a finite time for a send to be completed, or that all messages between two specific NSAs will always be sent in FIFO order, etc.  If a capability or feature is not described as part of the MTL Interface, then the NSI protocol specification cannot depend upon it being available, and thus cannot use it.   Likewise, if a feature is described in the MTL interface (say for instance a timeout value and a timeout callback) then a conformant MTL must [somehow] provide that capability and the NSI layer specification is allowed to reference that feature.  

It seems the easiest way to describe this functional interface between the NSI layer and an MTL would be to define a small set of specific primitives with parameters and how those parameters are supposed to function.   I.e a psuedocode form of a set of interface routines.    Admitedly, these psuedocode fucntions need not be implemented as described, but they nevertheless still offer a concise and bounded set of functionality for the NSI standards to use to describe how the NSI protocol should behave.   (We use state machines similarly to describe how the protocol should function *in the standard*, but an implementation is not required to implement state machines per se ...as long as the protocol implementation behaves as described in the standard by the state machine model, then the actual internal implementation method is left to the coder. ) 

So we should define
a) the MTL Interface primitives in a psuedocode fashion,
b) the common behaviour of the MTL in terms of message delivery, and
c) the transport protocol specifics for each binding.  


Hope this sheds more light...
Jerry

On 2/5/13 9:44 AM, Jeroen van der Ham wrote:
Hi,

I understand that we need to say something about the message transport between NSI.
What I don't see in this slide pack is why it has to be different from the simple statement "The MTL must be a reliable transport layer". Possibly with the addition of "with delivery notification".

It is all going to be outside of the scope of NSI anyway.

Jeroen.

On 4 Feb 2013, at 15:19, Jerry Sobieski <jerry@nordu.net> wrote:


HEre is some slides to present my ideas for separation of message transport from NSI protocols...

JErry
<NSI Message Transport Layer.pptx>_______________________________________________
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



-- 
Dimitrios K. Kalogeras

Electrical Engineer Ph.D.
Network Engineer
NTUA/GR-Net Network Management Center
_____________________________________
skype: aweboy
voice: +30-210-772 1863
fax:   +30-210-772 1866
e-mail: D.Kalogeras@noc.ntua.gr



_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg