October 2011 - Nsi-wg - lists.ogf.org

Re: [Nsi-wg] Issue 37 in ogf-nsi-project: xsd:integer or xsd:int ?
by ogf-nsi-project＠googlecode.com 19 Oct '11

19 Oct '11

Updates: Status: Started Comment #2 on issue 37 by jmacau...(a)gmail.com: xsd:integer or xsd:int ? http://code.google.com/p/ogf-nsi-project/issues/detail?id=37 If we switch to use xsd:int then the maximum bandwidth value will be 2,147,483,647 Mb/s. I think we are safe for the foreseeable future. :-)

1 2

Re: [Nsi-wg] Issue 27 in ogf-nsi-project: capitalisation of attribute names in WSDL
by ogf-nsi-project＠googlecode.com 19 Oct '11

19 Oct '11

Updates: Status: Fixed Labels: FixedWithUpdateR5 Comment #2 on issue 27 by jmacau...(a)gmail.com: capitalisation of attribute names in WSDL http://code.google.com/p/ogf-nsi-project/issues/detail?id=27 Renamed ServiceException element to serviceException as per issue #27. Closing issues #27 with update r5. ------------------------------------------------------------------------ r5 | jmacauley(a)gmail.com | 2011-10-14 16:30:54 -0400 (Fri, 14 Oct 2011) | 1 line Renamed NsiExceptionType to ServiceExceptionType as per issue #23. Renamed messageId to errorId in ServiceExceptionType as per Issue 24. Renamed ServiceException element to serviceException as per issue #27. Closing issues #23 and #27. Updating issue 24 ------------------------------------------------------------------------

1 1

NSI Call details for Wed October 19th
by Inder Monga 19 Oct '11

19 Oct '11

Hi all, The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Because I am not available, and neither is Guy, Chin/John will jointly run the call tomorrow. The focus of the call is: NSI 1.SC A few changes have been made to the WSDL and OGF issues resolved. One another thing to discuss is the topic for the next Wednesday call - I propose it be SECURITY. This next week session will not be a security tutorial - so please read-up ahead of time. We will invite security and NSI aware folks on the call. Hopefully that works for all of you. Hope you have a very productive session tomorrow, Inder -- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3><http://bit.ly/d2Olql>

1 0

FIA demo topo v1.1
by Jerry Sobieski 18 Oct '11

18 Oct '11

Hi all- Attached is topo .owl file v1.1. The corrections were many, but almost all were mistakes I had missed in the initial pass. - Changed "Pioneer" to "Pionier" - corrected several scProvider Endpoints - Corrected several STP references that were missing or incorrect. - Re-engineered JGN-X: JGNX is removed from the demo topology and AIST and KDDI Labs peer directly now with StarLight. (THis was due to no NSI version of OSCARS will be available at JGNX) Note: after this re-config, there are now only two SDPs linking StarLight & AIST (1780 & 1781), and likewise only two linking KDDI and StarLight (1782 & 1783). Everyone: Please! If you have not confirmed your csProviderEndpoint with me, please do so. THese are critical to the whole mechanism, and the only soap endpoints I have are the ones we used for Rio...need to make sure these are still correct. Note: there will be more changes, but the key topology elements are settling down now. The attached PPT reflects the basic demo topology and a slide about StarLight (for the StarLight engineers) Thanks. Questions/corrections to me. Jerry

4 4

Created ogf-nsi-cs-v1.sc branch
by John MacAuley 18 Oct '11

18 Oct '11

Peoples, As requested i did all the v1.SC updates outlined in the ogf-nsi-project issues list. I tried to submit one issue at a time as requested by Henrik, however some of them were related so I combined them into a single update. Go to the project web page and see how to download the branch @ http://code.google.com/p/ogf-nsi-project/source/browse/#svn%2Fbranches%2Fog… I noticed that the two wiki pages that had been created we now empty. No clue what happened. I ended up reseting the repository after I screwed things up with git. I switched over to subversion which I know how to use (a bit at least). I did two extra updates for open issues: Issue 34 - I created a timezone restriction on the xsd:dateTime. If you are using wsimport and Java there is no impact to code. Issue 37 - I changed the four occurrences of xsd:integer to xsd:int since it was a small change with minimal impact. Here is my update list: ------------------------------------------------------------------------ r8 | jmacauley(a)gmail.com | 2011-10-14 22:25:09 -0400 (Fri, 14 Oct 2011) | 1 line Branching from trunk to ogf-nsi-cs-v1.sc to provide a stable WSDL for SuperComputing demo. ------------------------------------------------------------------------ r7 | jmacauley(a)gmail.com | 2011-10-14 22:12:39 -0400 (Fri, 14 Oct 2011) | 1 line Changed all occurences of xsd:integer to xsd:int as requested in issue #37. Closing issue #37. ------------------------------------------------------------------------ r6 | jmacauley(a)gmail.com | 2011-10-14 17:03:57 -0400 (Fri, 14 Oct 2011) | 1 line Changed times in the form xsd:DateTime to be a new simpleType called DateTimeType that restricts dates to have a timezone or Z as requested in issue #34. closing issue #34. ------------------------------------------------------------------------ r5 | jmacauley(a)gmail.com | 2011-10-14 16:30:54 -0400 (Fri, 14 Oct 2011) | 1 line Renamed NsiExceptionType to ServiceExceptionType as per issue #23. Renamed messageId to errorId in ServiceExceptionType as per Issue 24. Renamed ServiceException element to ServiceException as per issue #27. Closing issues #23 and #27. Updating issue 24 ------------------------------------------------------------------------ r4 | jmacauley(a)gmail.com | 2011-10-14 15:18:20 -0400 (Fri, 14 Oct 2011) | 1 line Changed reservation message set to reserve as per issue #7. Closing issue #7. ------------------------------------------------------------------------ r3 | jmacauley(a)gmail.com | 2011-10-14 14:17:55 -0400 (Fri, 14 Oct 2011) | 1 line Added additional documentation around Acknowledgment handling as per issue #2. Updating issue #2. ------------------------------------------------------------------------ r2 | jmacauley(a)gmail.com | 2011-10-14 14:00:00 -0400 (Fri, 14 Oct 2011) | 1 line Renamed Terminateing state to Terminating. Closed issue #1. ------------------------------------------------------------------------ r1 | jmacauley(a)gmail.com | 2011-10-14 13:54:13 -0400 (Fri, 14 Oct 2011) | 1 line Adding wsdl from NSI Connection Services V1.Rio into trunk and a dedicated branch to maintain as a history. ------------------------------------------------------------------------ John.

3 9

NSA updates to ogf-nsi-cs-v1.sc
by John MacAuley 17 Oct '11

17 Oct '11

NSA owners, Let me know when you have upgrade your NSA to the new version of WSDL so that we can perform integration. Thank you, John.

1 0

Re: [Nsi-wg] Issue 36 in ogf-nsi-project: STP list
by ogf-nsi-project＠googlecode.com 17 Oct '11

17 Oct '11

Updates: Status: WontFix Comment #3 on issue 36 by jmacau...(a)gmail.com: STP list http://code.google.com/p/ogf-nsi-project/issues/detail?id=36 I am closing this issue. Adding the order attribute is the only way to guarantee the original ordering of an array of like elements modelled in a <sequence>. For example, in the "StpListType" definition we have a single element definition that may have multiple instances. The XML/XSD specifications do not explicitly state that the instances of "stp" must be in original programatic order, just that they must exist. <xsd:complexType name="StpListType"> <xsd:sequence> <xsd:element name="stp" type="tns:OrderedServiceTerminationPointType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> In JAX-WS this results in a List<OrderedServiceTerminationPointType> being created. The Java List<E> interface guarantees ordering based on positional insertion. However, other implementations may not use a structurally ordered type (i.e. Map), and therefore, original programatic order is not guaranteed. I believe the specification does indicate that different <elements> in a <sequence> must be ordered. For example, in PathType below directionality must occur before sourceSTP, sourceSTP before destSTP, etc. <xsd:complexType name="PathType"> <xsd:sequence> <xsd:element name="directionality" type="tns:DirectionalityType" default="Bidirectional"/> <xsd:element name="sourceSTP" type="tns:ServiceTerminationPointType" /> <xsd:element name="destSTP" type="tns:ServiceTerminationPointType" /> <xsd:element name="stpList" type="tns:StpListType" minOccurs="0" /> </xsd:sequence> </xsd:complexType> If anyone can find a specific standard-based definition the proves me wrong I will make the change.

1 0

FIA-SC demo topology v1.0a
by Jerry Sobieski 16 Oct '11

16 Oct '11

