December 2013 - Nsi-wg - lists.ogf.org

minutes from today's NSI conf call...
by Guy Roberts 12 Dec '13

12 Dec '13

... can be found here: https://redmine.ogf.org/dmsf_files/13174 _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

3 4

Fwd: ICCCN 2014: Call for Paper Distribution
by Inder Monga 12 Dec '13

12 Dec '13

Sorry if this is a duplicate message! Inder ---------- Forwarded message ---------- From: ICCCN 2014 <icccn2014(a)easychair.org> Date: Wed, Dec 11, 2013 at 9:32 PM Subject: ICCCN 2014: Call for Paper Distribution To: Inder Monga <imonga(a)es.net> Dear ICCCN 2014 TPC members, We would like to request for your help in advertising the ICCCN 2014 call for papers. Attached is a text version of the call for papers for ICCCN 2014. Please forward it to your friends and colleagues, and see if they'd be interested in submitting papers to the conference. We's also appreciate if you could help us out with the publicity by sending out personal emails to folks you know inviting them to submit papers to the conference. Lastly, you are all welcome and encouraged to submit your papers to the conference. Best regards, Lisong Xu & Pavan Balaji ICCCN 2014 PC co-chairs *************************************************************************** * The 23rd Intl. Conf. on Computer Communication and Networks (ICCCN '14) * * CALL FOR PAPERS * * August 4 to August 7, 2014. Shanghai, China * * http://www.icccn.org/icccn14/ * *************************************************************************** ICCCN is one of the leading international conferences for presenting novel ideas and fundamental advances in the fields of computer communications and networks. ICCCN serves to foster communication among researchers and practitioners with a common interest in improving computer communications and networking through scientific and technological innovation. ICCCN 2014 is technically co-sponsored by the IEEE Communication Society. The proceedings of ICCCN will be published in IEEE Xplore and is EI indexed. Papers of special merit will be selected for possible fast track publication in the Computer Communications (COMCOM) journal (http://www.journals.elsevier.com/computer-communications/) which is indexed by SCI. Scope: ====== The primary focus of the conference is on new and original research results in the areas of design, implementation, and applications of computer communications and networks. Topics of interest include, but are not limited to, the following: - Cognitive, Cellular and Mobile Networks (CCM) - Comm. Architecture, Algorithms, Modeling and Evaluation (CAAME) - Data Centers and Big Data Computing (DCBC) - Green Networks and Sustainable Computing (GREEN) - Grid, Cloud, Internet and Peer-to-peer Computing and Comm. (GCIP) - Multimedia and Real-Time Networking (MRN) - Security, Privacy, and Trust (SPT) - Sensor/Embedded Networks and Pervasive Computing (SNPC) - Software Defined Networks and Network Testing and Deployment (SDN) - Wireless LAN, Ad Hoc, and Mesh Networks (WAM) Instructions for Authors: ========================= Submitted manuscripts must be formatted in standard IEEE camera-ready format (double-column, 10-pt font) and must be submitted via EasyChair (http://www.easychair.org/) as PDF files (formatted for 8.5x11-inch paper). Manuscripts submitted for review should be no longer than 8 pages. Submitted papers should not be previously published in or be under consideration for publication in another conference or journal. Paper titles and/or author names cannot be changed and/or added to the papers once papers are submitted to ICCCN 2014 for review. The Program Committee reserves the right to not review papers that either exceed the length specification or have been submitted or published elsewhere. Submissions must include a title, abstract, keywords, author(s) and affiliation(s). A paper abstract must be registered on EasyChair by the deadline indicated below. For the final camera-ready version, accepted papers are permitted to purchase two additional pages at an over-length charge at the time of publication (camera-ready manuscripts should not exceed 10 pages in total). Review and Publication of Manuscripts: ====================================== Submitted papers will be reviewed by the TPC and judged on originality, technical correctness, relevance, and quality of presentation. An accepted paper must be presented at the conference venue by one of the authors registered at the full registration rate. Each full registration covers up to two papers authored by the registered author. Accepted and presented papers (by one of authors) will be published in the conference proceedings and submitted to IEEE Xplore as well as other Abstracting and Indexing (A&I) databases including EI. Note that each accepted paper must be presented by one of authors to be included in the IEEE Xlpore. Papers of special merit will be selected for possible fast track publication in the Computer Communications (COMCOM) journal (http://www.journals.elsevier.com/computer-communications/) which is indexed by SCI. Workshops: ========== Please note that the page limit for the workshop program is different. The review version should be no longer than 6 pages. The camera-ready version can have up to two additional pages if the authors pay an over-length charge at the time of publication (camera-ready manuscripts should not exceed 8 pages in total). The detailed info can be found in the workshop Call for Papers. For any questions or additional information, please contact the General, TPC, or Workshop Chairs. If you are interested in organizing a workshop, please contact the workshop chairs. Important dates: ================ Abstract Due: February 17, 2014 Paper Due: February 24, 2014 Acceptance Notification: April 23, 2014 Camera Ready Due: May 12, 2014 General Chairs: =============== Changjun Jiang, Tongji University, China Xiaobo Zhou, University of Colorado, Colorado Springs, USA Program Chairs: =============== Pavan Balaji, Argonne National Laboratory, USA Lisong Xu, University of Nebraska-Lincoln, USA Workshop Chairs: ================ Aaron Striegel, University of Notre Dame, USA Zhihui Du, Tsinghua University, China

1 0

Wednesday's NSI conf call
by Guy Roberts 11 Dec '13

11 Dec '13

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: - Finalizing NSI CS document - NSI extensions document progress - Aligning NSI and NML terminology _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

4 4

STP Identifier
by John MacAuley 11 Dec '13

11 Dec '13

Peoples, While the discussion over opaqueness occurs on a separate thread I though I would communicate what I have done for the final version of the NSI CSv2. <xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" /> <xsd:element name="stpId" type="xsd:string" /> </xsd:sequence> </xsd:complexType> I defined a single string STP identifier as specified by Jeroen in his NSI-EXT documentation. I have also included a separate networkId in the request to allow for routing by network only. The only additional thought I have is to make the networkId optional so if at some point in the future we decide to allow parsing of the stpId for the networkId, the individual networkId field will no longer be required. John

2 1

NSI CS v2.0 Final Candidate
by John MacAuley 06 Dec '13

06 Dec '13

Peoples, Today I submitted the final changes for NSI CS v2.0 and branched the candidate schema. The trunk and ogf-nsi-cs-v2_0.final branch are currently in synch and will maintain this until we close off the review period for 2.0. You can find the candidate schema under the following URL: https://ogf-nsi-project.googlecode.com/svn/branches/ogf-nsi-cs-v2_0.final/C… I have incorporated feedback received over the last two weeks, verified that the schema compiled, and that the correct interfaces are created. I have also updated the namespace URLs to reflect that this is the final version. This will help with compatibility when upgrading the existing NSA. Tomorrow I will be incorporating the changes into the NSI CS 2.0 documentation and close of my activities on that as well. John

3 2

NORDUnet and SURFnet are moving to production
by Hans Trompert 05 Dec '13

05 Dec '13

Hi, I have told this in one on one discussions with a lot of people already, but I think it is good if I repeat it here as well: The NORDUnet/SURFnet initiative to do a NSI based production grade multi-domain BoD implementation is driven by the need to finally have such a service out there. We would have loved to base it on a final NSI CS 2.0 and NSI Topology Description Format and NSI Topology Exchange Service, but the topics discussed in the NSI and NML WGs are not easily tackled and take a lot more time than everybody hoped and wished for. In my opinion it is much better to have running code early on to help people better understand the problems that are being discussed and the solutions that are being proposed. So please see this initiative as our way of contributing to this process. We will continuously share our experiences with the WGs in the hope that it will contribute to even better final standards. And to be clear on this, we do not intend or even want to make the decisions for the WGs, we just need to make our own decisions now to get a first real deployment done. In due course it is likely that we we will move to the final NSI and NML WG standards once they are finished. HansT.

1 0

NSI Topology
by John MacAuley 05 Dec '13

05 Dec '13

Peoples, As promised I have done a first pass at modelling the additional NSI topology concepts in NML. I did an overview of all the components we have defined to date so we can see how they all hang together. The slide pack attached is an overview of the proposal. The XML document attacked is an updated reference topology representation, and the schema files attached are the updated NML, NSI-EXT, and service definition schemas. John

2 2

NML requirements for NSI
by Freek Dijkstra 04 Dec '13

04 Dec '13

Dear members of the NML and NSI group, The NSI group has expressed desire for NML features behind the current state, and also is discussing which subset of NML is applicable for NSI. Immediately after after publication of the base draft, some members of the NML group (iincluding myself) seem to have suffered from a little standardisation-fatigue, but I see renewed interest at the moment. To get this effort going, I propose the following: 1. Assess what needs to be done on the mailing list 2. Schedule a conference call to decide which activities have priority and who is interested 3. Decide the best structure to get this going, which groups and which people are responsible (I know that Martin Swany and myself have not been very active lately, so I'm open for suggestions). For the conference call date, please fill in http://doodle.com/gsunb8iiycnimh4r (please check the time-zone in the top right corner, I picked 7:00 and 15:00 UCT, so it is equally horrible in Tokyo, London, Amsterdam and San Francisco time zones) Thanks! Freek -- SURFsara has a new telephone number: + 31 20 800 1300. Freek Dijkstra | Group Leader | Network Innovation & Support | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 20 800 1320 | | Freek.Dijkstra(a)surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |

1 1

Fwd: [ogf-nsi-project] r108 committed - Submitting changes not yet commited.
by John MacAuley 04 Dec '13

04 Dec '13

I submitted update r108 that includes the updates contained in the two attached slide packages that we went over last week. For the attached notification package. please start reading @ slide 14. John Begin forwarded message: > From: ogf-nsi-project(a)googlecode.com > Subject: [ogf-nsi-project] r108 committed - Submitting changes not yet commited. > Date: 4 December, 2013 10:07:40 AM EST > To: john.macauley(a)surfnet.nl > > Revision: 108 > Author: jmacauley > Date: Wed Dec 4 15:07:03 2013 UTC > Log: Submitting changes not yet commited. > http://code.google.com/p/ogf-nsi-project/source/detail?r=108 > > Modified: > /trunk/ConnectionService/a-gole-sd.xml > /trunk/ConnectionService/ogf_nsi_connection_types_v2_0.xsd > /trunk/ConnectionService/ogf_nsi_framework_headers_v2_0.xsd > /trunk/ConnectionService/ogf_nsi_services_definition_v2_0.xsd > /trunk/ConnectionService/ogf_nsi_services_p2p_v2_0.xsd > /trunk/ConnectionService/ogf_nsi_services_types_v2_0.xsd > > ======================================= > --- /trunk/ConnectionService/a-gole-sd.xml Tue Sep 17 07:59:19 2013 UTC > +++ /trunk/ConnectionService/a-gole-sd.xml Wed Dec 4 15:07:03 2013 UTC > @@ -42,171 +42,172 @@ > --> > <schema name="evts" required="true" > namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://schemas.ogf.org/nsi/2013/07/services/point2point}EthernetVlanType"/> > - > -  > - <parameter name="capacity" units="Mbps" required="true" modifiable="true" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://www.w3.org/2001/XMLSchema}int"> > - <comment> > - Capacity is defined to be the average quantity of data that will be > - guaranteed to be transported per unit time from ingress to egress, > - normalized to 1 second. The "capacity" for the EVTS instance > - includes the ethernet frame header(s) but does not include sync > - bits or any inter-frame gap considerations. Further, the EVTS > - "capacity" attribute does not include any additional headers that > - may be applied in transit. > - </comment> > - <minInclusive>0</minInclusive> > - <maxInclusive>100000</maxInclusive> > - <increment>1</increment> > - </parameter> > - > -  > - <parameter name="directionality" required="false" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://schemas.ogf.org/nsi/2013/07/services/types}DirectionalityType"> > - <comment> > - Directionality specifies whether the Connect requested is to be a > - "unidirectional" or "bidirectional" circuit. The implications for > - unidirectional are fairly obvious. However for bidirectional > - connections the STPs must be defined as bi-directional. Note: > - there may be ambiguity in certain topological scenarios where the > - routing of the connection may not be clear. > - </comment> > - <default>Bidirectional</default> > - </parameter> > - > -  > - <parameter name="symmetricPath" required="false" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://www.w3.org/2001/XMLSchema}boolean"> > - <comment> > - An indication that both directions of a bidirectional circuit must > - follow the same path. Only applicable when directionality is > - "Bidirectional". If not specified then value is assumed to be false. > - </comment> > - <default>false</default> > - </parameter> > - > -  > - <parameter name="sourceSTP" required="true" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://schemas.ogf.org/nsi/2013/07/services/types}StpType"> > - <comment> > - Source STP of the service. > - </comment> > - </parameter> > - > - <parameter name="destSTP" required="true" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://schemas.ogf.org/nsi/2013/07/services/types}StpType"> > - <comment> > - Destination STP of the service. > - </comment> > - </parameter> > - > - <parameter name="ero" required="false" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://schemas.ogf.org/nsi/2013/07/services/types}StpListType"> > - <comment> > - Hop-by-hop ordered list of STP from sourceSTP to destSTP. List does not include > - sourceSTP and destSTP. > - </comment> > - </parameter> > - > - <parameter name="mtu" units="bytes" required="false" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://www.w3.org/2001/XMLSchema}int"> > - <comment> Specifies the maximum transmission unit size in bytes. </comment> > - <minInclusive>1500</minInclusive> > - <maxInclusive>9000</maxInclusive> > - <increment>1</increment> > - <default>9000</default> > - </parameter> > - > - <parameter name="burstsize" units="bytes" required="false" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://www.w3.org/2001/XMLSchema}int"> > - <comment> > - Burstsize describes the maximum amount of data that the ingress STP > - will accept in a single sequence of packets at line rate of that > - STP. Bursts must be separated by a long enough quiescent period for > - the average long term rate of data transfer is within the capacity > - limits. Packets exceeding this burst profile are policed and will > - be immediately dropped when detected. > - </comment> > - <minInclusive>0</minInclusive> > - <maxInclusive>100000000000</maxInclusive> > - <increment>1</increment> > - </parameter> > +  > + <parameter name="capacity" units="Mbps" required="true" modifiable="true" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://www.w3.org/2001/XMLSchema}int"> > + <comment> > + Capacity is defined to be the average quantity of data that will be > + guaranteed to be transported per unit time from ingress to egress, > + normalized to 1 second. The "capacity" for the EVTS instance > + includes the ethernet frame header(s) but does not include sync > + bits or any inter-frame gap considerations. Further, the EVTS > + "capacity" attribute does not include any additional headers that > + may be applied in transit. > + </comment> > + <minInclusive>0</minInclusive> > + <maxInclusive>100000</maxInclusive> > + <increment>1</increment> > + </parameter> > + > +  > + <parameter name="directionality" required="false" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://schemas.ogf.org/nsi/2013/07/services/types}DirectionalityType"> > + <comment> > + Directionality specifies whether the Connect requested is to be a > + "unidirectional" or "bidirectional" circuit. The implications for > + unidirectional are fairly obvious. However for bidirectional > + connections the STPs must be defined as bi-directional. Note: > + there may be ambiguity in certain topological scenarios where the > + routing of the connection may not be clear. > + </comment> > + <default>Bidirectional</default> > + </parameter> > + > +  > + <parameter name="symmetricPath" required="false" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://www.w3.org/2001/XMLSchema}boolean"> > + <comment> > + An indication that both directions of a bidirectional circuit must > + follow the same path. Only applicable when directionality is > + "Bidirectional". If not specified then value is assumed to be false. > + </comment> > + <default>false</default> > + </parameter> > + > +  > + <parameter name="sourceSTP" required="true" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://schemas.ogf.org/nsi/2013/07/services/types}StpType"> > + <comment> > + Source STP of the service. > + </comment> > + </parameter> > + > + <parameter name="destSTP" required="true" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://schemas.ogf.org/nsi/2013/07/services/types}StpType"> > + <comment> > + Destination STP of the service. > + </comment> > + </parameter> > + > + <parameter name="ero" required="false" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://schemas.ogf.org/nsi/2013/07/services/types}StpListType"> > + <comment> > + Hop-by-hop ordered list of STP from sourceSTP to destSTP. List does not include > + sourceSTP and destSTP. > + </comment> > + </parameter> > + > + <parameter name="mtu" units="bytes" required="false" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://www.w3.org/2001/XMLSchema}int"> > + <comment> Specifies the maximum transmission unit size in bytes. </comment> > + <minInclusive>1500</minInclusive> > + <maxInclusive>9000</maxInclusive> > + <increment>1</increment> > + <default>9000</default> > + </parameter> > + > + <parameter name="burstsize" units="bytes" required="false" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://www.w3.org/2001/XMLSchema}int"> > + <comment> > + Burstsize describes the maximum amount of data that the ingress STP > + will accept in a single sequence of packets at line rate of that > + STP. Bursts must be separated by a long enough quiescent period for > + the average long term rate of data transfer is within the capacity > + limits. Packets exceeding this burst profile are policed and will > + be immediately dropped when detected. > + </comment> > + <minInclusive>0</minInclusive> > + <maxInclusive>100000000000</maxInclusive> > + <increment>1</increment> > + </parameter> > + > + <parameter name="sourceVLAN" required="true" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://www.w3.org/2001/XMLSchema}int"> > + <comment> > + The VLAN identifier must be in the range 1780 - 1783. > + </comment> > + <minInclusive>1780</minInclusive> > + <maxInclusive>1783</maxInclusive> > + <increment>1</increment> > + </parameter> > + > + <parameter name="destVLAN" required="true" modifiable="false" > + namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > + type="{http://www.w3.org/2001/XMLSchema}int"> > + <comment> > + The VLAN identifier must be in the range 1780 - 1783. > + </comment> > + <minInclusive>1780</minInclusive> > + <maxInclusive>1783</maxInclusive> > + <increment>1</increment> > + </parameter> > + </schema> > > - <parameter name="sourceVLAN" required="true" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://www.w3.org/2001/XMLSchema}int"> > - <comment> > - The VLAN identifier must be in the range 1780 - 1783. > - </comment> > - <minInclusive>1780</minInclusive> > - <maxInclusive>1783</maxInclusive> > - <increment>1</increment> > - </parameter> > - > - <parameter name="destVLAN" required="true" modifiable="false" > - namespace="http://schemas.ogf.org/nsi/2013/07/services/point2point" > - type="{http://www.w3.org/2001/XMLSchema}int"> > - <comment> > - The VLAN identifier must be in the range 1780 - 1783. > - </comment> > - <minInclusive>1780</minInclusive> > - <maxInclusive>1783</maxInclusive> > - <increment>1</increment> > - </parameter> > - >  > <attribute name="framing" type="IEEE 802.1Q Trunk"> > ======================================= > --- /trunk/ConnectionService/ogf_nsi_connection_types_v2_0.xsd Fri Sep 13 14:34:02 2013 UTC > +++ /trunk/ConnectionService/ogf_nsi_connection_types_v2_0.xsd Wed Dec 4 15:07:03 2013 UTC > @@ -73,12 +73,12 @@ > information collected by recursively traversing the reservation > tree. > > - 11. QueryNotification - Mechanism for a requester NSA to query the > + 11. queryNERF - Mechanism for a requester NSA to query the > provider NSA for a set of notifications against a connectionId. The > returned results will be a list of notifications for the specified > connectionId. > > - 12. QueryNotificationSync - Mechanism for a requester NSA to query the > + 12. queryNERFSync - Mechanism for a requester NSA to query the > provider NSA for a set of notifications against a connectionId. The > returned results will be a list of notifications for the specified > connectionId. This is a synchronous blocking operation. > @@ -182,15 +182,15 @@ > <xsd:element name="querySummarySyncConfirmed" type="tns:QuerySummaryConfirmedType" /> > <xsd:element name="querySummarySyncFailed" type="tns:QueryFailedType" /> > > -  > - <xsd:element name="queryNotification" type="tns:QueryNotificationType" /> > - <xsd:element name="queryNotificationConfirmed" type="tns:QueryNotificationConfirmedType" /> > - <xsd:element name="queryNotificationFailed" type="tns:QueryFailedType" /> > +  > + <xsd:element name="queryNERF" type="tns:queryNERFType" /> > + <xsd:element name="queryNERFConfirmed" type="tns:queryNERFConfirmedType" /> > + <xsd:element name="queryNERFFailed" type="tns:QueryFailedType" /> > > -  > - <xsd:element name="queryNotificationSync" type="tns:QueryNotificationType" /> > - <xsd:element name="queryNotificationSyncConfirmed" type="tns:QueryNotificationConfirmedType" /> > - <xsd:element name="queryNotificationSyncFailed" type="tns:QueryFailedType" /> > +  > + <xsd:element name="queryNERFSync" type="tns:queryNERFType" /> > + <xsd:element name="queryNERFSyncConfirmed" type="tns:queryNERFConfirmedType" /> > + <xsd:element name="queryNERFSyncFailed" type="tns:QueryFailedType" /> > >  > <xsd:element name="error" type="tns:GenericErrorType" /> > @@ -398,46 +398,63 @@ > </xsd:sequence> > </xsd:complexType> > > - <xsd:complexType name="QueryNotificationType"> > + <xsd:complexType name="queryNERFType"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > - Type definition for the QueryNotification message providing a > + Type definition for the queryNERF message providing a > mechanism for a Requester NSA to query a Provider NSA for a > - set of notifications against a specific connectionId. > + set of Notifications, Errors, Responses, and Failures (NERF) > + against a specific connectionId. > > - Elements compose a filter for specifying the notifications to > + Elements compose a filter for specifying the NERF to > return in response to the query operation. The filter query > provides an inclusive range of notification identifiers based > on connectionId. > > Elements: > > - connectionId - Notifications for this connectionId. > + connectionId - Retrieve NERF for this connectionId. > > - startNotificationId - The start of the range of notificationIds > - to return. If not present then the query should start from > - oldest notificationId available. > + startId - The start of the range of NERF Ids to return. If not > + present then the query should start from oldest NERF available. > > - endNotificationId - The end of the range of notificationIds > - to return. If not present then the query should end with > - the newest notificationId available. > + endId - The end of the range of NERF Ids to return. If not > + present then the query should end with the newest NERF available. > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > <xsd:element name="connectionId" type="ftypes:ConnectionIdType" /> > - <xsd:element name="startNotificationId" type="xsd:int" minOccurs="0" /> > - <xsd:element name="endNotificationId" type="xsd:int" minOccurs="0" /> > + <xsd:element name="startNERFId" type="xsd:int" minOccurs="0" /> > + <xsd:element name="endNERFId" type="xsd:int" minOccurs="0" /> > </xsd:sequence> > </xsd:complexType> > > - <xsd:complexType name="QueryNotificationConfirmedType"> > + <xsd:complexType name="queryNERFConfirmedType"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > - A query notification confirmation containing a list of notification > - messages matching the specified query criteria. > + A queryNERF confirmation containing a list of NERF messages > + matching the specified query criteria. > > Elements: > > + reserveConfirmed - Reserve operation confirmation. > + > + reserveFailed - Reserve operation failure. > + > + reserveCommitConfirmed - Reserve commit operation confirmation. > + > + reserveCommitFailed - Reserve commit operation failure. > + > + reserveAbortConfirmed - Reserve abort operation confirmation. > + > + provisionConfirmed - Provision operation confirmation. > + > + releaseConfirmed - Release operation confirmation. > + > + terminateConfirmed - Terminate confirmation. > + > + error - Error response message. > + > errorEvent - Error event notification. > > reserveTimeout - Reserve timeout notification. > @@ -449,6 +466,7 @@ > </xsd:annotation> > <xsd:sequence> > <xsd:choice minOccurs="0" maxOccurs="unbounded"> > + <xsd:element name="response" type="tns:NERFResponseType" /> > <xsd:element ref="tns:errorEvent" /> > <xsd:element ref="tns:reserveTimeout" /> > <xsd:element ref="tns:dataPlaneStateChange" /> > @@ -457,6 +475,51 @@ > </xsd:sequence> > </xsd:complexType> > > + <xsd:complexType name="NERFResponseType"> > + <xsd:annotation> > + <xsd:documentation xml:lang="en"> > + A queryNERF element containing a list of NERF messages > + matching the specified query criteria. > + > + Elements: > + > + reserveConfirmed - Reserve operation confirmation. > + > + reserveFailed - Reserve operation failure. > + > + reserveCommitConfirmed - Reserve commit operation confirmation. > + > + reserveCommitFailed - Reserve commit operation failure. > + > + reserveAbortConfirmed - Reserve abort operation confirmation. > + > + provisionConfirmed - Provision operation confirmation. > + > + releaseConfirmed - Release operation confirmation. > + > + terminateConfirmed - Terminate confirmation. > + > + error - Error response message. > + </xsd:documentation> > + </xsd:annotation> > + <xsd:sequence> > + <xsd:element name="nerfId" type="tns:NERFIdType" /> > + <xsd:element name="correlationId" type="ftypes:UuidType" /> > + <xsd:element name="timeStamp" type="ftypes:DateTimeType" /> > + <xsd:choice> > + <xsd:element ref="tns:reserveConfirmed" /> > + <xsd:element ref="tns:reserveFailed" /> > + <xsd:element ref="tns:reserveCommitConfirmed" /> > + <xsd:element ref="tns:reserveCommitFailed" /> > + <xsd:element ref="tns:reserveAbortConfirmed" /> > + <xsd:element ref="tns:provisionConfirmed" /> > + <xsd:element ref="tns:releaseConfirmed" /> > + <xsd:element ref="tns:terminateConfirmed" /> > + <xsd:element ref="tns:error" /> > + </xsd:choice> > + </xsd:sequence> > + </xsd:complexType> > + > <xsd:complexType name="GenericRequestType"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > @@ -564,9 +627,9 @@ > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > - <xsd:element name="connectionId" type="ftypes:ConnectionIdType" /> > - <xsd:element name="notificationId" type="tns:NotificationIdType" /> > - <xsd:element name="timeStamp" type="ftypes:DateTimeType" /> > + <xsd:element name="connectionId" type="ftypes:ConnectionIdType" /> > + <xsd:element name="nerfId" type="tns:NERFIdType" /> > + <xsd:element name="timeStamp" type="ftypes:DateTimeType" /> > </xsd:sequence> > </xsd:complexType> > > @@ -892,10 +955,10 @@ > > connectionStates - The reservation's overall connection states. > > - notificationId - If present represents the notification identifier > - of the most recent error notification against this reservation. > - The notificationId can be used in the queryNotification operation > - to retrieve the associated notification. > + nerfId - If present represents the NERF identifier of the most > + recent notification, error, response, or failure message against > + this reservation. The nerfId can be used in the queryNERF > + operation to retrieve the associated messages. > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > @@ -905,7 +968,7 @@ > <xsd:element name="criteria" type="tns:QuerySummaryResultCriteriaType" minOccurs="0" maxOccurs="unbounded" /> > <xsd:element name="requesterNSA" type="ftypes:NsaIdType" /> > <xsd:element name="connectionStates" type="tns:ConnectionStatesType" /> > - <xsd:element name="notificationId" type="tns:NotificationIdType" minOccurs="0" /> > + <xsd:element name="nerfId" type="tns:NERFIdType" minOccurs="0" /> > </xsd:sequence> > </xsd:complexType> > > @@ -1073,10 +1136,10 @@ > > connectionStates - The reservation's overall connection states. > > - notificationId - If present represents the notification identifier > - of the most recent error notification against this reservation. > - The notificationId can be used in the queryNotification operation > - to retrieve the associated notification. > + nerfId - If present represents the NERF identifier of the most > + recent notification, error, response, or failure message against > + this reservation. The nerfId can be used in the queryNERF > + operation to retrieve the associated messages. > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > @@ -1086,7 +1149,7 @@ > <xsd:element name="criteria" type="tns:QueryRecursiveResultCriteriaType" minOccurs="0" maxOccurs="unbounded" /> > <xsd:element name="requesterNSA" type="ftypes:NsaIdType" /> > <xsd:element name="connectionStates" type="tns:ConnectionStatesType" /> > - <xsd:element name="notificationId" type="tns:NotificationIdType" minOccurs="0" /> > + <xsd:element name="nerfId" type="tns:NERFIdType" minOccurs="0" /> > </xsd:sequence> > </xsd:complexType> > > @@ -1303,10 +1366,10 @@ > <xsd:restriction base="xsd:anyURI" /> > </xsd:simpleType> > > - <xsd:simpleType name="NotificationIdType"> > + <xsd:simpleType name="NERFIdType"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > - A specific type for a notificationId that is unique in the context > + A specific type for a NERF identifier that is unique in the context > of a connectionId. > </xsd:documentation> > </xsd:annotation> > ======================================= > --- /trunk/ConnectionService/ogf_nsi_framework_headers_v2_0.xsd Fri Jul 26 15:21:12 2013 UTC > +++ /trunk/ConnectionService/ogf_nsi_framework_headers_v2_0.xsd Wed Dec 4 15:07:03 2013 UTC > @@ -16,11 +16,8 @@ > > Description: This is the ftypes schema for the reference web services implementation of the OGF NSI Connection Services Protocol v2.0. Comments and questions can be directed to the mailing list group mailing list (nsi-wg(a)ogf.org) > --> > -<xsd:schema targetNamespace="http://schemas.ogf.org/nsi/2013/07/framework/headers" > - xmlns:xsd="http://www.w3.org/2001/XMLSchema" > - xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > - xmlns:ftypes="http://schemas.ogf.org/nsi/2013/07/framework/types" > - xmlns:tns="http://schemas.ogf.org/nsi/2013/07/framework/headers"> > +<xsd:schema targetNamespace="http://schemas.ogf.org/nsi/2013/07/framework/headers" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > + xmlns:ftypes="http://schemas.ogf.org/nsi/2013/07/framework/types" xmlns:tns="http://schemas.ogf.org/nsi/2013/07/framework/headers"> > > <xsd:annotation> > <xsd:documentation xml:lang="en"> > @@ -30,18 +27,16 @@ > >  > - <xsd:import namespace="urn:oasis:names:tc:SAML:2.0:assertion" > - schemaLocation="saml-schema-assertion-2.0.xsd"/> > - > + <xsd:import namespace="urn:oasis:names:tc:SAML:2.0:assertion" schemaLocation="saml-schema-assertion-2.0.xsd"/> > + >  > - <xsd:import namespace="http://schemas.ogf.org/nsi/2013/07/framework/types" > - schemaLocation="ogf_nsi_framework_types_v2_0.xsd"/> > + <xsd:import namespace="http://schemas.ogf.org/nsi/2013/07/framework/types" schemaLocation="ogf_nsi_framework_types_v2_0.xsd"/> > >  > - <xsd:element name="nsiHeader" type="tns:CommonHeaderType" /> > - > + <xsd:element name="nsiHeader" type="tns:CommonHeaderType"/> > + > <xsd:complexType name="CommonHeaderType"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > @@ -112,14 +107,27 @@ > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > - <xsd:element name="protocolVersion" type="xsd:string" /> > - <xsd:element name="correlationId" type="ftypes:UuidType" /> > - <xsd:element name="requesterNSA" type="ftypes:NsaIdType" /> > - <xsd:element name="providerNSA" type="ftypes:NsaIdType" /> > - <xsd:element name="replyTo" type="xsd:anyURI" minOccurs="0" /> > - <xsd:element name="sessionSecurityAttr" type="saml:AttributeStatementType" minOccurs="0" /> > - <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> > + <xsd:element name="protocolVersion" type="xsd:string"/> > + <xsd:element name="correlationId" type="ftypes:UuidType"/> > + <xsd:element name="requesterNSA" type="ftypes:NsaIdType"/> > + <xsd:element name="providerNSA" type="ftypes:NsaIdType"/> > + <xsd:element name="replyTo" type="xsd:anyURI" minOccurs="0"/> > + <xsd:element name="sessionSecurityAttr" type="tns:SessionSecurityAttrType" minOccurs="0" maxOccurs="unbounded"/> > + <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> > </xsd:sequence> > - <xsd:anyAttribute namespace="##other" processContents="lax" /> > + <xsd:anyAttribute namespace="##other" processContents="lax"/> > + </xsd:complexType> > + > + <xsd:complexType name="SessionSecurityAttrType"> > + <xsd:annotation> > + <xsd:documentation xml:lang="en"> > + </xsd:documentation> > + </xsd:annotation> > + <xsd:complexContent> > + <xsd:extension base="saml:AttributeStatementType"> > + <xsd:attribute name="type" type="xsd:string" use="optional"/> > + <xsd:attribute name="name" type="xsd:string" use="optional"/> > + </xsd:extension> > + </xsd:complexContent> > </xsd:complexType> > </xsd:schema> > ======================================= > --- /trunk/ConnectionService/ogf_nsi_services_definition_v2_0.xsd Tue Sep 17 07:59:19 2013 UTC > +++ /trunk/ConnectionService/ogf_nsi_services_definition_v2_0.xsd Wed Dec 4 15:07:03 2013 UTC > @@ -76,7 +76,6 @@ > <xsd:element name="comment" type="xsd:string" minOccurs="0" /> > <xsd:element name="serviceType" type="xsd:string" /> > <xsd:element name="schema" type="tns:SchemaType" minOccurs="1" maxOccurs="unbounded" /> > - <xsd:element name="parameter" type="tns:ParameterType" minOccurs="0" maxOccurs="unbounded" /> > <xsd:element name="attribute" type="tns:AttributeType" minOccurs="0" maxOccurs="unbounded" /> > <xsd:element name="error" type="tns:ErrorType" minOccurs="0" maxOccurs="unbounded" /> > <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> > @@ -111,7 +110,8 @@ > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > - <xsd:element name="comment" type="xsd:string" minOccurs="0" /> > + <xsd:element name="comment" type="xsd:string" minOccurs="0" /> > + <xsd:element name="parameter" type="tns:ParameterType" minOccurs="0" maxOccurs="unbounded" /> > <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> > </xsd:sequence> > <xsd:attribute name="name" type="xsd:string" use="required" /> > ======================================= > --- /trunk/ConnectionService/ogf_nsi_services_p2p_v2_0.xsd Fri Sep 13 14:34:02 2013 UTC > +++ /trunk/ConnectionService/ogf_nsi_services_p2p_v2_0.xsd Wed Dec 4 15:07:03 2013 UTC > @@ -40,28 +40,27 @@ > </xsd:annotation> > </xsd:element> > > - <xsd:element name="ets" type="tns:EthernetBaseType"> > +  > + <xsd:element name="capacity" type="xsd:long"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > - This Ethernet Transport Service element is used to specify a > - point-to-point Ethernet service request in the NSI CS protocol. > + This element is defined for a modification of the capacity of > + the service. The unit of capacity is specified in the Service > + Definition associated with the requested service. > </xsd:documentation> > - </xsd:annotation> > + </xsd:annotation> > </xsd:element> > - > - <xsd:element name="evts" type="tns:EthernetVlanType"> > + > + <xsd:element name="parameter" type="types:TypeValueType"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > - This Ethernet VLAN Transport Service element is used to specify > - a point-to-point Ethernet VLAN service request in the NSI CS > - protocol. > + This element is defined for specifying modification to > + non-specific parameters defined in the Service Definition but > + not in the service specific schema. > </xsd:documentation> > </xsd:annotation> > </xsd:element> > > -  > - <xsd:element name="capacity" type="xsd:long" /> > - >  > <xsd:complexType name="P2PServiceBaseType"> > <xsd:annotation> > @@ -72,7 +71,7 @@ > > Elements: > > - capacity - Capacity of the service in Mb/s. > + capacity - Capacity of the service. > > directionality - The (uni or bi) directionality of the service. > > @@ -88,6 +87,11 @@ > ero - A hop-by-hop ordered list of STP from sourceSTP to > destSTP representing a path that the connection must follow. > This list does not include sourceSTP or destSTP. > + > + parameter - A flexible non-specific parameters definition > + allowing for specification of parameters in the Service > + Definition that are not defined directly in the service > + specific schema. > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > @@ -97,107 +101,8 @@ > <xsd:element name="sourceSTP" type="types:StpType" /> > <xsd:element name="destSTP" type="types:StpType" /> > <xsd:element name="ero" type="types:StpListType" minOccurs="0" /> > + <xsd:element name="parameter" type="types:TypeValueType" minOccurs="0" maxOccurs="unbounded" /> > + <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> > </xsd:sequence> > </xsd:complexType> > - > - <xsd:complexType name="EthernetBaseType"> > - <xsd:annotation> > - <xsd:documentation xml:lang="en"> > - Point-to-Point Ethernet service definition. > - > - Elements: > - > - capacity - Capacity of the service in Mb/s including ethernet > - framing headers. > - > - directionality - The (uni or bi) directionality of the service. > - > - symmetricPath - An indication that both directions of a bidirectional > - circuit must fallow the same path. Only applicable when > - directionality is "Bidirectional". If not specified then value > - is assumed to be false. > - > - sourceSTP - Source STP of the service. > - > - destSTP - Destination STP of the service. > - > - ero - Hop-by-hop ordered list of STP from sourceSTP to > - destSTP. List does not include sourceSTP and destSTP. > - > - mtu - Specifies the maximum transmission unit size in bits. > - > - burstsize - Specifies the maximum number of bits that can be > - send to the interface before the sender must wait before > - sending again. > - </xsd:documentation> > - </xsd:annotation> > - <xsd:complexContent> > - <xsd:extension base="tns:P2PServiceBaseType"> > - <xsd:sequence> > - <xsd:element name="mtu" type="xsd:int" minOccurs="0" /> > - <xsd:element name="burstsize" type="xsd:long" minOccurs="0" /> > - </xsd:sequence> > - </xsd:extension> > - </xsd:complexContent> > - </xsd:complexType> > - > - <xsd:complexType name="EthernetVlanType"> > - <xsd:annotation> > - <xsd:documentation xml:lang="en"> > - Point-to-Point Ethernet VLAN service definition. > - > - Elements: > - > - capacity - Capacity of the service in Mb/s including ethernet > - framing headers. > - > - directionality - The (uni or bi) directionality of the service. > - > - symmetricPath - An indication that both directions of a bidirectional > - circuit must fallow the same path. Only applicable when > - directionality is "Bidirectional". If not specified then value > - is assumed to be false. > - > - sourceSTP - Source STP of the service. > - > - destSTP - Destination STP of the service. > - > - ero - Hop-by-hop ordered list of STP from sourceSTP to > - destSTP. List does not include sourceSTP and destSTP. > - > - mtu - Specifies the maximum transmission unit size in bits. > - > - burstsize - Specifies the maximum number of bits that can be > - send to the interface before the sender must wait before > - sending again. > - > - sourceVLAN - Specifies the VLAN identifier for the source port > - (1 - 4095). > - > - destVLAN - Specifies the VLAN identifier for the destination port > - (1 - 4095). > - </xsd:documentation> > - </xsd:annotation> > - <xsd:complexContent> > - <xsd:extension base="tns:EthernetBaseType"> > - <xsd:sequence> > - <xsd:element name="sourceVLAN" type="tns:vlanIdType" /> > - <xsd:element name="destVLAN" type="tns:vlanIdType" /> > - </xsd:sequence> > - </xsd:extension> > - </xsd:complexContent> > - </xsd:complexType> > - > - <xsd:simpleType name="vlanIdType"> > - <xsd:annotation> > - <xsd:documentation xml:lang="en"> > - A simple type modelling a VLAN identifier and restricting range > - to between 1 - 4095. > - </xsd:documentation> > - </xsd:annotation> > - <xsd:restriction base="xsd:int"> > - <xsd:minInclusive value="1"/> > - <xsd:maxInclusive value="4095"/> > - </xsd:restriction> > - </xsd:simpleType> > </xsd:schema> > ======================================= > --- /trunk/ConnectionService/ogf_nsi_services_types_v2_0.xsd Mon Sep 9 18:21:29 2013 UTC > +++ /trunk/ConnectionService/ogf_nsi_services_types_v2_0.xsd Wed Dec 4 15:07:03 2013 UTC > @@ -61,14 +61,21 @@ > localId - A locally unique identifier for the STP within the > associated network. > > - labels - Technology specific attributes associated with > - the Service Termination Point. > + labels - Technology specific attribute associated with the > + Service Termination Point. > + > + labelGroup - Technology specific attributes associated with > + the Service Termination Point. Used to specify a range of > + values instead of the label that provides a specific value. > </xsd:documentation> > </xsd:annotation> > <xsd:sequence> > - <xsd:element name="networkId" type="xsd:string" /> > - <xsd:element name="localId" type="xsd:string" /> > - <xsd:element name="label" type="tns:LabelType" minOccurs="0" maxOccurs="unbounded" /> > + <xsd:element name="networkId" type="xsd:string" /> > + <xsd:element name="localId" type="xsd:string" /> > + <xsd:choice minOccurs="0"> > + <xsd:element name="label" type="tns:TypeValueType" /> > + <xsd:element name="labelGroup" type="tns:TypeValueType" maxOccurs="unbounded" /> > + </xsd:choice> > </xsd:sequence> > </xsd:complexType> > > @@ -111,44 +118,20 @@ > <xsd:attribute name="order" type="xsd:int" use="required" /> > </xsd:complexType> > > - <xsd:complexType name="LabelType"> > + <xsd:complexType name="TypeValueType"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > - Definition for a simple type and multi-value tuple. Includes > - simple string type and value, as well as more advanced > - extensions if needed. A namespace attribute is included to > - provide context where needed. > - > - Elements: > - value - A string value corresponding to type. > - > - any - Provides a flexible mechanism allowing additional elements > - to be provided as an alternative, or in combination with value. > - Use of this element field is beyond the current scope of this > - NSI specification, but may be used in the future to extend the > - existing protocol without requiring a schema change. > + Definition for a simple type and value tuple. > > Attributes: > - type - A string representing the name of the type. > - > - namespace - An optional URL to qualify the name space of the > - capability. > - > - anyAttribute - Provides a flexible mechanism allowing additional > - attributes non-specified to be provided as needed for peer-to-peer > - NSA communications. Use of this attribute field is beyond the > - current scope of this NSI specification, but may be used in the > - future to extend the existing protocol without requiring a schema > - change. > + type - A string representing the name of the type. > </xsd:documentation> > </xsd:annotation> > - <xsd:sequence> > - <xsd:element name="value" type="xsd:string" nillable="true" minOccurs="0" maxOccurs="unbounded" /> > - <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> > - </xsd:sequence> > - <xsd:attribute name="type" type="xsd:string" use="optional" /> > - <xsd:attribute name="namespace" type="xsd:anyURI" use="optional" /> > - <xsd:anyAttribute namespace="##other" processContents="lax" /> > + <xsd:simpleContent> > + <xsd:extension base="xsd:string"> > + <xsd:attribute name="type" type="xsd:string" use="required"/> > + </xsd:extension> > + </xsd:simpleContent> > </xsd:complexType> > > <xsd:simpleType name="DirectionalityType">

2 1

minutes from today's NSI conf call...
by Guy Roberts 04 Dec '13

04 Dec '13

.... are available here: https://redmine.ogf.org/dmsf_files/13169 _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

1 0