- Nsi-wg - lists.ogf.org

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

Re: [Nsi-wg] [Nml-wg] NSI Topology
by John MacAuley 04 Dec '13

04 Dec '13

Last night after working on this for a week I realized the labelType is really not required because of the restriction that a Port can only have a single Label, and therefore, only a single labelType. However, it still would not hurt to have it, although, it can be derived from the Port/PortGroups present. It has been over a month since I first did the edits, but if I remember correctly, I followed the existing pattern in the NML that had an ANY in the element definitions themselves. When I attempted to add the ANY to the NetworkObject I invalidated the existing elements that had an ANY member already (Universe destroying paradox where members could no longer be resolved). I agree though, refactoring all ANYs out of the specific element definitions and placing in the NetworkObject would be a clean solution. John On 2013-12-04, at 5:39 AM, Roman Łapacz <romradz(a)man.poznan.pl> wrote: > Hi John, > > regarding the changes in the base nml xsd schema I see main two changes: > 1) presence of xs:any element in each type definition > 2) labelType in Switching Service > > Did I miss something? > > I think that in case of 1) xs:any element can be added only to NetworkObject. This way you don't have to place it in each type definition (NetworkObject is already there). > > Best regards, > Roman > > > W dniu 2013-12-04 06:06, John MacAuley pisze: >> 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 >> >> >> >> >> >> >> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg(a)ogf.org >> https://www.ogf.org/mailman/listinfo/nsi-wg > > _______________________________________________ > nml-wg mailing list > nml-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/nml-wg

1 0

NSI topology representation using NML
by John MacAuley 04 Dec '13

04 Dec '13

Peoples, I have taken another look over Jeroen's document "Network Service Interface Topology Representation" given the discussion we had today on the call. I must say that we are totally out of synch with the definition of an STP Identifier in Jeroen's document and what we have in the NSI CS (no specific fault on Jeroen). Specifically, if we look at section 2.2 and 2.3 the STP identifier is defined as follows: STP ID = urn:ogf:network:example.net:2013:A2?vlan=1781 urn:ogf:network: - describes that it is a network identifier. example.net:2013 - DNS name and a (at least) year to make a globally unique prefix creating the network identifier. A2?vlan=1781 - The local component identifying the STP in the context of the network identifier. The root STP ID "urn:ogf:network:example.net:2013:A2" would be an under specified STP referring to the bundle of STP enumerated by vlan. I believe, although not specifically stated, that "urn:ogf:network:example.net:2013:A2?vlan=1780-1790" would also allow me to under specify a range of vlan. This definition for an STP Identifier is in line with the Baton Rouge discussions. This is also how I build an internal STP identifier within my path finder implementation so I can refer to an STP using a single string. So there is a gap in definition between what we have defined as an STP identifier, and what is defined in the nsi-ext specification. We have taken multiple fields from NML objects and composed a complex STP Identifier: NSI CS STP Identifier = { networkId = NML Topology Identifier; localId = NML BidirectionalPort Identifier choice { label = NML Unidirectional Port Label; labelGroup = NML Unidirectional PortGroup LabelGroup; } } To compare the content of the two, here is an example of an STP from the Netherlight topology: <sourceStp> <networkId>urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed</networkId> <localId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1</localId> <label type="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1781</label> </sourceStp> versus something like this: urn:ogf:network:netherlight.net:2013:a-gole:testbed:port:uva:1?vlan=1781 where "urn:ogf:network:netherlight.net:2013:a-gole:testbed:" is the network portion, and "port:uva:1?vlan=1781" is the local portion. I must admit I am questioning the value of our complex STP definition. I understand the value of the being able to route on networkId, and the issue with URN opaqueness, but if we are constructing the URN following a specific set of rules, could we also not parse it similarly? John

4 7

reworked NSI framework document
by Guy Roberts 04 Dec '13

04 Dec '13

Hi all, I have reworked the NSI Framework as the current version is out of date and will not match the content of the Connection Service v2.0 protocol. Please find draft NSF v2.0 here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6526 Guy _____________________________________________________________________ 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

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

04 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: - NSI v2.0 topology and mapping to NML (John) - Returning under-specified STPs in response to a reserveRequest - OGF 40 dinner at Lincoln college Oxford _____________________________________________________________________ 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