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.
Hello John and Jerry, I want to separate generic parameters from service-specific parameters. G-lambda interface introduced xsd:extension to inherit generic parameters in service-specific definition. Please find attached the sample xsd of general and service-specific definitions and the ppt describing parameter descriptions and usage scenario. By using xsd:extension, we don't need to list all service parameters in a xsd. I want to explain and discuss this methodology in today's conf call. Best regards, Takahiro John MacAuley wrote:
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
-- Takahiro Miyamoto <tk-miyamoto@kddilabs.jp> Integrated Core Network Control And Management Laboratory KDDI R&D Laboratories, Inc. TEL: +81-49-278-7455 / FAX: +81-49-278-7811
This is good input. Last month I had written up a version that used the <xsd:any> to allow for inclusion of technology and deployment specific elements not defined in the core schema. In this case you would have the parent schema that could include addition schema elements in the instance document. This is an inverse to the extension strategy, but perhaps a good way to include other concrete schemas? <!-- 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:AnySequenceType" minOccurs="0"/> <xsd:element name="preferred" type="tns:AnySequenceType" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <!-- A generic sequence of <any> for inclusion of external elements from external schema. --> <xsd:complexType name="AnySequenceType"> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> John. ----- Original Message -----
From: "Takahiro Miyamoto" <tk-miyamoto@kddilabs.jp> To: "John MacAuley" <john.macauley@surfnet.nl>, "Jerry Sobieski" <jerry@nordu.net> Cc: nsi-wg@ogf.org Sent: Wednesday, April 13, 2011 12:40:11 AM Subject: Re: [Nsi-wg] NSI CS XSD comments Hello John and Jerry,
I want to separate generic parameters from service-specific parameters. G-lambda interface introduced xsd:extension to inherit generic parameters in service-specific definition. Please find attached the sample xsd of general and service-specific definitions and the ppt describing parameter descriptions and usage scenario. By using xsd:extension, we don't need to list all service parameters in a xsd.
I want to explain and discuss this methodology in today's conf call.
Best regards, Takahiro
John MacAuley wrote:
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
-- Takahiro Miyamoto <tk-miyamoto@kddilabs.jp> Integrated Core Network Control And Management Laboratory KDDI R&D Laboratories, Inc. TEL: +81-49-278-7455 / FAX: +81-49-278-7811
[XML:OpticalServiceDefinition.xsd]
[XML:GeneralServiceDefinition.xsd]
[XML:EthernetServiceDefinition.xsd]
Hi John, By using <xsd:any>, it is difficult to define parameter names and data types explicitly. As Takefusa-san mentioned, in order for interoperability, we should define a standard schema as explicitly as possible. So, I prefer to use <xsd:extension>. Best regards, Takahiro John MacAuley wrote:
This is good input. Last month I had written up a version that used the <xsd:any> to allow for inclusion of technology and deployment specific elements not defined in the core schema. In this case you would have the parent schema that could include addition schema elements in the instance document. This is an inverse to the extension strategy, but perhaps a good way to include other concrete schemas?
<!-- 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:AnySequenceType" minOccurs="0"/> <xsd:element name="preferred" type="tns:AnySequenceType" minOccurs="0"/> </xsd:sequence> </xsd:complexType>
<!-- A generic sequence of <any> for inclusion of external elements from external schema. --> <xsd:complexType name="AnySequenceType"> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType>
John.
----- Original Message -----
From: "Takahiro Miyamoto" <tk-miyamoto@kddilabs.jp> To: "John MacAuley" <john.macauley@surfnet.nl>, "Jerry Sobieski" <jerry@nordu.net> Cc: nsi-wg@ogf.org Sent: Wednesday, April 13, 2011 12:40:11 AM Subject: Re: [Nsi-wg] NSI CS XSD comments Hello John and Jerry,
I want to separate generic parameters from service-specific parameters. G-lambda interface introduced xsd:extension to inherit generic parameters in service-specific definition. Please find attached the sample xsd of general and service-specific definitions and the ppt describing parameter descriptions and usage scenario. By using xsd:extension, we don't need to list all service parameters in a xsd.
I want to explain and discuss this methodology in today's conf call.
Best regards, Takahiro
John MacAuley wrote:
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 -- Takahiro Miyamoto <tk-miyamoto@kddilabs.jp> Integrated Core Network Control And Management Laboratory KDDI R&D Laboratories, Inc. TEL: +81-49-278-7455 / FAX: +81-49-278-7811
[XML:OpticalServiceDefinition.xsd]
[XML:GeneralServiceDefinition.xsd]
[XML:EthernetServiceDefinition.xsd]
-- Takahiro Miyamoto <tk-miyamoto@kddilabs.jp> Integrated Core Network Control And Management Laboratory KDDI R&D Laboratories, Inc. TEL: +81-49-278-7455 / FAX: +81-49-278-7811
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, Ph. D. Information Technology Research Institute, AIST
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
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.) 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
I agree with the bandwidth comment. I need to take some time tonight to understand the impact of extension on the schema. John. On 2011-04-13, at 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.)
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
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
participants (6)
-
Atsuko Takefusa -
Atsuko Takefusa -
Jeff W. Boote -
Jerry Sobieski -
John MacAuley -
Takahiro Miyamoto