Peoples, I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message. John.
Hi all, I have several comments on the current schema as below. Thanks, Atsuko (AIST, G-lambda) -- * CommonParametersGroup - transactionId Who determines transactionId? It should be minOccurs=”0” if providers do. * ReservationGroup - connectionId As above, it should be minOccurs=”0” if provider does. * ScheduleType - startType Does the first release support immediate reservation? If support, startType shold be minOccurs=”0” or a new parameter should be defined. - duration xsd:long is better than xsd:integer. In addition, it’s unit is not explicitly defined in the schema. In the G-lambda’s schema, we define duration as follows: <xsd:complexType name="Duration_Type"> <xsd:sequence> <xsd:element ref="rdl:DurationValue"/> <xsd:element ref="rdl:TimeUnit"/> </xsd:sequence> </xsd:complexType> <xsd:element name="DurationValue" type="xsd:long"/> <xsd:simpleType name="TimeUnit_Type"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="MILLISECOND"/> <xsd:enumeration value="SECOND"/> <xsd:enumeration value="MINUTE"/> <xsd:enumeration value="HOUR"/> <xsd:enumeration value="DAY"/> <xsd:enumeration value="WEEK"/> <xsd:enumeration value="MONTH"/> <xsd:enumeration value="YEAR"/> </xsd:restriction> </xsd:simpleType> * BandwidthType It’s unit is not explicitly defined in the schema. The G-lambda’s schema defines as follows: <xsd:complexType name="GeneralBW_Type"> <xsd:sequence> <xsd:element ref="ndl:Rate" minOccurs="1" maxOccurs="1" /> <xsd:element ref="ndl:BWUnit" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> <xsd:element name="Rate" type="xsd:int"/> <xsd:simpleType name="BWUnit_Type"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Pbps"/> <xsd:enumeration value="Tbps"/> <xsd:enumeration value="Gbps"/> <xsd:enumeration value="Mbps"/> <xsd:enumeration value="kbps"/> <xsd:enumeration value="bps"/> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> * OrderedServiceTerminationPointType - order <xsd:attribute name="order" type="xsd:integer"/> should be removed. Because each array order is ensured in SOAP messages and we (provider and aggregator) have to renumber if STPs are inserted or removed. * namespace I think that namespace is generally defined in OGF schemas as follows: namespace="http://schemas.ogf.org/nsi/2011/03/connection" ("http://www.ogf.org/schema/nsi/connection/v1_0/types") E.g., JSDL : "http://schemas.ggf.org/jsdl/2005/11/jsdl" GLUE : "http://schemas.ogf.org/glue/2008/05/spec_2.0_d42_r01" 2011/3/24 John MacAuley <john.macauley@surfnet.nl>:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
Thank you for the comments. I have added comments below. On 2011-03-23, at 10:49 PM, Atsuko Takefusa wrote:
Hi all,
I have several comments on the current schema as below. Thanks,
Atsuko (AIST, G-lambda)
--
* CommonParametersGroup - transactionId Who determines transactionId? It should be minOccurs=”0” if providers do.
The agreement was that the requester must provide the value.
* ReservationGroup - connectionId As above, it should be minOccurs=”0” if provider does.
Likewise the requester must provide the value.
* ScheduleType - startType Does the first release support immediate reservation? If support, startType shold be minOccurs=”0” or a new parameter should be defined.
The agreement was to remove the immediate type and just set the start time to the time of the request.
- duration xsd:long is better than xsd:integer. In addition, it’s unit is not explicitly defined in the schema. In the G-lambda’s schema, we define duration as follows: <xsd:complexType name="Duration_Type"> <xsd:sequence> <xsd:element ref="rdl:DurationValue"/> <xsd:element ref="rdl:TimeUnit"/> </xsd:sequence> </xsd:complexType> <xsd:element name="DurationValue" type="xsd:long"/> <xsd:simpleType name="TimeUnit_Type"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="MILLISECOND"/> <xsd:enumeration value="SECOND"/> <xsd:enumeration value="MINUTE"/> <xsd:enumeration value="HOUR"/> <xsd:enumeration value="DAY"/> <xsd:enumeration value="WEEK"/> <xsd:enumeration value="MONTH"/> <xsd:enumeration value="YEAR"/> </xsd:restriction> </xsd:simpleType>
I was actually thinking of changing this to the "xsd:duration" type which provides a standard way of describing duration.
* BandwidthType It’s unit is not explicitly defined in the schema. The G-lambda’s schema defines as follows: <xsd:complexType name="GeneralBW_Type"> <xsd:sequence> <xsd:element ref="ndl:Rate" minOccurs="1" maxOccurs="1" /> <xsd:element ref="ndl:BWUnit" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> <xsd:element name="Rate" type="xsd:int"/> <xsd:simpleType name="BWUnit_Type"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Pbps"/> <xsd:enumeration value="Tbps"/> <xsd:enumeration value="Gbps"/> <xsd:enumeration value="Mbps"/> <xsd:enumeration value="kbps"/> <xsd:enumeration value="bps"/> </xsd:enumeration> </xsd:restriction> </xsd:simpleType>
I put it in the comment that it must be Mbps. Do we really need the distinction? Anyone really want to specify less that Mbps? I have no issue adding it if people agree.
* OrderedServiceTerminationPointType - order <xsd:attribute name="order" type="xsd:integer"/> should be removed. Because each array order is ensured in SOAP messages and we (provider and aggregator) have to renumber if STPs are inserted or removed.
Very interesting. I will need to check into that. I was not sure if a sequence was maintained in order during conversion from XML to Java.
* namespace I think that namespace is generally defined in OGF schemas as follows: namespace="http://schemas.ogf.org/nsi/2011/03/connection" ("http://www.ogf.org/schema/nsi/connection/v1_0/types") E.g., JSDL : "http://schemas.ggf.org/jsdl/2005/11/jsdl" GLUE : "http://schemas.ogf.org/glue/2008/05/spec_2.0_d42_r01"
Yes, I still have an action item to get a namespace allocated.
2011/3/24 John MacAuley <john.macauley@surfnet.nl>:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
Hey John- I have a few concerns about this sample Reservation Request: - I chg'd security attributes to <sessionSecutiyAttrib> as I believe there are two levels of authorization: First, the RA NSA must be authenticated and authorized to even talk to the PA NSA. Second, the service request itself must be authorized by the network(s) along the path. So I also added an authorization element to the service parameters - I added a "serviceDefinition" field in the reservation request. While this could be omitted, I think its useful to explicitly state the service you are expecting...and it could help the pathfinder construct a candidate path. - I put all schedule inside the service parameters - these are constraints on the service...not something independent of the service. - Changed the STP names: I added a "NORDUnet" network name and a simple "foo" local part just to make sure the request functions with these legal names. - I removed the path object from the source and dest STPs - This is arguable, but I felt this was more consistent with the other service parameters. I don't think we have a justification anymore for a PathObject with intermediate STPs...such a thing is just a Tree style segmentation. But if folks want to keep this PO with the src and dst, I don't have a big deal with it. I am almost of a mind to suggest we define all service parameters like you did the security attributes: <attribute> <attributeName> NameThing </attributeName> <attributeValue> abcd </attributeValue> </attribute> This would make the service definition XSD easier I think. Let me know what you think. Jerry On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Jerry, What is the expected NSA behaviour with respect to the <serviceDefinition> element? <serviceDefinition>file://user/jerry/EthernetFramedPayloadService.xml</serviceDefinition> Should the receiving NSA be able to interpret this in some way to provide request context? John. On 2011-03-25, at 10:42 PM, Jerry Sobieski wrote:
Hey John-
I have a few concerns about this sample Reservation Request:
- I chg'd security attributes to <sessionSecutiyAttrib> as I believe there are two levels of authorization: First, the RA NSA must be authenticated and authorized to even talk to the PA NSA. Second, the service request itself must be authorized by the network(s) along the path. So I also added an authorization element to the service parameters
- I added a "serviceDefinition" field in the reservation request. While this could be omitted, I think its useful to explicitly state the service you are expecting...and it could help the pathfinder construct a candidate path.
- I put all schedule inside the service parameters - these are constraints on the service...not something independent of the service.
- Changed the STP names: I added a "NORDUnet" network name and a simple "foo" local part just to make sure the request functions with these legal names.
- I removed the path object from the source and dest STPs - This is arguable, but I felt this was more consistent with the other service parameters. I don't think we have a justification anymore for a PathObject with intermediate STPs...such a thing is just a Tree style segmentation. But if folks want to keep this PO with the src and dst, I don't have a big deal with it.
I am almost of a mind to suggest we define all service parameters like you did the security attributes: <attribute> <attributeName> NameThing </attributeName> <attributeValue> abcd </attributeValue> </attribute> This would make the service definition XSD easier I think.
Let me know what you think. Jerry
On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
<ogf_nsi_reserve_message_1_0sob.xml>
The intent (I am a novice XML/XSD developer) is now that we develope a workable XSD that describes an Etehrnet transport Service. This will be the Service Definition. Each network can modify theirs slightly to reflect minor service differences. The SD is distributed with topology and so is stored in the topology DB with the associated network/domain node. The Service Request is received by an NSA. The NSA starts by locating the origination STP in his topologyDB, and finds a SD associated with that network. He validates the SR with the SD. If thats good, he creates a child segment and forwards that to that network for reservation. He modifies the SR to reflect new endpoints, and repeats the process. For what I expect DRAC would do... The DRAC NSA would recieve the SR, look at the end points, find the origSTp network SD, validates the SR.xml using the SD.xsd, if ok, he will issue a child segment to that network. The NSA will modify the SR to reflect new endpoints, find the next hop network, grab the SD, validate the SR, issue the child resv, and repeat. When the NSA creates a segment of just localorig and localdest, it will know its time to send the request to DRAC. IT will look up the endpoint names in a local name table and pull the associated DRAC designators outand return them. The NSA will insert the DRAC designators into a package for DRAC and send it off. Is this helpful? J On 4/5/11 11:36 PM, John MacAuley wrote:
Jerry,
What is the expected NSA behaviour with respect to the <serviceDefinition> element?
<serviceDefinition>file://user/ <file:///user/>jerry/EthernetFramedPayloadService.xml</serviceDefinition>
Should the receiving NSA be able to interpret this in some way to provide request context?
John.
On 2011-03-25, at 10:42 PM, Jerry Sobieski wrote:
Hey John-
I have a few concerns about this sample Reservation Request:
- I chg'd security attributes to <sessionSecutiyAttrib> as I believe there are two levels of authorization: First, the RA NSA must be authenticated and authorized to even talk to the PA NSA. Second, the service request itself must be authorized by the network(s) along the path. So I also added an authorization element to the service parameters
- I added a "serviceDefinition" field in the reservation request. While this could be omitted, I think its useful to explicitly state the service you are expecting...and it could help the pathfinder construct a candidate path.
- I put all schedule inside the service parameters - these are constraints on the service...not something independent of the service.
- Changed the STP names: I added a "NORDUnet" network name and a simple "foo" local part just to make sure the request functions with these legal names.
- I removed the path object from the source and dest STPs - This is arguable, but I felt this was more consistent with the other service parameters. I don't think we have a justification anymore for a PathObject with intermediate STPs...such a thing is just a Tree style segmentation. But if folks want to keep this PO with the src and dst, I don't have a big deal with it.
I am almost of a mind to suggest we define all service parameters like you did the security attributes: <attribute> <attributeName> NameThing </attributeName> <attributeValue> abcd </attributeValue> </attribute> This would make the service definition XSD easier I think.
Let me know what you think. Jerry
On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg <ogf_nsi_reserve_message_1_0sob.xml>
So this is URI is a reference to a local NSA file representing the desired SID for the request? Can I assume then that an NSA will not dynamically retrieve this file from the specified location and has pre-knowledge that it exists? If so then I think exposing internal filesystem structure is probably a bit dangerous so we should look at a couple of options: 1. We could use the ServiceName of the SID. 2. We could use a public URL used to access the resource on the NSA (i.e. http://nas.ip.address.com/nsi/connection/EthernetFramedPayloadService.xml). 3. Assign a namespace to each SID and use this in the reference. John On 2011-04-06, at 12:15 AM, Jerry Sobieski wrote:
The intent (I am a novice XML/XSD developer) is now that we develope a workable XSD that describes an Etehrnet transport Service. This will be the Service Definition. Each network can modify theirs slightly to reflect minor service differences. The SD is distributed with topology and so is stored in the topology DB with the associated network/domain node.
The Service Request is received by an NSA. The NSA starts by locating the origination STP in his topologyDB, and finds a SD associated with that network. He validates the SR with the SD. If thats good, he creates a child segment and forwards that to that network for reservation. He modifies the SR to reflect new endpoints, and repeats the process.
For what I expect DRAC would do... The DRAC NSA would recieve the SR, look at the end points, find the origSTp network SD, validates the SR.xml using the SD.xsd, if ok, he will issue a child segment to that network. The NSA will modify the SR to reflect new endpoints, find the next hop network, grab the SD, validate the SR, issue the child resv, and repeat. When the NSA creates a segment of just localorig and localdest, it will know its time to send the request to DRAC. IT will look up the endpoint names in a local name table and pull the associated DRAC designators outand return them. The NSA will insert the DRAC designators into a package for DRAC and send it off.
Is this helpful? J
On 4/5/11 11:36 PM, John MacAuley wrote:
Jerry,
What is the expected NSA behaviour with respect to the <serviceDefinition> element?
<serviceDefinition>file://user/jerry/EthernetFramedPayloadService.xml</serviceDefinition>
Should the receiving NSA be able to interpret this in some way to provide request context?
John.
On 2011-03-25, at 10:42 PM, Jerry Sobieski wrote:
Hey John-
I have a few concerns about this sample Reservation Request:
- I chg'd security attributes to <sessionSecutiyAttrib> as I believe there are two levels of authorization: First, the RA NSA must be authenticated and authorized to even talk to the PA NSA. Second, the service request itself must be authorized by the network(s) along the path. So I also added an authorization element to the service parameters
- I added a "serviceDefinition" field in the reservation request. While this could be omitted, I think its useful to explicitly state the service you are expecting...and it could help the pathfinder construct a candidate path.
- I put all schedule inside the service parameters - these are constraints on the service...not something independent of the service.
- Changed the STP names: I added a "NORDUnet" network name and a simple "foo" local part just to make sure the request functions with these legal names.
- I removed the path object from the source and dest STPs - This is arguable, but I felt this was more consistent with the other service parameters. I don't think we have a justification anymore for a PathObject with intermediate STPs...such a thing is just a Tree style segmentation. But if folks want to keep this PO with the src and dst, I don't have a big deal with it.
I am almost of a mind to suggest we define all service parameters like you did the security attributes: <attribute> <attributeName> NameThing </attributeName> <attributeValue> abcd </attributeValue> </attribute> This would make the service definition XSD easier I think.
Let me know what you think. Jerry
On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
<ogf_nsi_reserve_message_1_0sob.xml>
I changed the <securityAttr> element to <sessionSecurityAttr> as requested. I have gone through the other changes and need to discuss the structure of the reservation in your modified example: <reservation> <globalReservationId>urn:uuid:e7712ca0-d85f-4176-8f43-2981a988813a</globalReservationId> <description>This is an example schedule request.</description> <connectionId>1234567890</connectionId> <serviceDefinition>file://user/jerry/EthernetFramedPayloadService.xml</serviceDefinition> <serviceParameters> <sourceSTP> <networkId>NORDUnet</networkId> <localId>cph-ps</localId> </sourceSTP> <destSTP> <networkId>netherlight.net</networkId> <localId>urn:ogf:network:domain=netherlight.net:node=f25s1t:port=0-21:link=dlp01.surfnet.nl</localId> </destSTP> <authorizationAttrib> <certificate>c450f23a</certificate> </authorizationAttrib> <bandwidth> <bytesPerSecond>1000</bytesPerSecond> </bandwidth> <maxBurstSize> <bytes>100000</bytes> </maxBurstSize> <directionality>bidirectional</directionality> <schedule> <startTime>2011-05-30T09:30:10-06:00</startTime> <endTime>2011-05-30T10:30:10-06:00</endTime> </schedule> </serviceParameters> </reservation> You have added some additional elements here within the reservation, and modified by definition of bandwidth. Can I assume you do not want these as dedicated elements but flexible attributes as discovered from the Service Definition? Do we need to have required and best effort SD attributes? For example, could we specify these either using your SD schema, or the <AttributeSequenceType> <guaranteed> <attribute> <attributeName>maxBurstSize</attributeName> <attributeValue>100000</attributeValue> <attributeValue>bytes</attributeValue> </attribute> <attribute> <attributeName>bandwidth</attributeName> <attributeValue>1000</attributeValue> <attributeValue>bytesPerSecond</attributeValue> </attribute> </guaranteed> We could break out a specific attributeUnit to make it even clearer. <guaranteed> <attribute> <attributeName>maxBurstSize</attributeName> <attributeValue>100000</attributeValue> <attributeUnit>bytes</attributeUnit> </attribute> <attribute> <attributeName>bandwidth</attributeName> <attributeValue>1000</attributeValue> <attributeUnit>bytesPerSecond</attributeUnit> </attribute> </guaranteed> I know you want to have SD attributes that are not defined until after the fact, so we need to be careful to clearly define the XSD structure in a generic way. John. On 2011-03-25, at 10:42 PM, Jerry Sobieski wrote:
Hey John-
I have a few concerns about this sample Reservation Request:
- I chg'd security attributes to <sessionSecutiyAttrib> as I believe there are two levels of authorization: First, the RA NSA must be authenticated and authorized to even talk to the PA NSA. Second, the service request itself must be authorized by the network(s) along the path. So I also added an authorization element to the service parameters
- I added a "serviceDefinition" field in the reservation request. While this could be omitted, I think its useful to explicitly state the service you are expecting...and it could help the pathfinder construct a candidate path.
- I put all schedule inside the service parameters - these are constraints on the service...not something independent of the service.
- Changed the STP names: I added a "NORDUnet" network name and a simple "foo" local part just to make sure the request functions with these legal names.
- I removed the path object from the source and dest STPs - This is arguable, but I felt this was more consistent with the other service parameters. I don't think we have a justification anymore for a PathObject with intermediate STPs...such a thing is just a Tree style segmentation. But if folks want to keep this PO with the src and dst, I don't have a big deal with it.
I am almost of a mind to suggest we define all service parameters like you did the security attributes: <attribute> <attributeName> NameThing </attributeName> <attributeValue> abcd </attributeValue> </attribute> This would make the service definition XSD easier I think.
Let me know what you think. Jerry
On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
<ogf_nsi_reserve_message_1_0sob.xml>
Oh...a couple other comments I forgot: First, the <nsaAddresses> examples do not seem right... The message should reference a RA NSA and a PA NSA... Those should not need a domain reference...just the NSA identifier. First, NSI context has no notion of a "domain"... but more importantly, we need to specify where to find an NSA...it should ultimately resolve to an IP address (v4 or v6) and a TCP port that NSA is listening to. The NSA location can be specified in a symbolic name manner, but it needs to be specific to the transport layer it is using, and should not be handled differently in the protocol for different transport layers. So an NSA locator string could be: "NSA.NORDU.net:2764" meaning the NSA is listening to port 2764 on the server nsa.nordu.net. Or we could do "urn:ogf:network: netherlight.edu" and assume it is using a default port that is documented somewhere. We need to come to closure on NSA resolution. I.e. How do we specify an NSA location? Is it an IP address and TCP port? Is it a standard DNS name? a URN of some sort? Also, the string you referenced as a local part of the netherlight.edu STP is probably not valid if we use the colon seperated tuple for NSI endpoints. Endpoints will be referenced outside of XML contexts. And endpoint strings will be used in many other manners than simply the local NRM. Therefore, I think it is imperative that we make sure the name strings are as simple as possible. For instance is a network name case sensitive? Can it have colons ":" embedded in it? Or will that hose the tuple mechanism for naming? Are spaces allowed? are linefeeds? Are contiguous spaces significant? I was hoping we could let the local strings be whatever the local NSA wants them to be, but I think we need to be a bit more specific about how we expect to be able to use endpoint names. We need to specify some constraints on the string values that make up NSI names. I suggest case-insensitive, no spaces, alphanumeric, and maybe a small set of special characters. Jerry On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
So are you implying that the <nsaAddress> is element is not just an opaque reference, but an actual protocol address? Would this not conflict with the requirement not to put any transport implementation specific fields on the protocol? I have defined the <nsaAddress> element as an anyURI because I anticipated you would be asking for this as soon as you saw my example. If you want to model the NSA address as a UDP port it can be done with the URI format <nsaAddress>udp://NSA.NORDU.net:2764</nsaAddress> or for TCP <nsaAddress>tcp://NSA.NORDU.net:2764</nsaAddress> all accomplished through the magic of the URI. These are still protocol specific so you might want to revert back to my nice abstract name :-) As for not using STP in the <localId> of the STP... I am not sure specifying a colon as an internal string separator is a good idea when URI/URL are now becoming a de facto standard for naming resources. Some of the organizations that will participate in the NSI testbed use this naming format already, and we should not force them to change. I also do not think we should be specifying a restricted character set for naming in the NSI with so many standardized naming schemes available in RFCs. Jerry... Come over to the dark side.. Which raises another question. Should naming support multi-byte characters (UTF-8)? John. On 2011-03-25, at 11:15 PM, Jerry Sobieski wrote:
Oh...a couple other comments I forgot:
First, the <nsaAddresses> examples do not seem right... The message should reference a RA NSA and a PA NSA... Those should not need a domain reference...just the NSA identifier. First, NSI context has no notion of a "domain"... but more importantly, we need to specify where to find an NSA...it should ultimately resolve to an IP address (v4 or v6) and a TCP port that NSA is listening to. The NSA location can be specified in a symbolic name manner, but it needs to be specific to the transport layer it is using, and should not be handled differently in the protocol for different transport layers.
So an NSA locator string could be: "NSA.NORDU.net:2764" meaning the NSA is listening to port 2764 on the server nsa.nordu.net. Or we could do "urn:ogf:network: netherlight.edu" and assume it is using a default port that is documented somewhere.
We need to come to closure on NSA resolution. I.e. How do we specify an NSA location? Is it an IP address and TCP port? Is it a standard DNS name? a URN of some sort?
Also, the string you referenced as a local part of the netherlight.edu STP is probably not valid if we use the colon seperated tuple for NSI endpoints. Endpoints will be referenced outside of XML contexts. And endpoint strings will be used in many other manners than simply the local NRM. Therefore, I think it is imperative that we make sure the name strings are as simple as possible. For instance is a network name case sensitive? Can it have colons ":" embedded in it? Or will that hose the tuple mechanism for naming? Are spaces allowed? are linefeeds? Are contiguous spaces significant? I was hoping we could let the local strings be whatever the local NSA wants them to be, but I think we need to be a bit more specific about how we expect to be able to use endpoint names.
We need to specify some constraints on the string values that make up NSI names. I suggest case-insensitive, no spaces, alphanumeric, and maybe a small set of special characters.
Jerry
On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Ok...I have been thinking on this NSA addressing issue a lot recently... There are times when we do not want to forward a request to the NSA associated with an endpoint. One is a federating NSA that announces an internal network we need. Another is just a transit network we need to use because we don't know how to reach the real nsa. For these reasons we should not expect the network name associated with an endpoint to map us directly to the appropriate NSA for forwarding the request. But this is a simple problem, a local name table (in topology DB?) maps a network we know about to an NSA delivery address. Nordu.net.ETS={ KTH, DTU,Stocholm.edu} says Nordu.net.ETS speaks for these other network NSI networks. All this will be clearer when we work on topology distribution, but for now, all we can say is that there are only a few ways we could find out where to send a message to an NSA: 1. The NSA IP /port addr is configured by hand and read into the topology DB at NSA initiatization. 2. We learn about a remote NSA from an automated Toplogy distribution process. 3. There is some "well known" place to start ala DNS resolver. 4. Global file someplace. Number 4 does not scale and is unreliable. Might work in an experiment, but not in a standard. Number 3 requires other services and is similar to number 4. Certainly too complex for now...and not necessary IMO. Number 1 is the obvious place to start - we configure the Network name and associated contact address manually. These form the initial direct peerings that we have arranged with other networks (ala BGP peers) These initial NSA peers will presumably offer us topology - which contains network announcements(2). IMO, associating the NSA contact info with the network topology object is the perfect location. We can use the topology to build an incrementally more comprehensive set of Networks and associated NSA contact info. I think I like your suggestion to specify it as <nsaAddress>tcp://NSA.NORDU.net:2764</nsaAddress> in the topodb, but in the NSI message, I think I prefer a context free spec: maybe just the network name. So if you are a PA and send amessage to the RA at Nordunet, the RAnsaAddress in the ReserveConfirm would just be "Nordu.net" or "Nordu.net.ETS" (for the Ethernet service). These would be found in the topodb and the associated ipaddr or the URi would be used to actually send the messgae. AS for the tuple syntax, I agree. The colon has implications for URNs...but the GLIF guys knew that too...why did they choose it none the less? I am not wed to using that specific syntax, but I do like the form <network><divider><localname>. Indeed, I would have suggested a more hierarchichal aproach ala //Nordu.net/endpoint1, or Internet2.edu/MAX/UMD/perfSonar which would allow easier federation.... But for now, we have the two part tuple. Lets stick with that. We can review the separator character, and the string syntax, but lets keep the two part tuple. It works well in some key ways. What do you suggest? (Note- I will blow a fuse if you try to encode physical information into these names for direct use by DRAC or any other NRM - it won't work in real world. :-) Whatever we do, we need to keep the NSI names and objects abstracted from any particular hardware, technology, or NRM. These have to work across all of them. Peace brother:-) Gotta sleep now. J On 4/5/11 11:55 PM, John MacAuley wrote:
So are you implying that the <nsaAddress> is element is not just an opaque reference, but an actual protocol address? Would this not conflict with the requirement not to put any transport implementation specific fields on the protocol?
I have defined the <nsaAddress> element as an anyURI because I anticipated you would be asking for this as soon as you saw my example. If you want to model the NSA address as a UDP port it can be done with the URI format <nsaAddress>udp://NSA.NORDU.net:2764</nsaAddress> or for TCP <nsaAddress>tcp://NSA.NORDU.net:2764</nsaAddress> all accomplished through the magic of the URI.
These are still protocol specific so you might want to revert back to my nice abstract name :-)
As for not using STP in the <localId> of the STP... I am not sure specifying a colon as an internal string separator is a good idea when URI/URL are now becoming a de facto standard for naming resources. Some of the organizations that will participate in the NSI testbed use this naming format already, and we should not force them to change. I also do not think we should be specifying a restricted character set for naming in the NSI with so many standardized naming schemes available in RFCs.
Jerry... Come over to the dark side..
Which raises another question. Should naming support multi-byte characters (UTF-8)?
John.
On 2011-03-25, at 11:15 PM, Jerry Sobieski wrote:
Oh...a couple other comments I forgot:
First, the <nsaAddresses> examples do not seem right... The message should reference a RA NSA and a PA NSA... Those should not need a domain reference...just the NSA identifier. First, NSI context has no notion of a "domain"... but more importantly, we need to specify where to find an NSA...it should ultimately resolve to an IP address (v4 or v6) and a TCP port that NSA is listening to. The NSA location can be specified in a symbolic name manner, but it needs to be specific to the transport layer it is using, and should not be handled differently in the protocol for different transport layers.
So an NSA locator string could be: "NSA.NORDU.net:2764" meaning the NSA is listening to port 2764 on the server nsa.nordu.net <http://nsa.nordu.net>. Or we could do "urn:ogf:network: netherlight.edu <http://netherlight.edu>" and assume it is using a default port that is documented somewhere.
We need to come to closure on NSA resolution. I.e. How do we specify an NSA location? Is it an IP address and TCP port? Is it a standard DNS name? a URN of some sort?
Also, the string you referenced as a local part of the netherlight.edu <http://netherlight.edu> STP is probably not valid if we use the colon seperated tuple for NSI endpoints. Endpoints will be referenced outside of XML contexts. And endpoint strings will be used in many other manners than simply the local NRM. Therefore, I think it is imperative that we make sure the name strings are as simple as possible. For instance is a network name case sensitive? Can it have colons ":" embedded in it? Or will that hose the tuple mechanism for naming? Are spaces allowed? are linefeeds? Are contiguous spaces significant? I was hoping we could let the local strings be whatever the local NSA wants them to be, but I think we need to be a bit more specific about how we expect to be able to use endpoint names.
We need to specify some constraints on the string values that make up NSI names. I suggest case-insensitive, no spaces, alphanumeric, and maybe a small set of special characters.
Jerry
On 3/23/11 10:37 PM, John MacAuley wrote:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
I would prefer URL/URI as well. Inder
------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@surfnet.nl> April 6, 2011 12:55 PM
So are you implying that the <nsaAddress> is element is not just an opaque reference, but an actual protocol address? Would this not conflict with the requirement not to put any transport implementation specific fields on the protocol?
I have defined the <nsaAddress> element as an anyURI because I anticipated you would be asking for this as soon as you saw my example. If you want to model the NSA address as a UDP port it can be done with the URI format <nsaAddress>udp://NSA.NORDU.net:2764</nsaAddress> or for TCP <nsaAddress>tcp://NSA.NORDU.net:2764</nsaAddress> all accomplished through the magic of the URI.
These are still protocol specific so you might want to revert back to my nice abstract name :-)
As for not using STP in the <localId> of the STP... I am not sure specifying a colon as an internal string separator is a good idea when URI/URL are now becoming a de facto standard for naming resources. Some of the organizations that will participate in the NSI testbed use this naming format already, and we should not force them to change. I also do not think we should be specifying a restricted character set for naming in the NSI with so many standardized naming schemes available in RFCs.
Jerry... Come over to the dark side..
Which raises another question. Should naming support multi-byte characters (UTF-8)?
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
Jerry Sobieski <mailto:jerry@nordu.net> March 26, 2011 12:15 PM
Oh...a couple other comments I forgot:
First, the <nsaAddresses> examples do not seem right... The message should reference a RA NSA and a PA NSA... Those should not need a domain reference...just the NSA identifier. First, NSI context has no notion of a "domain"... but more importantly, we need to specify where to find an NSA...it should ultimately resolve to an IP address (v4 or v6) and a TCP port that NSA is listening to. The NSA location can be specified in a symbolic name manner, but it needs to be specific to the transport layer it is using, and should not be handled differently in the protocol for different transport layers.
So an NSA locator string could be: "NSA.NORDU.net:2764" meaning the NSA is listening to port 2764 on the server nsa.nordu.net. Or we could do "urn:ogf:network: netherlight.edu" and assume it is using a default port that is documented somewhere.
We need to come to closure on NSA resolution. I.e. How do we specify an NSA location? Is it an IP address and TCP port? Is it a standard DNS name? a URN of some sort?
Also, the string you referenced as a local part of the netherlight.edu STP is probably not valid if we use the colon seperated tuple for NSI endpoints. Endpoints will be referenced outside of XML contexts. And endpoint strings will be used in many other manners than simply the local NRM. Therefore, I think it is imperative that we make sure the name strings are as simple as possible. For instance is a network name case sensitive? Can it have colons ":" embedded in it? Or will that hose the tuple mechanism for naming? Are spaces allowed? are linefeeds? Are contiguous spaces significant? I was hoping we could let the local strings be whatever the local NSA wants them to be, but I think we need to be a bit more specific about how we expect to be able to use endpoint names.
We need to specify some constraints on the string values that make up NSI names. I suggest case-insensitive, no spaces, alphanumeric, and maybe a small set of special characters.
Jerry
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg ------------------------------------------------------------------------
John MacAuley <mailto:john.macauley@surfnet.nl> March 24, 2011 11:37 AM
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- -- Inder Monga imonga@es.net
participants (4)
-
Atsuko Takefusa -
Inder Monga -
Jerry Sobieski -
John MacAuley