Hi all- Here is the FIA demo topology. I include two files: a PPT diagram, and the .owl topo file. Please review both of these files to insure that the information associated with your network(s) is accurate. As we did before, I will maintain the authoritative versions of the global topology, so please forward corrections or changes to me. The FIA-Topo-v1.0a.owl is a rather complex file. I did not construct it using the SNE editor and it does not display in the editor either...I will try to figure out why, but this should not prevent you from reviewing it and insuring it is correct - and using it. The .owl file does not yet contain the "location" objects. I have included what I could in the PPT diagram for location in lat/lon, so check the location info for accuracy. I will add location to the next spin of the topo file. Please check the csProviderEndpoint fields for your network NSAs in the .owl file. This must be correct, and I know there will be some changes required for these. The networks are named as one would expect with the ".ets" appended for "ethernet transport service". Ex: northernlight.ets The associated NSAs are identified with just the netork name Ex: northernlight Of course, these are full URNs in the topo file. For the demo, I have only anticipated using VLANs 1780 thru 1783. The STPs are named using a convention that will indicate the associated VLAN mapping for human readability. Example STP: starlight.ets:tok-80 would indicate the VLAN 1780 on the port facing Tokyo in the StarLight network. The "mapsTo" relation should be used in each STP to store the information the local NRM needs to configure that endpoint. *you* must add the mapsTo information for your STPs. If you wish, I can maintain it in the global .owl file - just send me the your STPs with the mapsTo info and I will add it on the next cycle (hopefully, this will minimize what you need to do each time the topo gets updated.) I included perfSonar STPs for every network, even if there was not one indicated on the diagram. This topology information is what we would ideally like the hardware to reflect. So please insure that these VLANs are mapped transparently between the AutoGOLE switches across any intervening hardware. I expect in some facilities this will require physicaly adding patches or otherwise making some modifications. But it is important that we have full access to these VLANs without hidden constraints imposed by transit hardware not under our NSA control. Please let me know of necessary changes. I will cycle important global changes as quickly as possible. From here on out, I will only forward updates to the *nsi-plugfest* list in order to reduce duplicate spamming. Thanks all! Jerry

1 0

Re: [Nsi-wg] Issue 25 in ogf-nsi-project: Change 'reservation' primitive to 'reserve'
by ogf-nsi-project＠googlecode.com 14 Oct '11

14 Oct '11

Updates: Status: Fixed Labels: FixedWithUpdateR4 Comment #4 on issue 25 by jmacau...(a)gmail.com: Change 'reservation' primitive to 'reserve' http://code.google.com/p/ogf-nsi-project/issues/detail?id=25 Fixed when renaming of "reservation" to "reserve" occurred in update r4. ------------------------------------------------------------------------ r4 | jmacauley(a)gmail.com | 2011-10-14 15:18:20 -0400 (Fri, 14 Oct 2011) | 1 line Changed reservation message set to reserve as per issue #7. Closing issue #7. ------------------------------------------------------------------------

1 0

Discussion on NSI error handling.
by John MacAuley 12 Oct '11

12 Oct '11

Peoples, I took and action to start the error handling discussion so that we, as a group, can document the error messages and behaviors. I would like to start it off with when an NSIServiceException is returned as a SOAP fault to a request, and when it is returned in a specific failed response message. OpenDRAC used the strategy of validating a “key” set of attributes in the request before returning an ACK response or SOAP fault. This gives OpenDRAC the opportunity to validate parameters needed to accept the message for processing, and possibly return the asynchronous failed message at a later time. Here is the list of parameters I will validate in a reservation message and return a SOAP fault if they are incorrect or missing. HTTP authentication – if you don’t have valid credentials you are rejected with an HTTP 40x message. correlationId - needed for any acknowledgment, confirmation, or failed message. Must be unique within the context of the providerNSA otherwise the request cannot be accepted. replyTo - we will send the confirmation, or failed message back to this location. We do not validate the contents of the endpoint, just that it exists. Reservation – if the reservation parameters are not present then we reject. requesterNSA and providerNSA – must be present and resolve to an NsNetwork in topology. Also, the providerNSA must be the NsNetwork OpenDRAC is managing or we reject the message. connectionId – this is used as the primary reference attribute for reservation state machines and must be present. If any of these fields are missing or invalid OpenDRAC will return a SOAP fault containing the NSIServiceException set to an appropriate error message. Here is a list of error messages currently implemented in OpenDRAC. The list continues to expand. I have kept the text generic with the specific error values being returned in the associated attribute list. We will also need to agree on the format of the message/errorId. MISSINGPARAMETER, “SVC0001", "Invalid or missing parameter" UNSUPPORTEDOPTION, “SVC0002", "Parameter provided contains an unsupported value which MUST be processed" ALREADYEXISTS, “SVC0003", "Schedule already exists for connectionId" DOESNOTEXISTS, "SVC0004", "Schedule does not exists for connectionId" MISSINGSECURITY, “SVC0005", "Invalid or missing user credentials" TOPOLOGYRESOLUTION_STP, "SVC0006", "Could not resolve STP in Topology database" TOPOLOGYRESOLUTION_STP_NSA, SVC0007", "Could not resolve STP to managing NSA" PATHCOMPUTATION_NO_PATH, “SVC0008", "Path computation failed to resolve route for reservation" INVALIDSTATE, “SVC0009", "Connection state machine is in invalid state for received message" INTERNALERROR, "SVC0010", "An internal error has cause a message processing failure" Would people like to add to the list? Comments? John.

1 0