[Nsi-wg] The massive NSI-CS 2.0 WSDL revision is complete
Atsuko Takefusa
takefusa at acm.org
Thu Sep 20 03:51:08 EDT 2012
Hi John,
Thank you for your great work for WSDL.
I have small questions or suggestions as follows:
* ogf_nsi_connection_requester_v2_0.wsdl (It's not v. 2 problem...)
Is Requester's "query" service operation actually required?
If the requester is not uRA, it must be implemented provider wsdl, too.
if the requester is uRA, what kind of queries does the uRA has to respond?
* ogf_nsi_connection_interface_v2_0.wsdl:129:
<!-- ********** Acknowledgement type definition ********** -->
Acknowledg*e*ment ==> Acknowledgment
* ogf_nsi_connection_types_v2_0.xsd:356: <xsd:element
name="globalReservationId" type="tns:GlobalReservationIdType"
nillable="true" />
In this case, I prefer 'minOccurs="0"' rather than 'nillable="true"',
as you specified in the other nillable elements.
Best regards,
Atsuko
2012/9/19 John MacAuley <john.macauley at surfnet.nl>:
> That is close to how it is now, and has been pretty much the same since 1.0. I modified the hierarchy a bit, and changed the attribute "name" to "type" since everyone wanted "type".
>
> <reservation>
> <globalReservationId> </globalReservationId>
> <description> </description>
> <connectionId> </connectionId>
> <criteria>
> <schedule>
> <startTime> </startTime>
> <endTime> </endTime>
> </schedule>
> <serviceAttributes>
> <attribute>
> <namespace>P2PCS</namespace>
> <type>bandwidth</type>
> <value>1000</value>
> </attribute>
> <namespace>P2PCS</namespace>
> <type>jitter</type>
> <value>2</value>
> </attribute>
> </serviceAttributes>
> <path>
> <directionality> </directionality>
> <symmetric> </symmetric>
> <sourceSTP> </sourceSTP>
> <destSTP> </destSTP>
> <ero> </ero>
> </path>
> </criteria>
> </reservation>
>
> On 2012-09-19, at 9:25 AM, Jerry Sobieski wrote:
>
>> Here is how I had envisioned it:
>>
>> <ResvReq>
>> <serviceType> P2PCS </serviceType>
>> <sourceSTP> [STP name with TV pairs] </sourceSTP>
>> <destSTP> [STP name TV pairs] </destSTP>
>> <ero>
>> <hop> [STP name TV pairs] </hop>
>> <hop> [STP name TV pairs] </hop>
>> <hop> [STP name TV pairs] </hop>
>> ...
>> </ero>
>> <serviceSpecificParameters>
>> (These parameter names defined in the Service definition for <serviceType>-- see note below)
>> <bandwidth> 100 Mbps </bandwidth>
>> <jitter> 2 ms </jitter>
>> ...
>> </serviceSpecificParameters>
>> <schedule>
>> <startTimeDate>...</startTimeDate>
>> <endTimeDate> ... </endTimeDate>
>> </schedule>
>> <authorization>
>> ...
>> </authorization>
>> </ResvReq>
>>
>> I know this is not WSDL code, but it should describe the basic structure as I believe we have agreed. Of course John's WSDL may be slightly different, but the key points are that the Resv Req identifies the service of interest, and the service specific paramters can be derived from the common service definition for that service type.
>>
>> For V2 - I recommend we use a single (possibly hard coded) service type - say "P2PCS" (Point to Point Connection Service) and define the paramters associated with that service for V2. We can open up more dynamic service definitions in the next/later NSI release. THis should expedite the NSIv2 progress.
>>
>> Thoughts?
>> Jerry
>>
>> On 9/19/12 12:19 PM, John MacAuley wrote:
>>> I dropped bandwidth on purpose since it is service description value and would be specified in the service attribute type value pairs with other service definition attributes. I believe Jerry has be referring to it as "capacity".
>>>
>>> Thank you,
>>> John
>>>
>>> Thumb typed on my iPad.
>>>
>>> On 2012-09-19, at 6:16 AM, Guy Roberts <Guy.Roberts at dante.net> wrote:
>>>
>>>> Hi John,
>>>>
>>>> I apologise - the bandwidth attribute got accidentally dropped out of the STP proposal document. This needs to be added back in as a mandatory element in 'PathType' in as was in v1.1 WSDL.
>>>>
>>>> So Path elements are as follows:
>>>>
>>>> bandwidth - the desired bandwidth of the service in Mb/s.
>>>> symmetric - Optional Boolean. Pathfinding constraint that requires that the go and return paths should take the same route (relevant to bidirectional connections only)
>>>> directionality - (uni or bi) directionality of the service.
>>>> sourceSTP - Source STP of the service.
>>>> destSTP - Destination STP of the service.
>>>> stpList - Hop-by-hop ordered list of STP from sourceSTP to destSTP. List does not include sourceSTP and destSTP.
>>>>
>>>> Guy
>>>>
>>>> -----Original Message-----
>>>> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of Tomohiro Kudoh
>>>> Sent: 19 September 2012 09:45
>>>> To: NSI Working Group
>>>> Subject: Re: [Nsi-wg] The massive NSI-CS 2.0 WSDL revision is complete
>>>>
>>>> Hello John,
>>>>
>>>> Thank you very much for making the WSDL. I really appreciate your hard work.
>>>>
>>>> I have a few questions:
>>>>
>>>> 1. GenericAcknowledgmentType
>>>>
>>>> In v1, all requests return GenericAcknowledgmentType. In v2, when we look at Java generated from the WSDL, Provider's queryConfirmed and Requester's queryConfirmed, reserveConfirmed and modifyCheckConfirmed returns GenericAcknowledgmentType but otheres do not. Is this an intended behavior?
>>>>
>>>> Both Apache CXF 2.5.2 and 2.6.2 generated such code.
>>>>
>>>> 2. Bandwidth
>>>> How can a bandwidth be specified in a reservation request?
>>>>
>>>> 3. Warning from wsdl2java
>>>> wsdl2java of Apache CXF 2.6.2 (which is the latest) generates the following warnings.
>>>> Is it ok to ignore them?
>>>>
>>>> [java] wsdl2java -b gnswsi3/gnswsi3_jaxb_bindings.xml -verbose -d java/nsi2/common/build/src -frontend jaxws21 file:nsi2/ogf_nsi_connection_provider_v2_0.wsdl
>>>> [java] wsdl2java - Apache CXF 2.6.2
>>>> [java]
>>>> [java] Sep 19, 2012 3:45:17 PM org.apache.cxf.tools.common.ToolErrorListener addWarning
>>>> [java] WARNING: schema/nsi2/xenc-schema.xsd [27,7]: src-resolve: Cannot resolve the name 'ds:KeyInfo' to a(n) 'element declaration' component.
>>>> [java] Sep 19, 2012 3:45:17 PM org.apache.cxf.tools.common.ToolErrorListener addWarning
>>>> [java] WARNING: schema/nsi2/ogf_nsi_connection_interface_v2_0.wsdl [0,0]: src-resolve.4.2: Error resolving component 'ftypes:ServiceExceptionType'. It was detected that 'ftypes:ServiceExceptionType' is in namespace 'http://schemas.ogf.org/nsi/2012/03/framework/types', but components from this namespace are not referenceable from schema document 'file:schema/nsi2/ogf_nsi_connection_interface_v2_0.wsdl#types1'. If this is the incorrect namespace, perhaps the prefix of 'ftypes:ServiceExceptionType' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:schema/nsi2/ogf_nsi_connection_interface_v2_0.wsdl#types1'.
>>>> [java] Sep 19, 2012 3:45:17 PM org.apache.cxf.tools.common.ToolErrorListener addWarning
>>>> [java] WARNING: schema/nsi2/ogf_nsi_framework_headers_v2_0.xsd [79,13]: src-resolve: Cannot resolve the name 'saml:AttributeStatementType' to a(n) 'type definition' component.
>>>>
>>>> Thanks,
>>>>
>>>> Tomohiro
>>>>
>>>> On Tue, 18 Sep 2012 21:51:15 -0400
>>>> John MacAuley <john.macauley at surfnet.nl> wrote:
>>>>
>>>>> ... well, at least the first cut at it. I think I managed to cover everything agreed up to this point. Code is in the trunk.
>>>>>
>>>>> State machine is still a little iffy, but I did my best.
>>>>>
>>>>> The Modify operations are added.
>>>>>
>>>>> Reservations are now versioned.
>>>>>
>>>>> Added a generic notification message that carries a number of new notifications for activation. Folded forcedEnd in to this as well.
>>>>>
>>>>> Updated PathList and STP definitions to follow approved proposal.
>>>>> - Changed path to ero.
>>>>> - Included new optional "symmetric" element to PathType to constrain bidirectional connections.
>>>>> - STP is not composed of networkId, localId, an optional label, and an optional orientation to indicated ingress or egress of bidirectional connections.
>>>>>
>>>>> Removed "nilable" from globalReservationId and made it optional to follow the design pattern of all other types.
>>>>>
>>>>> Collapsed ServiceParametersType - moved schedule and serviceAttributes into ReservationInfoGroup instead of having them in a subtype.
>>>>>
>>>>> Restructured the query results to fix open issues.
>>>>>
>>>>> Some other minor changes I can't remember.
>>>>>
>>>>> John.
>>>>> _______________________________________________
>>>>> nsi-wg mailing list
>>>>> nsi-wg at ogf.org
>>>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>>>
>>>> _______________________________________________
>>>> nsi-wg mailing list
>>>> nsi-wg at ogf.org
>>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>>>
>>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
More information about the nsi-wg
mailing list