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@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________
Hi Radek, Thanks for taking the time to review the current NSI WSDL. Let me explain how I think the VLAN issue you mention can be resolved... (some caveats... note that this is an area that is still under discussion, so other people may have different views - I have assumed here that STPs are technology agnostic labels) 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. 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. 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). 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 ;) 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
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
- 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
Oops - one thing I should make clear below... O 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
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...
- 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
O 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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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...
- 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
O 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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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...
- 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
O 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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Sorry my email overlapped with yours John. I am having the same issues. Inder
------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@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@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
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- -- Inder Monga imonga@es.net
Jerry and John, It will be great if we can do an simple enough example of going through 3 domains with STP and mapping. Domain ESnet - Domain Surfnet - Domain Nordunet Example 1: ESnet segment ends in STP specified as <ESnet>:<myEndPointZ> maps to <ESnet>:<Router IP address>:Port 0/3: Vlan 2010 in the topology database. OR Example 2: ESnet segment ends in STP specified as <ESnet>:<myEndPointB> maps to <ESnet>:<Router IP address>:Port 0/3 in the topology database and VLAN Range 2000 - 2100 is put in the Service Definition. --------------------------------------------------------- In Example 1 - The segment request to SURFNet should have STP <SURFnet>:<myEndPointA> where <myEndPointA> has to have VLAN 2010 as part of the mapping or an indication of a VLAN translation function. How does the RA figure that out is not clear. Also the burden is on the topology database to distribute 4092 definitions per port if VLAN is used, or 2^16 unique strings when MAC-in-MAC encapsulation is used with new Carrier Ethernet technologies. This frankly is not scalable IMHO, unless I am misinterpreting STPs. In Example 2 - the STP specifies the physical topology connection, while the virtual connections are carried in the Service Definition. With that defined as a range, it allows VLAN translation or picking option by the Surfnet destination. I would prefer Example 2 as a scalable model. I know opinions may vary - but unless we can solve this situation authoritatively, the STP discussion is not going to resolve. Thanks Inder
------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@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@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
nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Guy Roberts <mailto:Guy.Roberts@dante.net> March 29, 2011 7:18 PM
Hi Radek,
Thanks for taking the time to review the current NSI WSDL. Let me explain how I think the VLAN issue you mention can be resolved... (some caveats... note that this is an area that is still under discussion, so other people may have different views - I have assumed here that STPs are technology agnostic labels)
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. 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. 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).
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 ;)
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
-- -- Inder Monga imonga@es.net
participants (5)
-
Guy Roberts -
Inder Monga -
Jerry Sobieski -
John MacAuley -
Radek Krzywania