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

NSI CS XSD comments
by John MacAuley 14 Apr '11

14 Apr '11

Peoples, I think there is one major area we need to close on before I feel comfortable starting to write the associated document. It is specifically around the service parameters and how they are specified:  <xsd:complexType name="ServiceParametersType"> <xsd:sequence>  <xsd:element name="schedule" type="tns:ScheduleType"/> <xsd:element name="bandwidth" type="tns:BandwidthType"/> <xsd:element name="directionality" type="tns:DirectionalityType"/> <xsd:element name="pathObject" type="tns:PathObjectType"/> <xsd:element name="guaranteed" type="tns:AttributeSequenceType" minOccurs="0"/> <xsd:element name="preferred" type="tns:AttributeSequenceType" minOccurs="0"/> </xsd:sequence> </xsd:complexType> The main question I have is do we change this structure to be completely generic and list all service parameters through type/value pairs, or do we break out hose key ones as I have here and put the remaining in the type/value pairs? Also, for bandwidth do we document the values as Mb/s or do I add an element to explicitly identify the unit as suggested in one provided comment. Thank you, John.

6 8

usage of STPs
by Guy Roberts 14 Apr '11

14 Apr '11

Hi Jerry, Based on our discussion yesterday I will try and summarize the current thinking on STPs: STP is a tuple which is formed as: Network_Id:Local_id where: Network_id is an string (unformatted - no syntax specified) which identifies a group of resources available to a single service. Each Network has an associated NSA, i.e. there is a 1:1 relationship between and NSA instance and a Network. A single stage lookup is required to find the address of the NSA from the Network_id. Local_id is a string (unformatted - no syntax specified) which identifies a local resource (or endpoint). A federating NSA has the option (not compulsory) of swapping the Network and Local parts of the STP. Both parts must be swapped (not just the network part) this removes the need for Local_id to be globally unique. (this is like MLPS label swapping) Does this align with your view? Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

4 5

NSI conf call minutes from today's call
by Guy Roberts 13 Apr '11

13 Apr '11

Minutes are available here: http://forge.gridforum.org/sf/go/doc16253?nav=1 _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

tomorrow's NSI conf call
by Guy Roberts 12 Apr '11

12 Apr '11

Hi all, The following is dial-in information for tomorrow's NSI call: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 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 "#" Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

NSI-CS initial SD for Ethernet transport
by Jerry Sobieski 12 Apr '11

12 Apr '11

Hi Guy- I have given up for now trying to generalize a Service Definition schema. XSDs just don't provide the indirection we need for this...so I am punting on the generic SD schema for now. Instead, I have opted for an example Service Definition for an Ethernet Transport Service. The workings are the same - its just that now whoever defines the service deployment will also need to know how to edit this XSD. So be it...(for now). We may not need even the XSD if we can effectively document what an XML service definition should look like. Oh well...This will work for v1.0 Attached is the latest version of the Ethernet Transport Service service definition. Also attached is a autogenerated PDF of the same SD. The generic SD has two basic parts: the Name, and the Attirbute List. If all would look this through... The important issues that need inspecting are: --- Are the Service Attributes sufficient (what attributes are missing?) --- Are the Service Attributes defined correctly? (should the ranges be different? should defaults be differnet?... Please let me know. Jerry

2 4

Fwd: Re: comments to WSDL files
by Jerry Sobieski 07 Apr '11

07 Apr '11

