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