- Nsi-wg - lists.ogf.org

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

Fwd: NSI meeting Wednesday morning (October 12th)
by Inder Monga 12 Oct '11

12 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 “#” > Agenda: > > 1. NSI roadmap: agree on a roadmap for new NSI features, draft roadmap > here: > https://docs.google.com/spreadsheet/ccc?key=0ApTOJNVUoixhdF9UYWNBTGNWeWRkZG… > > 2. Review open issues, agree resolution and assign work: > http://code.google.com/p/ogf-nsi-project/issues/list > 3. Preparation for demo at SC11 > > See you tomorrow. > > Inder >

1 0

Request for developer for NSI visualisation software
by Radek Krzywania 07 Oct '11

07 Oct '11

Hi all, For SC demonstration there is a need to have a centralised tool which will be able to show global reservation state and visualise the NSI demo topology. The first draft of such application will be required in about 4 weeks for Future Internet Week event held in Poznan between 24-28 Oct, where pre-SC NSI demo will be shown. During my discussion with Jerry Sobieski, we would like to propose the following specification for this visualisation tool: - A simple WebService needs to be implemented at network managers, which will allow to register event listeners (a WS addresses in fact), which will be the visualisation tool - NSI enabled network managers will notify listeners on all events regarding reservations (mostly reservation status change according to NSI reservation lifecycle model) - A visualisation tool will have a WS interface to receive the notifications from all domains involved in the demo - A visualisation tool will be able to show global status on the screen, possibly a topology map. It would be good if a reservation paths could be shown (either delivered by NSI implementations or "guessed" by a tool having knowledge on involved domains) The way of showing a view is a subject to discuss, it can be either a web page or an standalone application. The details should be clarified soon, at the beginning of the next week. As developers who are already involved in coding the NSI and their network managers, it will be best to find someone else dedicated especially for visualiser task. Jerry and I will appreciate any volunteering developers here, so please if you feel being able to write a simple tool to support with a little graphical interface for NSI demos, please rise your hand. In case of any questions, feel free to ask on mailing list or directly to me or Jerry. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

7 11

Keep those
by Henrik Thostrup Jensen 07 Oct '11

07 Oct '11

Hi Please remember to keep your NSI agents running and well-taken care of so people can test their implementations against yours. Here is a short reservation test result: OpenNSA WS reservation test client Network: Aruba Reservation created. Connection ID: urn:uuid:bcfa9dda-ea7b-11e0-9905-00144f20a8d2 Network: Bonaire Callback for call urn:uuid:bd0924e0-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Bonaire-OpenDRAC timed out. Network: Curacao Callback for call urn:uuid:c8f50fa8-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Curacao-AutoBAHN timed out. Network: Dominica Callback for call urn:uuid:d4e0feee-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Dominica-OSCARS timed out. Network: Grenada org.apache.cxf.binding.soap.SoapFault: Could not initialize class com.sun.xml.internal.ws.spi.ProviderImpl Network: Jamaica Reservation created. Connection ID: urn:uuid:e18453ee-ea7b-11e0-9905-00144f20a8d2 Network: Martinique Callback for call urn:uuid:e5561296-ea7b-11e0-9905-00144f20a8d2/reservation from urn:ogf:network:nsa:Martinique-DynamicKL timed out. Result: 2/7 succesfull registrations. Come on, we can do better :-). Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.

2 8

10 issues changed in ogf-nsi-project
by ogf-nsi-project＠googlecode.com 05 Oct '11

05 Oct '11

Updates: Labels: FixedInVersion-1.SC Comment by imo...(a)gmail.com: (No comment was entered for this change.) Affected issues: issue 1: ConnectionStateType.TERMINATEING - maybe TERMINATING looks better http://code.google.com/p/ogf-nsi-project/issues/detail?id=1 issue 2: GenericAcknowledgmentType http://code.google.com/p/ogf-nsi-project/issues/detail?id=2 issue 7: change reservation name in WSDL http://code.google.com/p/ogf-nsi-project/issues/detail?id=7 issue 15: XML/WSDL name spaces documentation needed http://code.google.com/p/ogf-nsi-project/issues/detail?id=15 issue 23: "NsiExceptionType" change to "serviceException" http://code.google.com/p/ogf-nsi-project/issues/detail?id=23 issue 24: ServiceException needs further details http://code.google.com/p/ogf-nsi-project/issues/detail?id=24 issue 25: Change 'reservation' primitive to 'reserve' http://code.google.com/p/ogf-nsi-project/issues/detail?id=25 issue 29: clarify usage of providerNSA and requesterNSA http://code.google.com/p/ogf-nsi-project/issues/detail?id=29 issue 34: time zones - document usage http://code.google.com/p/ogf-nsi-project/issues/detail?id=34 issue 38: push/pop attributes from SOAP layer - documenation http://code.google.com/p/ogf-nsi-project/issues/detail?id=38 -- You received this message because you are listed in the owner or CC fields of these issues, or because you starred them. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 41 in ogf-nsi-project: Do we replace the replyTo field with a topology/NSA configuration lookup?
by ogf-nsi-project＠googlecode.com 05 Oct '11

05 Oct '11

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 41 by jmacau...(a)gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 Description of Issue: At the moment we get the requestor endpoint information using the replyTo field in the SOAP message payload. We are looking up the csProviderEndpoint in the topology so should we also look up the requestor endpoint in a similar fashion? If we do use an external mapping mechanism then which fields do we use to perform this mapping (requesterNSA)? Discussion of Issue: Resolution of Issue:

2 2