[Nsi-wg] A Message Transport Layer description for NSI
Jerry Sobieski
jerry at nordu.net
Wed Feb 6 09:39:51 EST 2013
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 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
>
>
> _______________________________________________
> 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/c337ad15/attachment.html>
More information about the nsi-wg
mailing list