[Nsi-wg] comments to WSDL files
Inder Monga
imonga at es.net
Wed Apr 6 08:55:09 CDT 2011
Sorry my email overlapped with yours John. I am having the same issues.
Inder
> ------------------------------------------------------------------------
>
> John MacAuley <mailto:john.macauley at surfnet.nl>
> April 6, 2011 10:35 PM
>
>
> 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.
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
> ------------------------------------------------------------------------
>
> Jerry Sobieski <mailto:jerry at nordu.net>
> April 6, 2011 1:27 PM
>
>
> 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
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
> ------------------------------------------------------------------------
>
> John MacAuley <mailto:john.macauley at surfnet.nl>
> April 6, 2011 11:45 AM
>
>
> 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.
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
> ------------------------------------------------------------------------
>
> Jerry Sobieski <mailto:jerry at nordu.net>
> March 30, 2011 4:13 AM
>
>
> Oops - one thing I should make clear below...
>
> O
> 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
> ------------------------------------------------------------------------
>
> Jerry Sobieski <mailto:jerry at nordu.net>
> March 30, 2011 3:51 AM
>
>
> 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 at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of Radek Krzywania
>> Sent: 29 March 2011 10:26
>> To: nsi-wg at 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 at man.poznan.pl Networking Center
>> +48 61 850 25 26 http://www.man.poznan.pl
>> ________________________________________________________________________
>>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
--
--
Inder Monga
imonga at es.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/a14bfc3c/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1517 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/a14bfc3c/attachment-0002.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1418 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/a14bfc3c/attachment-0003.jpg
More information about the nsi-wg
mailing list