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>
           <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@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg