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

ServiceType and Service Descriptions
by John MacAuley 17 Jul '13

17 Jul '13

All, I need to capture my closing thought on ServiceType before I forget. I didn't want to extend the meeting with this, but I think it is an important point on which we need resolution. From the discussion today I think Jerry views the service description as a template for ranges and population of parameters. I have extended this to also include other aspects such as service level agreement, things not quantifiable in request parameters. I also see it as a great tool for creating customer specific or group specific services. Services that may have specific needs above those of the masses, and specific resources allocated to them. Let me use the example of an ETS.1G service, an ETS.10G service, and an ETS.100G service. All of these are point-to-point Ethernet, use the same <ets> service schema, and the only difference is the maximum capacity specified in the service description template, however, they are semantically different due to their target user base. I should be able to get my point across with the following use cases... Now let us say we have five networks (A through E) participating in the NSI protocol. They all agree to the ETS.1G service, define the service description template, and support the full specification of the agreement. This ETS.1G service description template is communicated to all their users and is a global service offering to the masses. We can also associate service level agreements such as a repair time on failed services of 48 hours. Networks A, B, and C need to offer an low latency ETS.10G service for specific user cases proposed by their user base. Networks A, B, and C all agree to the ETS.10G service, define the service description template, and support the full specification of the agreement. This ETS.10G service description template is communicated to the end users and they restrictions relating to the service offering (i.e. only networks A, B, and C). This specific service has a guarantee of 2 hours to restore services. Finally, Network E has just installed equipment making them 100G capable and want to offer this service to a special group of users within their network. They define an ETS.100G service, define the service description template, and provide to all their users as a local service offering. This is an experimental service and has a best effort service level agreement. Remember that Network E does not offer an ETS.10G service. Use case #1: User Bob in network A wants to connect port A1 to port E1 with a bandwidth of 500 Mb/s. Bob has been given the two service description templates (or equivalent) that his network supports (ETS.1G and ETS.10G). How this is done is beyond the scope of this discussion. Bob sees that both ETS.1G and ETS.10G will meet his bandwidth requirements, however, network E does not support ETS.10G so he must chose the ETS.1G serviceType for his request. Bob issues his request to local NSA A that validates it using ETS.1G, populates any additional parameters required, and then performs path computation. NSA A must exclude any networks not specifically supporting ETS.1G since those NSA will not understand the ETS.1G serviceType, however, in this specific case all do support the serviceType. Discussion: Although the ETS.100G service offered in Network E could theoretically meet the requirement of the ETS.10G service template, they are in fact two different services offerings and must be treated that way. If Network E is capable of providing the ETS.10G service then they should support the common template. Not advertising the template is an indication that they are not willing to meet the specifics of that service, even if the service criteria is covered by another template. For example, they might not be willing to meet the 2 hours guarantee on service restoration. I think that if we consider how these services will be offered by the service providers, the end users will be given a limited set of supported services based on their requirements, where they are interconnecting from, and who they are interconnecting to. They will not need to make these types of complicated decisions. Use case #2: User Fred in network C wants to connect port A2 to port C2 with a bandwidth of 2 Gb/s. Fred has no other option in this case and must use the ETS.10G service offering. The procedure proceeds as it did in user case #1 using NSA C, except the NSA C will need to exclude networks D and E from path computation since they do not offer the ETS.10G service. As mentioned previously, network E does provide an ETS.100G service, but this network must still be excluded because it does not support the ETS.10G service offering. Use case #3: User George in network E wants to connect port E3 to port A3 with a bandwidth of 2 Gb/s. George is out of luck. His local network offers him the ETS.1G and the ETS.100G service (if he has 100GE ports installed locally). No other networks support the ETS.100G service, so when he specifies the request, his local NSA E will determine that there is no valid path between E3 and A3 (in fact, A3 doesn't support ETS.100G so it is an easy decision). Conclusions I think the service description concept is a good one, but I believe it is more than a simple template for parameters and values. I believe it wraps all aspects of a service up into one neat package, and offers a needed layer of abstraction we do not currently have. Networks are excluded from path computation when they do not support the serviceType, and I would go so far as to say we probably need to tag serviceTypes against ports in topology so we can quickly exclude those that are not capable of "possibly" meeting the criteria. John

1 0

minutes from today's NSI call....
by Guy Roberts 17 Jul '13

17 Jul '13

.... are available here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6529 _____________________________________________________________________ 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 16 Jul '13

16 Jul '13

Hi all, The following is dial-in information for Wednesday's NSI call: Time: 7:00 PDT 10:00 EDT, 15:00 BST, 16:00 CEST, 23: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: - Service decoupling proposal - CS editing _____________________________________________________________________ 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

Service definitions (draft) for Point-to-Point Ethernet
by Henrik Thostrup Jensen 11 Jul '13

11 Jul '13

