On 4/13/11 11:22 AM, Jeff W. Boote wrote:
I would go one step further here and say that there is no benefit in having multiple ways to specify most things in schema, and it makes interoperability and software development more cumbersome. (i.e. For bandwidth, just specify an explicit unit. Do not have another parameter to define units. There is no benefit to having multiple ways to specify it and it just adds to complexity of software.)
Hi Jeff- Yes. I concur. I think a lot of folks dropped off the cal before we covered a few aspects of the Service Definition.... My thinking is to make a very simple SD. A Service Name, and a list of Service Attributes. Each Service Attribute will take one of only a very few forms so that the NSA validation module can compare Service Request Attributes with Service Definition Attributes. For instance, a Service Attribute could take the form of a "range" (min, max), a "interval" (floor, ceiling, step), a "choice" ( "a", "b", "c",...), and probably a "dateTime" (yyyy-mm-ddThh:mm:ss). Optional Service Attributes will have a default value, and lacking a default, the Attribute is required to be specified in the SR by the RA. And Units would be explicit in the annotation of each Attribute. THis allows the NSA to insure a complete and explicitly specified service request is communicated between RA and PA. However, this is not [currently] sufficient to generalize the entire service allocation process... But it will prune the search space considerably and allow a straight forward high level candidate path to be selected fairly easily. So it is very useful. The workings of Service Definitions will be increasingly obvious and important as new service capabilities in our networks are identified and engineered. This SD process is one of the truly novel aspects of NSI that I think will be very useful in coming years. At the moment, we need to define the minimum SD capability necessary get V1.0 out the door. To this end, I have chucked the idea of a generalized XSD for service definitions - its difficult to do what I think we need done. And the bells and whistles I had in mind are not really necessary now (maybe we revisit later...). For now, I propose to simply describe essential what I just said above, and provide an example XML based Service Definition, and a corresponding Service Request. A set of several SDs can be then easily defined and verified, and all NSA should produce the same expected result. I need to look thru several other comments yet regarding the SD I profered several days back... So I have'nt settled yet on a final form. I need to see what concerns and suggestions were made... I think we are close though. Regards all Jerry Jerry
jeff
On Apr 13, 2011, at 7:39 AM, Atsuko Takefusa wrote:
Hi all,
I prefer John's structured schema. Because it can specify optional or mandatory parameters and data types of each parameter, explicitly. In order for interoperability, we should define a standard schema as explicitly as possible. Thank you,
Atsuko G-lambda, AIST
2011/4/12 John MacAuley<john.macauley@surfnet.nl>:
Peoples, I think there is one major area we need to close on before I feel comfortable starting to write the associated document. It is specifically around the service parameters and how they are specified: <!-- Parameters relating to the requested service. --> <xsd:complexType name="ServiceParametersType"> <xsd:sequence> <!-- Time parameters relating to the reservation. --> <xsd:element name="schedule" type="tns:ScheduleType"/> <xsd:element name="bandwidth" type="tns:BandwidthType"/> <xsd:element name="directionality" type="tns:DirectionalityType"/> <xsd:element name="pathObject" type="tns:PathObjectType"/> <xsd:element name="guaranteed" type="tns:AttributeSequenceType" minOccurs="0"/> <xsd:element name="preferred" type="tns:AttributeSequenceType" minOccurs="0"/> </xsd:sequence> </xsd:complexType> The main question I have is do we change this structure to be completely generic and list all service parameters through type/value pairs, or do we break out hose key ones as I have here and put the remaining in the type/value pairs? Also, for bandwidth do we document the values as Mb/s or do I add an element to explicitly identify the unit as suggested in one provided comment. Thank you, John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg