[Nsi-wg] Reservation request message

[John MacAuley]

So this is URI is a reference to a local NSA file representing the desired SID for the request?  Can I assume then that an NSA will not dynamically retrieve this file from the specified location and has pre-knowledge that it exists?  If so then I think exposing internal filesystem structure is probably a bit dangerous so we should look at a couple of options:

1. We could use the ServiceName of the SID.
2. We could use a public URL used to access the resource on the NSA (i.e. http://nas.ip.address.com/nsi/connection/EthernetFramedPayloadService.xml).
3. Assign a namespace to each SID and use this in the reference.

John

On 2011-04-06, at 12:15 AM, Jerry Sobieski wrote:

> The intent (I am a novice XML/XSD developer) is now that we develope a workable XSD that describes an Etehrnet transport Service.   This will be the Service Definition.   Each network can modify theirs slightly to reflect minor service differences.  The SD is distributed with topology and so is stored in the topology DB with the associated network/domain node.  
> 
> The Service Request is received by an NSA.  The NSA starts by locating the origination STP in his topologyDB, and finds a SD associated with that network.   He validates the SR with the SD.  If thats good, he creates a child segment and forwards that to that network for reservation.   He modifies the SR to reflect new endpoints, and repeats the process.
> 
> For what I expect DRAC would do...  The DRAC NSA would recieve the SR, look at the end points, find the origSTp network SD, validates the SR.xml using the SD.xsd, if ok, he will issue a child segment to that network.  The NSA will modify the SR to reflect new endpoints, find the next hop network, grab the SD, validate the SR, issue the child resv, and repeat.   When the NSA creates a segment of just localorig and localdest, it will know its time to send the request to DRAC.  IT will look up the endpoint names in a local name table and pull the associated DRAC designators outand return them.  The NSA will insert the DRAC designators into a package for DRAC and send it off.
> 
> Is this helpful?
> J
> 
> On 4/5/11 11:36 PM, John MacAuley wrote:
>> 
>> Jerry,
>> 
>> What is the expected NSA behaviour with respect to the <serviceDefinition> element?
>> 
>> <serviceDefinition>file://user/jerry/EthernetFramedPayloadService.xml</serviceDefinition>
>> 
>> Should the receiving NSA be able to interpret this in some way to provide request context?
>> 
>> John.
>> 
>> On 2011-03-25, at 10:42 PM, Jerry Sobieski wrote:
>> 
>>> 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 at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>> <ogf_nsi_reserve_message_1_0sob.xml>
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/d4aad5be/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/d4aad5be/attachment.bin