[Nsi-wg] NSI service
Jerry Sobieski
jerry at nordu.net
Fri Sep 2 07:49:36 CDT 2011
Hey John - question about the requesterNSA/providerNSA fields...see
comment in line..
On 9/2/11 8:30 AM, John MacAuley wrote:
> Looks like I have some explaining to do. We forget that not everyone
> is participating in the NSI weekly meetings and the extra special OGF
> conference meetings. Lucky for you, but unfortunately you miss the
> results of some of the discussions. The is only one SOAP endpoint in
> the message and that is in the replyTo field. We originally didn't
> have the replyTo field and the endpoints were in the requesterNSA
> and providerNSA fields, however, there was a push to make these field
> protocol independent.
>
> I wrote the new topology schema a couple of weeks ago so this is the
> first time a SOAP endpoint had shown up in the schema. Mainly for
> discovering the ProviderNSA endpoint. This will remove manual
> provisioning of the endpoint in each NSA. Howeve, now that we have
> this topology mechanism, we could expand it to hold the Requestor
> endpoint as well, removing the need for the replyTo field.
>
> Here is what a request should look like based on all the agreements we
> have reached. We need to make sure everyone follows this pattern or
> chaos will prevail :-)
>
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:int="http://schemas.ogf.org/nsi/2011/07/connection/interface"
> xmlns:typ="http://schemas.ogf.org/nsi/2011/07/connection/types"
> xmlns:urn="urn:oasis:names:tc:SAML:2.0:assertion"
> xmlns:xe="http://www.w3.org/2001/04/xmlenc#"
> xmlns:xd="http://www.w3.org/2000/09/xmldsig#">
> <soapenv:Header/>
> <soapenv:Body>
> <int:reservationRequest>
> <int:correlationId>*urn:uuid:73d32a9d-fc68-4736-9c24-99abce1aaea3*</int:correlationId>
> <int:replyTo>*http://orval.grid.aau.dk:7080/NSI/services/ConnectionService*</int:replyTo>
> <typ:reservation>
> <requesterNSA>*urn:ogf:network:nsa:Aruba-OpenNSA*</requesterNSA>
> <providerNSA>*urn:ogf:network:NSnetwork:Martinique-DynamicKL*</providerNSA>
Right here ^ Why do you specify an NSA URN in the requesterNSA field
but specify a Network in the provider NSA field ?? These should both
be NSA references. Right?
Also, at SLC, we did not define an "NSA" URN...not that I recall. Did
we? I think what you have will work nicely for now, but I don't think
it is in the spec. (?) Therefore, we should put this on the near term
dicussion list to get group consesnsus. (we touched only on the Network
<not equal> NSA issue, but not how that should be done or what the
mapping supports, etc.)
> <reservation>
> <globalReservationId>*urn:ogf:network:service:**Aruba**:conn-560*</globalReservationId>
> <description>OpenNSA Test Schedule #1</description>
> <connectionId>*urn:uuid:593d9816-0574-471d-b2a9-101e63a5d0f2*</connectionId>
> <serviceParameters>
> <schedule>
> <startTime>2011-10-15T21:32:52+01:00</startTime>
> <endTime>2011-10-15T22:32:52+01:00</endTime>
> </schedule>
> <bandwidth>
> <desired>100</desired>
> </bandwidth>
> </serviceParameters>
> <path>
> <directionality>Bidirectional</directionality>
> <sourceSTP>
> <stpId>*urn:ogf:network:NSnetwork:Martinique:M1*</stpId>
> </sourceSTP>
> <destSTP>
> <stpId>*urn:ogf:network:NSnetwork:Martinique:M4*</stpId>
> </destSTP>
> </path>
> </reservation>
> </typ:reservation>
> </int:reservationRequest>
> </soapenv:Body>
> </soapenv:Envelope>
>
> On 2011-09-02, at 5:45 AM, Henrik Thostrup Jensen wrote:
>
>> On Wed, 31 Aug 2011, 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.
>>
>> I combine the endpoints in OpenNSA, but as I interpret the protocol,
>> this is not a requirement at all, and the protocol explicitely
>> supports different endpoitns for this.
>>
>> It is important to note, that the RA endpoint is only advertised
>> through the replyTo field (AFAIK), and never in the topology and
>> requester / provider fields.
>>
>>> Comments?
>>
>> I find that there are way to many addressing schemes. Currently there is:
>>
>> A. NSA provider endpoint advertisted through topology.
>> B. NSA provider and requester endpoint specified in provider/requester
>> message fields.
>> C. NSA requester endpoint specified in replyTo message field.
>>
>> Which is simply to many IMHO.
>>
>> I think the providerNSA and requesterNSA fields in the message could
>> be removed entirely without problems (these fields smell alot like
>> some low level protocol where security is not an issue - which is not
>> the case for NSI at all).
>>
>> I would also like to see the removal of the replyTo field, such that
>> an NSA only has one contact point - the one advertised through the
>> topology.
>>
>>
>> Best regards, Henrik
>>
>> Henrik Thostrup Jensen <htj at ndgf.org <http://ndgf.org>>
>> NORDUnet / Nordic Data Grid
>> Facility._______________________________________________
>> 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/20110902/0e375a1a/attachment-0001.html
More information about the nsi-wg
mailing list