I should have replied-all... J -------- Original Message -------- Subject: Re: [Nsi-wg] comments to WSDL files Date: Wed, 06 Apr 2011 13:28:04 -0400 From: Jerry Sobieski <jerry(a)nordu.net> Organization: NORDUnet To: John MacAuley <john.macauley(a)surfnet.nl> NSI is not VLAN sensitive...this is soo hard for people to grip. In NSI, we specify "connections" across "network", between two "endpoints". Period. Its *that* simple. If that requires that we have 4000 entries in our topology DB representing VLAN endpoints across the ENNI, so be it...its a topology problem -not an NSI CS problem. Its a pathfinder problem, not a ReserveRequest problem. An NSA for network "netA" gets a request netA:F>netQ:M, the NSA looks at the orig netA:F and knows its in his own network. NSA looks at dest netQ:M and realizes its in a remote network. NSA calls the pathfinder to select an exit point from netA:F towards netQ:M. Pathfinder says go to netB:io1 next via netA:x10. NSA creates a segment netA:F>netA:X10, it looks up netA:F in local topoDB and build a hdw request from "sw=F10-e300 port=3/2 vlan=27" he found from the topoDB, he looks up netA:X10 in topodb and come up with hdw info"sw=dell3236 port=1/1 vlan=2998" he puts both hardware endpoints in the NRM reserve request and and passes the nrm request to local NRM. Local segment done. NSA then goes to pathfinder again to ask: next hop for netB:io1> netQ:M (this is tree) Pathfinder says netC:i1 next via netB:io9. NSA build SR for netB:io1>netB:io9 and sends to netB NSA. NSA then goes to PF from netC:i1>netQ:M. PF return NetD:in via netC:o9... This continues until a segment is built for the last network. In this process, each NSA gets a request with only local endpoint STPs, the NSA will see both are local, and will build a local nrm request with hardware specs just as the first hop NSA did. Alternately, after the first hop NSA does his local ReservationRequest, it can build a SR for netB:io1>netQ:M and submit it to netB NSA. If a confirm comes back, we have a circuit. (this is chain) does this help? j On 4/6/11 9:35 AM, John MacAuley wrote: > Taking time off from the NSI the last couple weeks has muddled my head. > > Taking the current Automated GOLE demo service as an example, we specify a VLAN to provision across the network and the E-NNI Ethernet edge ports along the path. Are you saying that we no longer do this and that an STP would reference pre-defined VLANs? I am having problems visualizing. > > Thanks, > John. > > On 2011-04-06, at 12:27 AM, Jerry Sobieski wrote: > >> Not quite, John. The STP (<net>:<ep> tuple) should be considered to be a link into the local topology db. The physical specifics of the termination point are found there- not in the service request. >> >> When processing the SR, the NSA will look up the network in the topodb and find a path to that network. At some point, a segment will be generated from the far network edge to the end point and set to the NSA. That NSA will realize the endpoints are local, and will know then to convert the NSI tuples to NRM nomenclature and any other munging about of the SR. The NSAs will need a local internal mechanism to map NSI names to local physical specifications for the NRM. That might be a look up name table, or it may be a name list in the topology DB that has the NSI name associated with a topology object. In any case, the topology object should have information relating to the termination point details - vlan tag, port, switch, availbale cap, etc. >> >> The VLAN tag is NRM specific information and is not recognized by NSI. Unless we elect to define VLANs in the Service Definition, they won't either show up in the ReserveRequest. All the specific hardware information is found in the topology DB. The local NRM topology DB will say if the termination point is a tag on a port on a switch... or is just a port on a switch (or tag0 on a port on a switch). >> >> The user doesn't know and should have to know the technical specs associated with an far STP in some remote land. The request simply specifies an STP - the networkname:endpointname tuple. The request will specify the bandwdith, orig and dest STP, and other parameters defined in the Service definition. The primitive does not have guaranteed attributes...(I saw these in the xsd... What are those?) >> >> j >> >> On 4/5/11 10:45 PM, John MacAuley wrote: >>> So based on the discussion here, have we answered Radek's original request with respect to VLAN against the ServiceTerminationPointType? >>> >>> In my mind the answer is that the ServiceTerminationPointType identifies the abstract interconnects, while specifics of the service are held in the ServiceParametersType. The tagged/untagged and specific VLAN id would be populated in the "guaranteed" attribute sequence as per the service definitions. >>> >>> John. >>> >>> On 2011-03-29, at 3:13 PM, Jerry Sobieski wrote: >>> >>>> Oops - one thing I should make clear below... >>>> >>>> O >>>>>> - In ServiceTerminationPointType, it would be useful to have information whether port is tagged or not (VLANs information is not stored also). I know that we would like to keep the messages as technology agnostic as possible, but we need to have a balance between functionality and simplicity/universality here. In case of AutoBAHN we can probably do some workarounds to evade the issue, however this is not plug-and-play ;) >>>>> Hej Radak- >>>>> >>>>> The STP is just an NSI name.<network>:<localname> NSI does not >>>>> encode any physical topology information into the name. It is just a >>>>> name. I expect the NSA would use the name to index into a table of >>>>> local names to link to the local topologyDB. (Alternatively, the NSA may >>>>> simply search the local TopoDB for a topology object with this NSI name. >>>>> ...but this is all an implementaion detail) The topoDB would indicate >>>>> whether that STP maps to a port or VLAN or something else. Since NSI >>>>> does not define any technology specific topology information, things >>>>> like VLANs and ports etc are only of significance to the local NRM >>>>> (AutoBahn in this case). And it becomes the responsibility of the NRM >>>>> (AutoBahn in this case) to provide a translation from the NSI local >>>>> endpoint name to any NRM specific denotion. (Also, since each NRM is >>>>> different, it would be impractical for the NSA to know each dialect of >>>>> every NRM it might encounter...) >>>> The *service* specifics - things like bandwidth or MTU or other service >>>> related specifics of a particular connection service are defined in the >>>> Service Definition. The ReservationRequest contains such service >>>> attributes, and they are qualified against the Service Definitions of >>>> the transit networks, but they are not specifically part of the NSI-CS >>>> protocol. >>>> >>>> We have tried to separate the service specifics from the protocol(s) >>>> that communicate them. The NSI-CS protocol recognizes an abstract >>>> model of a "connection", but hardware specifics of a particular >>>> connection service offering or a particular service instance are not >>>> hard wired into the NSI-CS protocol. This will allow a great deal of >>>> flexibility to map multi-layer and heterogenous connection services and >>>> their dialects to the same generic and global protocol framework. >>>> >>>> Hope this helps a bit more.. >>>> J >>>> >>>> >>>> >>>> _______________________________________________ >>>> nsi-wg mailing list >>>> nsi-wg(a)ogf.org >>>> http://www.ogf.org/mailman/listinfo/nsi-wg

4 3

Conf call minutes
by Guy Roberts 06 Apr '11

06 Apr '11

.... Are available here: http://forge.gridforum.org/sf/go/doc16250?nav=1 _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

Reservation request message
by John MacAuley 06 Apr '11

06 Apr '11

Peoples, I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message. John.

4 11

my slide
by Tomohiro Kudoh 06 Apr '11

06 Apr '11

Please take a look at slide 14 of: http://forge.gridforum.org/sf/go/doc16046?nav=1

1 0

comments to WSDL files
by Radek Krzywania 06 Apr '11

06 Apr '11

Hi, Michal has get through the WSDL file, the comments are below: - WSDL seems to be fine, and not very difficult to adopt in various software (i.e. AutoBAHN) - In ServiceTerminationPointType, it would be useful to have information whether port is tagged or not (VLANs information is not stored also). I know that we would like to keep the messages as technology agnostic as possible, but we need to have a balance between functionality and simplicity/universality here. In case of AutoBAHN we can probably do some workarounds to evade the issue, however this is not plug-and-play ;) Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

5 8