Comments inline... On 3/29/11 6:18 AM, Guy Roberts wrote:
My understanding is that you are currently planning to implement AutoBAHN internally in GÉANT and an NSI interface facing other dynamic services. In this case, GÉANT will be treated by an NSI request as a leaf network, for this reason any connection request will be a single-Network request (i.e not a multi-domain request). This means that the Origin and Destination STPs will also be the service end-points. This is correct.
So in this case you are able to look at the Access Framing type to find out if the STP reflects a tagged or untagged Ethernet port. The STP *represents* a topological location where the service does or could terminate. i.e. It *links* to the TopoDB. It is *not* the topoDB. So using the STP name, the NSA indexes into the topologyDB to find the corresponding topological object (a port, or VLAN, or...) Specifics about the termination point is then found in the topology DB - not in the STP name itself. Access Framing types (and VLANs?) are described in the service definition associated with the connection request:
OrigSTP := NSISTP(OrigSTP)==True; /* STP */ DestSTP := NSISTP(DestSTP)==True; /* STP */ Bandwidth := 1..1000 Mbps, default=10 Mbps; AccessFraming:= 802.1, /* payloads in untagged frames */ 802.1q, /* payloads in tagged frames */ 802.1ah,/* tagged frames are the payload */ default=802.1q; /* only tagged payloads */
Note that this would change if you were to implement NSI between AutoBAHN IDMs. Since the access framing only refers to the service access points, intermediate 'stitching points' between networks are represented by STPs which are technology agnostic labels only, so to find the technology detail it would be necessary to dig down (i.e perform some lookup of the full NML representation). Yes, NSI endpoint names (STPs) are technology agnostic. They represent points where the *service* can terminate (whatever the service may be.) The "stitching" points are simply STPs in two adjacent networks that are indicated to correlate to the same *topological location* i.e. if you plug a fiber into a port, the end of the fiber, and the port interface now correlate to the same topological location. Therefore they exhibit the same topological characteristics. Likewise at the service level, if your ethernet service connects to my ethernet service at a particular endpoint on your service and a similar endpoint on my service, then those two endpoints now correlate to the same topological location, and exhibit the same characteristics, and they constitute the inter-domain connection of our two networks, or the stitching point.
Guy
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Radek Krzywania Sent: 29 March 2011 10:26 To: nsi-wg@ogf.org Subject: [Nsi-wg] comments to WSDL files
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 ;) 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...) We should re-iterate this: Since the specifics of physical resources are managed by the NRM there is no need for the NSAs to know about or to specify anything more specific than the network and localname of the endpoint. It is the NRM's job to convert the global NSI address to the local hardware specifics. With regard to WSDLs, the WS implementation of the NSI CS primitives does not redefine any of the NSI semantics. The NSI primitive XML descriptions (the message formats) look the same regardless of whether they are processed by a WS or by a lower layer protocol. I hope this helps explain why we do not include hardware specifics in the provisioning semantics. Why do you say hardware specific end point information would be useful at the interdomain level.?? BR Jerry
Best regards Radek
________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg