[Nsi-wg] Reservation request message

[Jerry Sobieski]

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/ 
> <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/3e05eb75/attachment.html