Hi everyone Here are high-level descriptions of suggested ethernet service definitions. These are the result of a conversation that Jerry and I had some weeks ago, along with the latest discussions on the calls. The definitions are fairly close to what we already had, but are more precise and involve some more ethernet specific attributes. There are two suggestions here. One for plain ethernet, and one for vlan over ethernet. Organizing the the request types / service definitions like this makes it very clear what is going, but is also slightly less flexible than what we previously had, e.g., there is no clear way for how to provide a connection where one end is plain ethernet and the other is on a VLAN. However, as the point here is interdomain, I think simplicity is a virtue, and I don't see it as a major loss. The order of in which the attributes are listed is largely random. Point-to-Point Ethernet (suggested short name ets_v1) * Directionality := choice(Bidirectional, Unidirectional). Optional, default: Bidirecitonal Specifies if the circuit should only carry data in one direction or in both direction. If Unidirectional, data can only be carried from source to destination. * Symmetric := Boolean. Optional. Default: False Can only be specified for bidirectional circuits. If true, the circuit creates must follow the same path in both directions. * Source STP : PortType (network + port). Mandatory. Specifies the source of the data flow. Network+Port values are similar to current STP constructio. * Destination STP : PortType (network + port). Mandatory. Specifies the destination of the data flow. Network+Port values are similar to current STP constructio. * Capacity : Integer. Mandatory. Specifies the required capacity of the circuit. In Mbps. The capacity includes ethernet framing headers (because thats what Ethernet does) * MTU : Integer. Optional. Specifies the maximum transmission unit size. In bits. * Burstsize : Integer. Optional. Specifies the maximum number of bits that can be send to the interface before the sender must wait before sending again. Point-to-Point Ethernet VLAN (suggested short name evts_v1) # Includes the same attributes as the Ethernet service. * Source VLAN : Integer (1-4095). Mandatory. Specifies the VLAN for the source port. * Destination VLAN : Integer (1-4095). Mandatory. Specified the VLAN for destination port. I suggest not having any ANY elements or similar in these, as they are strict thingies. * Service types and Topology Where this gets interesting, is how the service definitions mix up with the topology. At the very least we need a way to announce which service types a NSA or Network (Topology in NML lingo). I'm a bit unsure how to structure this. Just because an NSA supports a request type, doesn't mean that the network can provide it and vice versa. However IMHO it only makes sense to announce service types, which the NSA AND Network can provide. However an NSA may adminstrate multiple networks, which shakes things up a bit. I am unsure if it should be attached to the network, but leaning toward the network. Another thing to consider is if how match the service types and ports in the topology. One option is to have a mapping between labels and service types, or simply just list the service types on the ports. This would make it clear which ports could support features like jumbo frames (by having a large mtu capability). This could even be necessary for path finding. The idea of listing capabilities in the topology like this is somewhat different than the core principles in NML, which is more geared towards describing network a link and labels (plumming so to say), where using service definitions it becomes more oriented towards capability. The capability oriented approach could have some advantages in topology aggregation / scaling, where a network could announce reachability to other networks in terms of capability, i.e., nordunet can provide transit to surfnet on ethernet with the following parameters, etc. This is a lot more useful than just reachability, and compresses quite well. Thoughts? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

3 9

Minutes of today's meeting
by Guy Roberts 10 Jul '13

10 Jul '13

Hello All, Please find minutes of today's NSI conf call here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6529 Regards, 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

NSI Service Decoupling v2
by John MacAuley 10 Jul '13

10 Jul '13

People, As agreed I have added the serviceType string to identify the corresponding Service Description that will identify the elements carried in the serviceAttributes. The updated document is attached. I will open issues to track the updates and submit the changes to the code.google repository. John

2 3

Wednesday's NSI conf call
by Guy Roberts 09 Jul '13

09 Jul '13

Hi all, The following is dial-in information for Wednesday's NSI call: Time: 7:00 PDT 10:00 EDT, 15:00 BST, 16:00 CEST, 23: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: - Feedback on NSI CS v2.0 from OGF editors - John M. Service decoupling proposal - other issues. _____________________________________________________________________ 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

Issue 97 in ogf-nsi-project: Add ServiceType element to reservation criteria.
by ogf-nsi-project＠googlecode.com 06 Jul '13

06 Jul '13

Status: Accepted Owner: jmacauley Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 97 by jmacauley: Add ServiceType element to reservation criteria. http://code.google.com/p/ogf-nsi-project/issues/detail?id=97 As part of service definition decoupling from the NSI CS core protocol we need to add a ServiceType string value to reservation criteria to indicate the type of service being requested. This string value will correspond to the service definition template for the service being offered. Based on this ServiceType string value, and NSA will be able to determine the serviceAttributes required to meet the service request, and look up the service definition template. The current ReservationRequestCriteriaType definition is: <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="bandwidth" type="xsd:int" minOccurs="0" /> <xsd:element name="serviceAttributes" type="ftypes:TypeValuePairListType" minOccurs="0" /> <xsd:element name="path" type="tns:PathType" minOccurs="0" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> </xsd:complexType> This will be modified to: <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="serviceType" type="xsd:string" /> <xsd:element name="bandwidth" type="xsd:int" minOccurs="0" /> <xsd:element name="serviceAttributes" type="ftypes:TypeValuePairListType" minOccurs="0" /> <xsd:element name="path" type="tns:PathType" minOccurs="0" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> </xsd:complexType> All other types containing criteria will also be modified to contain the serviceType element. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 4

Is ServiceType optional?
by John MacAuley 05 Jul '13

05 Jul '13

Is the serviceType string optional? If it is what will be the behaviour?

2 1

Issue 95 in ogf-nsi-project: Type attribute in TypeValuePairType should be optional.
by ogf-nsi-project＠googlecode.com 05 Jul '13

05 Jul '13

Status: Accepted Owner: jmacauley Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 95 by jmacauley: Type attribute in TypeValuePairType should be optional. http://code.google.com/p/ogf-nsi-project/issues/detail?id=95 The "type" attribute in TypeValuePairType should be optional for when elements from external namespaces are included. The TypeValuePairType appears currently as: <xsd:complexType name="TypeValuePairType"> <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="required" /> <xsd:attribute name="targetNamespace" type="xsd:anyURI" use="optional" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> It will be changed to: <xsd:complexType name="TypeValuePairType"> <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="targetNamespace" type="xsd:anyURI" use="optional" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2