[Nsi-wg] NSI service
Jerry Sobieski
jerry at nordu.net
Wed Aug 31 17:07:11 CDT 2011
Ok ... comments in line:
On 8/31/11 10:53 AM, John MacAuley wrote:
> Yes you can combine them if you need to. But I think the protocol
> will work without them combined.
>
> The csProviderEndpoint value tells the RA how to contact the PA for a
> network. The RA fills in the replyTo field within the SOAP request to
> tell the PA how to respond with the confirmation, failed, or forcedEnd
> messages. Jerry will have a stroke, but this would allow an RA-only
> entity to not need to be in the topology file.
The csProviderEndpoint tells the local NSA how to contact the NSA
represented by the NSA object. Period. No RA or PA qualifications or
constraints. - NSA to NSA. The roles of the NSA in any particular
request should not affect the address used to send or receive a
message. It affects which fields the NSA IDs go into, but it does not
affect where a message is sent if its going to a particular NSA. One
NSA, one address.
The confrimation response is an NSI CS protocol message - it does not
rely on the reply going back to the same SOAP Endpoint that issued some
other message. For example: It would be perfectly fine within the CS
protocol to *change* the NSA contact information associated with an NSA
bewtteen the Request and ensueing Response. The NSI layer would still
function just fine - it would find the NSA addess for the appropriate
NSA and queue a Confirmation. But the MTL would break this if the MTL
is expecting to send the message back to where it came from. This is
just broken John and should not be even considered.
Likewise, I could restart and issue the confirmation after a local
restart ...the SOAP environment would be destroyed and the MTL would not
know how to deliver the message. In NSI, each message is processed by
the MTL independent of every other NSI message. Period. We've gone
over this before. It is ok to acknowledge receipt of a message
between two MTLs in order to assure delivery - this is fine within the
SOAP environment. But you cannot link upper Layer NSI CS messages to
SOAP constraucts or dependencies.... No.
>
> If we want to remove the requirement for the replyTo field and force
> all RA addresses into the topology file then we could do that. We
> would then do a lookup for the NSA csRequesterEndpoint in topology
> before sending a confirmation.
>
This is much better. But still not clear why we care or need this...?
The PA NSA receives a Request() message...once the MTL has finished
processing it the message is passed up to the NSI layer for
processing. The NSI layer looks at the msg type and says to itself
"Self, this is a primitive *request* that I just *received*, therefore I
am the NSA in the PA-NSAID, and the request came from the NSA in the
RA-NSAID field. The NSI layer will never need see the SOAP Endpoint
or any other SOAP fields...and shouldn't. It only sees the NSI message
header and learns its role from that....right?
What I suggest is the following:
I think there is some confusion about the RA and PA _/roles/_ getting in
the way of /_Source and Destination NSA_/s in the message header. Maybe
the msg header field names are chosen poorly. But without changing the
roles of the corresponding NSAs, or the semantics of the
messages/primitives, we could rename the message header fields to
"SourceNSA" and "DestNSA". The message mechanics be a bit clearer if
the message header fields were clearly meant as message delivery fields
rather than NSI functional roles. Not faulting anyone on this...but
would it not work better? Their respective roles as RA and PA will
still be obvious from the message type and direction (e.g. a "send"
"Request" msg puts the PA's NSAID in the destNSA field and the RA's
NSAID in the SourceNSA field,, The NSA issueing the Response msg will
place the RA's NSAID in the destNSA field, and the PA's NSAID in the
sourceNSA field.
This way, the MTL always sends messages based soley on the DestNSA field
of the NSI message. No confusion, and it requires almost no knowledge
of the NSI layer primitives. The MTL still needs to know the *address*
of the destNSA. So a lookup is still required by someone....The MTL
could a) require NSI layer provide the address as a Send() parameter, or
b) the MTL could find the NSAID in the topology database itself and grab
the contact info, or c) we define another service to look up this
information.
I suggest "b" - at least for Rio as we are pretty much there now. But
"a" would be an easy and perhaps purer alternative since it means the
MTL needs no topology access.
Jerry
> Comments?
>
> John.
>
>
> On 2011-08-31, at 10:35 AM, Michał Balcerkiewicz wrote:
>
>> Hello,
>> I want to clarify a bit on NSI services – currently when generating
>> sources from the NSI wsdls we get two services (RA and PA) and each
>> one has its own url. I try to combine them together so they will be
>> accessible under a single url, suitable for csProviderEndpoint.
>> Br
>> michal
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110831/61f43da8/attachment.html
More information about the nsi-wg
mailing list