Here is an update on the inter-domain topology OWL file (the Rio Ring). ---> I deleted the intra-domain Ports. ---> Corrected a mispelled object name. ---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA. ---> Added Admin contact info to the NSA adminContact field. Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line. This topology now contains only NSnetwork objects, STP objects, and NSA objects. Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network. Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged. If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included... Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose. If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so. Best regards! Jerry
Hi Jerry and all, The G-lambda/AIST team's "csProviderEndpoint" will be: http://163.220.30.174:8090/nsi_gl_proxy/services/ConnectionServiceProvider Thanks, Atsuko, AIST 2011/9/1 Jerry Sobieski <jerry@nordu.net>:
Here is an update on the inter-domain topology OWL file (the Rio Ring).
---> I deleted the intra-domain Ports.
---> Corrected a mispelled object name.
---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA.
---> Added Admin contact info to the NSA adminContact field.
Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line.
This topology now contains only NSnetwork objects, STP objects, and NSA objects.
Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network.
Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged.
If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included...
Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose.
If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so.
Best regards! Jerry
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
I have not yet gone through the entire file but I did notice this STP has an STP. <!-- http://www.glif.is/working-groups/tech/dtox#A3 --> <owl:NamedIndividual rdf:about="http://www.glif.is/working-groups/tech/dtox#A3"> <rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/> <rdfs:comment xml:lang="en">Position : [864,558]</rdfs:comment> <hasSTP rdf:resource="http://www.glif.is/working-groups/tech/dtox#Aruba"/> </owl:NamedIndividual> On 2011-08-31, at 12:54 PM, Jerry Sobieski wrote:
Here is an update on the inter-domain topology OWL file (the Rio Ring).
---> I deleted the intra-domain Ports.
---> Corrected a mispelled object name.
---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA.
---> Added Admin contact info to the NSA adminContact field.
Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line.
This topology now contains only NSnetwork objects, STP objects, and NSA objects.
Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network.
Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged.
If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included...
Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose.
If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so.
Best regards! Jerry
<Rio-Inter-Domain-Topo-Ring-v1.1a.owl>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hmm..interesting. I will look into this. Thanks for noticing! Jerry On 9/1/11 8:04 AM, John MacAuley wrote:
I have not yet gone through the entire file but I did notice this STP has an STP.
<!-- http://www.glif.is/working-groups/tech/dtox#A3 -->
<owl:NamedIndividualrdf:about="http://www.glif.is/working-groups/tech/dtox#A3"> <rdf:typerdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/> <rdfs:commentxml:lang="en">Position : [864,558]</rdfs:comment> <hasSTPrdf:resource="http://www.glif.is/working-groups/tech/dtox#Aruba"/> </owl:NamedIndividual>
On 2011-08-31, at 12:54 PM, Jerry Sobieski wrote:
Here is an update on the inter-domain topology OWL file (the Rio Ring).
---> I deleted the intra-domain Ports.
---> Corrected a mispelled object name.
---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA.
---> Added Admin contact info to the NSA adminContact field.
Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line.
This topology now contains only NSnetwork objects, STP objects, and NSA objects.
Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network.
Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged.
If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included...
Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose.
If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so.
Best regards! Jerry
<Rio-Inter-Domain-Topo-Ring-v1.1a.owl>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Hi John- If you use the SNE editor to graphically run a hasSTP link from Aruba to STP A3, it generates correctly. If you run the hasSTP link from the STP A3 to Aruba, it generates the mistake you noted. So I have corrected the topo file. Jeroen- you may want to look at this in the editor. hasSTP should only be allowed to go from NSnetwork object to STP object. We need something else as the reverse relation...maybe "STPof"...? Jerry On 9/1/11 8:04 AM, John MacAuley wrote:
I have not yet gone through the entire file but I did notice this STP has an STP.
<!-- http://www.glif.is/working-groups/tech/dtox#A3 -->
<owl:NamedIndividualrdf:about="http://www.glif.is/working-groups/tech/dtox#A3"> <rdf:typerdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/> <rdfs:commentxml:lang="en">Position : [864,558]</rdfs:comment> <hasSTPrdf:resource="http://www.glif.is/working-groups/tech/dtox#Aruba"/> </owl:NamedIndividual>
On 2011-08-31, at 12:54 PM, Jerry Sobieski wrote:
Here is an update on the inter-domain topology OWL file (the Rio Ring).
---> I deleted the intra-domain Ports.
---> Corrected a mispelled object name.
---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA.
---> Added Admin contact info to the NSA adminContact field.
Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line.
This topology now contains only NSnetwork objects, STP objects, and NSA objects.
Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network.
Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged.
If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included...
Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose.
If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so.
Best regards! Jerry
<Rio-Inter-Domain-Topo-Ring-v1.1a.owl>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Jerry, Jeroen, I am a little confused about the names within the topology files. I thought we would be using the standard naming schemes we decided upon in Salt Lake City. For example, we have a network named "http://www.glif.is/working-groups/tech/dtox#Curacao" when we agreed they would be named using the URN format "urn:ogf:network:nsnetwork: Curacao". Similarly, STPs should be named "urn:ogf:network:stp:Curacao:C1" and I would recommend naming NSAs using the format "urn:ogf:network:nsa:Curacao-AutoBAHN" or maybe "urn:ogf:network:nsa:Curacao:Curacao-AutoBAHN" for completeness. We would therefore get the following for an NSNetwork <owl:NamedIndividual rdf:about="urn:ogf:network:nsnetwork: Curacao"> <rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#NSNetwork"/> <rdfs:comment xml:lang="en">Position : [3690,102]</rdfs:comment> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C1"/> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C2"/> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C3"/> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C4"/> <managedBy rdf:resource="urn:ogf:network:nsa:Curacao:Curacao-AutoBAHN"/> </owl:NamedIndividual> I think this makes it much clearer as to the values someone should use within their requests since it now matches the defined formats for the protocol elements. Thank you, John. On 2011-09-01, at 11:08 AM, Jerry Sobieski wrote:
Hi John-
If you use the SNE editor to graphically run a hasSTP link from Aruba to STP A3, it generates correctly. If you run the hasSTP link from the STP A3 to Aruba, it generates the mistake you noted. So I have corrected the topo file.
Jeroen- you may want to look at this in the editor. hasSTP should only be allowed to go from NSnetwork object to STP object. We need something else as the reverse relation...maybe "STPof"...?
Jerry
On 9/1/11 8:04 AM, John MacAuley wrote:
I have not yet gone through the entire file but I did notice this STP has an STP.
<!-- http://www.glif.is/working-groups/tech/dtox#A3 -->
<owl:NamedIndividual rdf:about="http://www.glif.is/working-groups/tech/dtox#A3"> <rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/> <rdfs:comment xml:lang="en">Position : [864,558]</rdfs:comment> <hasSTP rdf:resource="http://www.glif.is/working-groups/tech/dtox#Aruba"/> </owl:NamedIndividual>
On 2011-08-31, at 12:54 PM, Jerry Sobieski wrote:
Here is an update on the inter-domain topology OWL file (the Rio Ring).
---> I deleted the intra-domain Ports.
---> Corrected a mispelled object name.
---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA.
---> Added Admin contact info to the NSA adminContact field.
Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line.
This topology now contains only NSnetwork objects, STP objects, and NSA objects.
Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network.
Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged.
If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included...
Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose.
If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so.
Best regards! Jerry
<Rio-Inter-Domain-Topo-Ring-v1.1a.owl>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi John and Atsuko - Hmmm...yes, the OWL names are a bit confusing...They rdf outout is not the simple names I tried to use for the SNE graphical layout. What we currently have is not clear, so we need to address the issue. For consistency, simplicity, and expediency sake for Rio, I will go through and change the topo file to use the NSI URN format for network, stp, and nsa names as used by the CS spec... But I have some concerns about the long term usefulness or practicality of doing this. But lets proceed as an interim step to get through Rio - and revisit as part of the followup topology discusions. I will do this and circulate a new topo image shortly. I will also remove the "http....dtox#" prefix - I don't see a value to that at all in present circumstance. Jerry On 9/1/11 10:28 PM, John MacAuley wrote:
Jerry, Jeroen,
I am a little confused about the names within the topology files. I thought we would be using the standard naming schemes we decided upon in Salt Lake City. For example, we have a network named "http://www.glif.is/working-groups/tech/dtox#Curacao" when we agreed they would be named using the URN format "urn:ogf:network:nsnetwork: Curacao". Similarly, STPs should be named "urn:ogf:network:stp:Curacao:C1" and I would recommend naming NSAs using the format "urn:ogf:network:nsa:Curacao-AutoBAHN" or maybe "urn:ogf:network:nsa:Curacao:Curacao-AutoBAHN" for completeness. We would therefore get the following for an NSNetwork
<owl:NamedIndividual rdf:about="urn:ogf:network:nsnetwork: Curacao"> <rdf:type rdf:resource="http://www.glif.is/working-groups/tech/dtox#NSNetwork"/> <rdfs:comment xml:lang="en">Position : [3690,102]</rdfs:comment> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C1"/> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C2"/> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C3"/> <hasSTP rdf:resource="urn:ogf:network:stp:Curacao:C4"/> <managedBy rdf:resource="urn:ogf:network:nsa:Curacao:Curacao-AutoBAHN"/> </owl:NamedIndividual>
I think this makes it much clearer as to the values someone should use within their requests since it now matches the defined formats for the protocol elements.
Thank you, John.
On 2011-09-01, at 11:08 AM, Jerry Sobieski wrote:
Hi John-
If you use the SNE editor to graphically run a hasSTP link from Aruba to STP A3, it generates correctly. If you run the hasSTP link from the STP A3 to Aruba, it generates the mistake you noted. So I have corrected the topo file.
Jeroen- you may want to look at this in the editor. hasSTP should only be allowed to go from NSnetwork object to STP object. We need something else as the reverse relation...maybe "STPof"...?
Jerry
On 9/1/11 8:04 AM, John MacAuley wrote:
I have not yet gone through the entire file but I did notice this STP has an STP.
<!-- http://www.glif.is/working-groups/tech/dtox#A3 -->
<owl:NamedIndividualrdf:about="http://www.glif.is/working-groups/tech/dtox#A3"> <rdf:typerdf:resource="http://www.glif.is/working-groups/tech/dtox#STP"/> <rdfs:commentxml:lang="en">Position : [864,558]</rdfs:comment> <hasSTPrdf:resource="http://www.glif.is/working-groups/tech/dtox#Aruba"/> </owl:NamedIndividual>
On 2011-08-31, at 12:54 PM, Jerry Sobieski wrote:
Here is an update on the inter-domain topology OWL file (the Rio Ring).
---> I deleted the intra-domain Ports.
---> Corrected a mispelled object name.
---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA.
---> Added Admin contact info to the NSA adminContact field.
Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line.
This topology now contains only NSnetwork objects, STP objects, and NSA objects.
Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network.
Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged.
If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included...
Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose.
If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so.
Best regards! Jerry
<Rio-Inter-Domain-Topo-Ring-v1.1a.owl>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Hello, The identifiers in RDF are not completely user-friendly, I agree. The point though is, that they are not intended to be. They serve an identifying function, and the objects themselves have labels that can be used to provide a human-readable label. The editor perhaps does not make it very easy to provide the right prefix for your objects, but we should perhaps work on that. On 2 Sep 2011, at 17:15, Jerry Sobieski wrote:
I will also remove the "http....dtox#" prefix - I don't see a value to that at all in present circumstance.
Please don't remove the prefix completely. If you do want to change it, change it to something else. Otherwise we can run into all kinds of mixups with objects sharing the same identifiers, etc. Jeroen.
participants (4)
-
Atsuko Takefusa -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley