Hey John-
I have a few concerns about this sample Reservation Request:
- I chg'd security attributes to <sessionSecutiyAttrib> as I
believe there are two levels of authorization: First, the RA NSA
must be authenticated and authorized to even talk to the PA NSA.
Second, the service request itself must be authorized by the
network(s) along the path. So I also added an authorization
element to the service parameters
- I added a "serviceDefinition" field in the reservation request.
While this could be omitted, I think its useful to explicitly state
the service you are expecting...and it could help the pathfinder
construct a candidate path.
- I put all schedule inside the service parameters - these are
constraints on the service...not something independent of the
service.
- Changed the STP names: I added a "NORDUnet" network name and a
simple "foo" local part just to make sure the request functions with
these legal names.
- I removed the path object from the source and dest STPs - This is
arguable, but I felt this was more consistent with the other service
parameters. I don't think we have a justification anymore for a
PathObject with intermediate STPs...such a thing is just a Tree
style segmentation. But if folks want to keep this PO with the src
and dst, I don't have a big deal with it.
I am almost of a mind to suggest we define all service parameters
like you did the security attributes:
<attribute>
<attributeName> NameThing </attributeName>
<attributeValue> abcd </attributeValue>
</attribute>
This would make the service definition XSD easier I think.
Let me know what you think.
Jerry
On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg