[Nsi-wg] Reservation request message

[John MacAuley]

I changed the <securityAttr> element to <sessionSecurityAttr> as requested.

I have gone through the other changes and need to discuss the structure of the reservation in your modified example:

   <reservation>
      <globalReservationId>urn:uuid:e7712ca0-d85f-4176-8f43-2981a988813a</globalReservationId>
      <description>This is an example schedule request.</description>
      <connectionId>1234567890</connectionId>
      <serviceDefinition>file://user/jerry/EthernetFramedPayloadService.xml</serviceDefinition>
      <serviceParameters>
         <sourceSTP>
            <networkId>NORDUnet</networkId>
            <localId>cph-ps</localId>
         </sourceSTP>
         <destSTP>
            <networkId>netherlight.net</networkId>
            <localId>urn:ogf:network:domain=netherlight.net:node=f25s1t:port=0-21:link=dlp01.surfnet.nl</localId>
         </destSTP>
         <authorizationAttrib>
            <certificate>c450f23a</certificate>
         </authorizationAttrib>
         <bandwidth>
            <bytesPerSecond>1000</bytesPerSecond>
         </bandwidth>
         <maxBurstSize>
            <bytes>100000</bytes>
         </maxBurstSize>
         <directionality>bidirectional</directionality>
         <schedule>
            <startTime>2011-05-30T09:30:10-06:00</startTime>
            <endTime>2011-05-30T10:30:10-06:00</endTime>
         </schedule>
      </serviceParameters>
   </reservation>

You have added some additional elements here within the reservation, and modified by definition of bandwidth.  Can I assume you do not want these as dedicated elements but flexible attributes as discovered from the Service Definition?  Do we need to have required and best effort SD attributes?  For example, could we specify these either using your SD schema, or the <AttributeSequenceType>

         <guaranteed>
            <attribute>
               <attributeName>maxBurstSize</attributeName>
               <attributeValue>100000</attributeValue>
               <attributeValue>bytes</attributeValue>
            </attribute>
            <attribute>
               <attributeName>bandwidth</attributeName>
               <attributeValue>1000</attributeValue>
               <attributeValue>bytesPerSecond</attributeValue>
            </attribute>     
         </guaranteed>

We could break out a specific attributeUnit to make it even clearer.

         <guaranteed>
            <attribute>
               <attributeName>maxBurstSize</attributeName>
               <attributeValue>100000</attributeValue>
               <attributeUnit>bytes</attributeUnit>
            </attribute>
            <attribute>
               <attributeName>bandwidth</attributeName>
               <attributeValue>1000</attributeValue>
               <attributeUnit>bytesPerSecond</attributeUnit>
            </attribute>     
         </guaranteed>

I know you want to have SD attributes that are not defined until after the fact, so we  need to be careful to clearly define the XSD structure in a generic way.

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/67888fc5/attachment-0001.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/67888fc5/attachment-0001.bin