[Nsi-wg] NSI service
Atsuko Takefusa
takefusa at acm.org
Fri Sep 2 09:29:51 CDT 2011
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