=================================== http://ngn.andong.ac.kr NGN Lab. Comp. Engineering Dept. Andong National University +82-10-2456-3237, +82-54-820-5714 =================================== ----- Original Message ----- From: <nsi-wg-request@ogf.org> To: <nsi-wg@ogf.org> Sent: Monday, August 22, 2011 9:15 PM Subject: nsi-wg Digest, Vol 36, Issue 23
Send nsi-wg mailing list submissions to nsi-wg@ogf.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.ogf.org/mailman/listinfo/nsi-wg or, via email, send a message with subject or body 'help' to nsi-wg-request@ogf.org
You can reach the person managing the list at nsi-wg-owner@ogf.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of nsi-wg digest..."
Today's Topics:
1. Re: NSI specific topology recommendation for plug fest. (John MacAuley) 2. Re: NSI specific topology recommendation for plug fest. (Jeroen van der Ham) 3. Re: NSI specific topology recommendation for plug fest. (Jerry Sobieski)
----------------------------------------------------------------------
Message: 1 Date: Mon, 22 Aug 2011 00:39:54 -0400 From: John MacAuley <john.macauley@surfnet.nl> Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug fest. To: John MacAuley <john.macauley@surfnet.nl> Cc: NSI WG <nsi-wg@ogf.org> Message-ID: <7769F884-3DA9-412B-8599-1A3B64730CCA@surfnet.nl> Content-Type: text/plain; charset="windows-1252"
Found a small issue in the example owl.
On 2011-08-19, at 10:16 PM, John MacAuley wrote:
Peoples,
I think the existing detailed DTOX topology models we have been generating are excellent. I can definitely see how I will be able to incorporate this into future versions of OpenDRAC as a primary topology import mechanism, however, I do not think it is capturing the simplified concepts in NSI that are needed for the demo.
I have been playing around with the example topologies trying to massage them into a form where I can learn not only the network and STP topologies, but the managing NSA topologies as well. I found that the existing DTOX topology is very good at the details of nodes, switch matrixes, and ports, but I had a hard time filtering down to the simple aspects. I also believe we will get into some trouble if we try to use the port class to model STP while also modeling physical ports. I am not sure if the DTOX schema can handle this aspect, as I could not find a describing schema.
I spent time over the last couple of days discussing this with Jerry while we worked through the plug fest scenarios. He provided good feedback and pulled together the attached slide showing the concepts we are trying to capture. I also mocked up an example OWL file with an NSI topology specific name space, and introduced the NSI concepts of NSnetwork, STP, and NSA. These classes are used to model their simplified namesakes from the NSI CS protocol, and are not meant to replace the DTOX definitions, but augment them with our NSI specific concepts. We can consider the NSI topology elements an overlay on the existing DTOX elements, reusing data properties and including references to DTOX object instances. (I removed the DTOX object instances from the file to simplify the example). I think this will become much clearer when running NSI on out real networks and not this abstract topology for the demo.
I have not yet validated the attached OWL so I apologize if it contains errors. The following classes and properties are introduced in the file?
NSnetwork: We model a NSI network with the NSnetwork class.
Example URN: urn:ogf:network:NSnetwork:Aruba
Properties:
? label - display name for the network. ? canSwap - indicates VLAN Id interchange is supported in the network domain. ? managedBy - the Network Services Agent managing this network. ? hasSTP - a set of references to the inter-domain Service Termination Points that are within this network. ? hasPart - a set of references to the DTOX Node NamedIndividual representing network elements within this network.
NSA: We model a Network Services Agent with the NSA class.
Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl
Properties:
? label - display name for the NSA. ? managing - indicates the network being managed by this NSA. ? connectedTo - represents an NSA to which this NSA has a peering relationship. ? dnsName - DNS name of the NSA. ? csProviderEndpoint - the SOAP endpoint for this NSA's CS provider interface. ? adminContact - administrative contact information for this NSA.
STP: We model a logical Service Termination point with the STP class.
Example URN: urn:ogf:network:stp:Aruba:Aiden
Properties:
? label - display name for this STP. ? partOf - indicates the member network of this STP. ? connectedTo - a topological link identifying the peer STP to which this STP is connected. ? mapsTo - the logical STP represented by this object instance maps through to this physical entity (port, vlan, etx.) in DTOX.
We will need to start up a discussion after the plug fest to address the issue of NSI topology needs. I believe these changes will do until then. Comments?
Thank you, John.
<nsi-interop-topology-example.owl> <NSI topology model.pptx> _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachment... -------------- next part -------------- A non-text attachment was scrubbed... Name: nsi-interop-topology-example.owl Type: application/octet-stream Size: 12053 bytes Desc: not available Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachment... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110822/675dbc7c/attachment...
------------------------------
Message: 2 Date: Mon, 22 Aug 2011 11:10:26 +0200 From: Jeroen van der Ham <vdham@uva.nl> Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug fest. To: John MacAuley <john.macauley@surfnet.nl> Cc: NSI WG <nsi-wg@ogf.org> Message-ID: <2EDE9B14-3E07-4C19-9BCC-A2EE695B5484@uva.nl> Content-Type: text/plain; charset=iso-8859-1
Hello,
NSnetwork: We model a NSI network with the NSnetwork class. =20 Example URN: urn:ogf:network:NSnetwork:Aruba =20 Properties: =20 =B7 label - display name for the network. =B7 canSwap - indicates VLAN Id interchange is supported in the = network domain. =B7 managedBy - the Network Services Agent managing this network. =B7 hasSTP - a set of references to the inter-domain Service = Termination Points that are within this network. =B7 hasPart - a set of references to the DTOX Node = NamedIndividual representing network elements within this network. =20 =20 NSA: We model a Network Services Agent with the NSA class. =20 Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl =20 Properties: =20 =B7 label - display name for the NSA. =B7 managing - indicates the network being managed by this NSA. =B7 connectedTo - represents an NSA to which this NSA has a =
=B7 dnsName - DNS name of the NSA. =B7 csProviderEndpoint - the SOAP endpoint for this NSA's CS =
=B7 adminContact - administrative contact information for this = NSA. =20 STP: We model a logical Service Termination point with the STP class. =20 Example URN: urn:ogf:network:stp:Aruba:Aiden =20 Properties: =20 =B7 label - display name for this STP. =B7 partOf - indicates the member network of this STP. =B7 connectedTo - a topological link identifying the peer STP to = which this STP is connected. =B7 mapsTo - the logical STP represented by this object instance = maps through to this physical entity (port, vlan, etx.) in DTOX. =20 We will need to start up a discussion after the plug fest to address =
On 20 Aug 2011, at 04:16, John MacAuley wrote: peering relationship. provider interface. the issue of NSI topology needs. I believe these changes will do until = then. Comments?
=20
How do you envision labels to be added to the above topology?
The ontology above maps almost directly to the DTOX schema we created = before we started considering labels...
The current test-topologies may not have labels in them, but as things = look now, they will always be part of the network, and will always be = something to consider when you are doing pathfinding.
Jeroen.=
------------------------------
Message: 3 Date: Mon, 22 Aug 2011 08:15:09 -0400 From: Jerry Sobieski <jerry@nordu.net> Subject: Re: [Nsi-wg] NSI specific topology recommendation for plug fest. To: Jeroen van der Ham <vdham@uva.nl> Cc: NSI WG <nsi-wg@ogf.org> Message-ID: <7377BC40-AF8C-4FBD-B5D4-AF87DBDDED3D@nordu.net> Content-Type: text/plain; charset=utf-8
Hi jeroen
The issue is that currently NSI service termination points do not point to u= nder-specified endpoints such as ports with labels. As it stands today an N= SI STP would point to a particular label as the termination point for a circ= uit. To put something other than the terminating point of the circuit in t= he NSI reservation request implies a certain semantic about what specificall= y can be found in a request as an Endpoint and how to recognize and process i= t. We got into this briefly but decided it involved a lot of topology issu= es we were not able to address or answer at that time - so we shelved it unt= il we had a chance to discuss a more sophisticated NSI topology model.
For now, for the plugfest, we can treat Ports as the STP. We will define a= ll interdomain peering points as untagged ports for the interop plugfest in R= io. In the Port object we either define a single label, (e.g. "0") or be= tter, no label at all. This must be coordinated with the peer network so th= at their corresponding Port object is defined similarly.
IMO, the NSI working group has not worked out a consensus approach to how we= expect the protocol to treat "labels"...else it would already be in the sta= ndard. Strictly speaking, the NSI CS protocol works just fine as is - it j= ust maps STPs to particular labels. (note: the SNE editor offered no Label= object.) However, a number of folks are uncomfortable with this and want a= different treatment. We need to have this discussion, but there are relate= d issues we need to work through if we want all of these features to integra= te in a cohesive and fashion. =20
Sent from my iPad3g
On Aug 22, 2011, at 5:10 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello, =20 =20 On 20 Aug 2011, at 04:16, John MacAuley wrote:
forNSnetwork: We model a NSI network with the NSnetwork class. =20 Example URN: urn:ogf:network:NSnetwork:Aruba =20 Properties: =20 =C2=B7 label - display name for the network. =C2=B7 canSwap - indicates VLAN Id interchange is supported in the n= etwork domain. =C2=B7 managedBy - the Network Services Agent managing this network.=
=C2=B7 hasSTP - a set of references to the inter-domain Service Term= ination Points that are within this network. =C2=B7 hasPart - a set of references to the DTOX Node NamedIndividua= l representing network elements within this network. =20 =20 NSA: We model a Network Services Agent with the NSA class. =20 Example URN: urn:ogf:network:nsa:dracproxy01.surfnet.nl =20 Properties: =20 =C2=B7 label - display name for the NSA. =C2=B7 managing - indicates the network being managed by this NSA. =C2=B7 connectedTo - represents an NSA to which this NSA has a peeri= ng relationship. =C2=B7 dnsName - DNS name of the NSA. =C2=B7 csProviderEndpoint - the SOAP endpoint for this NSA's CS prov= ider interface. =C2=B7 adminContact - administrative contact information for this NS= A. =20 STP: We model a logical Service Termination point with the STP class. =20 Example URN: urn:ogf:network:stp:Aruba:Aiden =20 Properties: =20 =C2=B7 label - display name for this STP. =C2=B7 partOf - indicates the member network of this STP. =C2=B7 connectedTo - a topological link identifying the peer STP to w= hich this STP is connected. =C2=B7 mapsTo - the logical STP represented by this object instance m= aps through to this physical entity (port, vlan, etx.) in DTOX. =20 We will need to start up a discussion after the plug fest to address the i= ssue of NSI topology needs. I believe these changes will do until then. Co= mments? =20 =20 How do you envision labels to be added to the above topology? =20 The ontology above maps almost directly to the DTOX schema we created befo= re we started considering labels... =20 The current test-topologies may not have labels in them, but as things loo= k now, they will always be part of the network, and will always be something= to consider when you are doing pathfinding. =20 Jeroen.
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
End of nsi-wg Digest, Vol 36, Issue 23 **************************************