[Nsi-wg] A Message Transport Layer description for NSI

[Jerry Sobieski]

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 at 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 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/20130206/b43d7242/attachment.html>