[Nsi-wg] NSI service
John MacAuley
john.macauley at surfnet.nl
Fri Sep 2 10:54:36 CDT 2011
Can everyone one reply and let me know if they can do https or should we only do http?
I think we should use http basic authentication to secure the session. Can everyone allocate a set of accounts on their system for each of the NSA and send the information to the associated NSA prime?
Thanks,
John
Sent from my iPhone
On 2011-09-02, at 10:29 AM, Atsuko Takefusa <takefusa at acm.org> wrote:
> Hi Jerry, John, and all,
>
> We will use "urn:ogf:..." values in <requester/providerNSA> and
> <stpId>, won't we?
> If so, why do we describe the "urn:ogf:..." values in the .owl file?
>
>
> And I have a question about security.
> Which of the followings will we use at Rio?
>
> #1 http + no authentication
> #2 http + basic authentication (single user name & password)
> #3 https + basic authentication (single user name & password)
> #4 other
>
> If #2 or #3, what are the user name and password?
>
> Thanks,
>
> Atsuko
>
>
> 2011/9/2 Jerry Sobieski <jerry at nordu.net>:
>> Ok good. I agree with what you did...it makes sense to me. And you and I
>> had discussed the NSA topo object. We just need to bring this to the group
>> when we do a Rio post-mortem (:-).
>>
>> I recall that we decided that the NSA and the Network were separately
>> addressable entities - one was an active agent, and one just represented an
>> administrative/infrastructure domain. Each network has exactly one NSA, and
>> each NSA manages exactly one network. (This does not preclude things like
>> federated structures in the future, but feds require some topological
>> considerations that we have not broached yet.)
>>
>> Thanks!
>> Jerry
>>
>> On 9/2/11 9:00 AM, John MacAuley wrote:
>>
>> You are correct - copy and paste issue. It should
>> be urn:ogf:network:nsa:Martinique-DynamicKL.
>> I can't remember if we decided to use the network to define the NSA, but in
>> the topology we need to uniquely name the NSA and it can't conflict with the
>> network name. I made the leap of faith that we should then use this NSA
>> name in the NSA fields.
>> John.
>> On 2011-09-02, at 8:49 AM, Jerry Sobieski wrote:
>>
>> 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>
>> NORDUnet / Nordic Data Grid
>> Facility._______________________________________________
>> nsi-wg mailing list
>> 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
>>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>>
>
>
>
> --
> Atsuko Takefusa
> Information Technology Research Institute, AIST
More information about the nsi-wg
mailing list