[Nsi-wg] comments to WSDL files

[John MacAuley]

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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110405/0cf370fe/attachment.bin