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

[Dimitris Kalogeras]

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 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
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at 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 at noc.ntua.gr

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