[Nsi-wg] Network and STP Identifiers
John MacAuley
macauley at es.net
Wed Oct 8 09:44:17 EDT 2014
I just noticed the examples I added during the A-GOLE call are wrong. We will discuss in 15 minutes.
On 2014-10-08, at 9:15 AM, John MacAuley <macauley at es.net> wrote:
> Peoples,
>
> I was writing this up last night and would like share it with the group to explains some of the issues I am running into.
>
> John
>
> Network and STP identifier Syntactic Structure
> A network resource URN (NURN) identified by the "urn:ogf:network:" prefix is defined in [URN-OGF-NETWORK]. NSI utilizes NURN formatted URNs in the P2P service definition, and within NML topology describing NSI network constructs. The NSI Connection Service Protocol specification [OGF-NSI-CS] puts a specific requirement on the Service Termination Point Identifier (stpId), defining the stpId as a three-part identifier composed of a network identifier part, a local identifier part, and a qualifying label part:
>
> <STP identifier> ::= <networkId> “:” <localId> <label>
> <label> ::= “?” <labelType> “=” <labelValue> | “?”<labelType> | “”
> <labelType> ::= <string>
> <labelValue> ::= <string>
>
> To maintain syntactic correctness with the NURN specification such that an stpId is also a valid NURN formatted URN, we define a specific Augmented B
> NF [RFC 5234] to restrict the format of the NSI Network and STP identifiers such that they remain NURN compliant, but provide the needed imbedded structure.
>
> NSAID = ROOTID
> NETWORKID = ROOTID
>
> ROOTID = "urn:ogf:network:" ORGID ":" LOCALPART
> ORGID = FQDN ":" DATE ; ID of assigning organisation
> FQDN = 1*(ALPHA / DIGIT / "-" / ".") ; Domain name
> DATE = YEAR *1(MONTH *1DAY) ; Date of creation of ORGID
> YEAR = 4DIGIT
> MONTH = 2DIGIT
> DAY = 2DIGIT
> LOCALPART = *(ALPHA / DIGIT / SYMBOL)
> ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
> DIGIT = %x30-39 ; 0-9
> SYMBOL = "+" / "," / "-" / "." / ";" / "=" / "_"
>
> STPID = NETWORKMEMBER
> SERVICEDOMAINID = NETWORKMEMBER
> SERVICEADAPTATIONID = NETWORKMEMBER
> SERVICEDEFINITIONID = NETWORKMEMBER
>
> NETWORKMEMBER = NETWORKID ":" MEMBERLOCALPART *1QUERY *1FRAGMENT ;
> MEMBERLOCALPART = *(ALPHA / DIGIT / OTHER)
> OTHER = ALLOWED / EXTENSION
> ALLOWED = "+" / "," / "-" / "." / ":" / ";" / "=" / "_"
> EXTENSION = "!" / "$" / "(" / ")" / "*" / "@" / "~" / "&"
> QUERY = "?" *QFCHAR
> FRAGMENT = "#" *QFCHAR
> QFCHAR = ALPHA / DIGIT / OTHER
>
> The full length of an ID must not exceed 255 characters.
>
> ALLOWED and SYMBOL characters may be used for the assignment of network resource URNs. EXTENSION characters should not be used to assign network resource URNs. To allow for future extensions, parsers should accept network resource URNs with EXTENSION characters.
>
> The QUERY part is used by NSI to specify technology specific labels as part of the abstract stpId.
>
> The FRAGMENT parts must not be present in any assigned URN and is reserved for future standardization.
>
> A STPID must not contain percentage-encoded characters ("%" HEXDIG HEXDIG). It should also be noted that the following characters (which are either allowed by the URI or URN specification) must not be used in the NETWORKLOCALPART or STPLOCALPART of a network resource URN: "%", "/", "?", "#", and "'".
>
> DOMAIN is a fully qualified domain name (FQDN) of the URN assigning organisation in LDR format [RFC 5890]. Valid examples are example.net and example.xn--jxalpdlp. DATE is a date (either year, year+month or year+month+day). The combination of DOMAIN and DATE forms the organisation identifier, ORGID.
>
> Examples
> The following STP identifiers are considered legal based on the NURN syntax and a networkId of "urn:ogf:network:es.net:2013":
>
> <ns2:BidirectionalPort id="urn:ogf:network:es.net:2013:manlan:aofa:1">
> <ns2:PortGroup id="urn:ogf:network:es.net:2013:manlan:aofa:1:in"/>
> <ns2:PortGroup id="urn:ogf:network:es.net:2013:manlan:aofa:1:out"/>
> </ns2:BidirectionalPort>
>
> The following STP identifiers are considered legal based on the NURN syntax and a networkId of "urn:ogf:network:grnet.gr:2013:topology":
>
> <ns3:BidirectionalPort id="urn:ogf:network:grnet.gr:2013:topology:CLIENT_port">
> <ns3:name>CLIENT_port</ns3:name>
> <ns3:PortGroup id="urn:ogf:network:grnet.gr:2013:topology:CLIENT_port-in"/>
> <ns3:PortGroup id="urn:ogf:network:grnet.gr:2013:topology:CLIENT_port-out"/>
> </ns3:BidirectionalPort>
>
> The following Caltech identifiers are considered illegal based on an networkId of "urn:ogf:network:caltech.edu:2013:":
>
> <ns3:BidirectionalPort id="urn:ogf:network:caltech.edu:2013:stp1">
> <ns3:PortGroup id="urn:ogf:network:caltech.edu:2013:stp1:in"/>
> <ns3:PortGroup id="urn:ogf:network:caltech.edu:2013:stp1:out"/>
> </ns3:BidirectionalPort>
>
> The corrected set of identifiers would be:
>
> <ns3:BidirectionalPort id="urn:ogf:network:caltech.edu::2013:stp1">
> <ns3:PortGroup id="urn:ogf:network:caltech.edu:2013::stp1:in"/>
> <ns3:PortGroup id="urn:ogf:network:caltech.edu:2013::stp1:out"/>
> </ns3:BidirectionalPort>
>
> The following ESnet STP identifiers are illegal based on the NURN syntax, but considered valid URN based on RFC 2141.
>
> <ns2:BidirectionalPort id="urn:ogf:network:es.net:2013:lbl-mr2:xe-8/2/0:*">
> <ns2:PortGroup id="urn:ogf:network:es.net:2013:lbl-mr2:xe-8/2/0:*:in"/>
> <ns2:PortGroup id="urn:ogf:network:es.net:2013:lbl-mr2:xe-8/2/0:*:out"/>
> </ns2:BidirectionalPort>
>
>
> RFC 2141 Rules
>
> 2. Syntax
>
> All URNs have the following syntax (phrases enclosed in quotes are
> REQUIRED):
>
> <URN> ::= "urn:" <NID> ":" <NSS>
>
> where <NID> is the Namespace Identifier, and <NSS> is the Namespace
> Specific String. The leading "urn:" sequence is case-insensitive.
> The Namespace ID determines the _syntactic_ interpretation of the
> Namespace Specific String (as discussed in [1]).
>
> RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
> for URN encoding, which have implications as far as limiting syntax.
> On the other hand, the requirement to support existing legacy naming
> systems has the effect of broadening syntax. Thus, we discuss the
> acceptable syntax for both the Namespace Identifier and the Namespace
> Specific String separately.
>
> 2.1 Namespace Identifier Syntax
>
> The following is the syntax for the Namespace Identifier. To (a) be
> consistent with all potential resolution schemes and (b) not put any
> undue constraints on any potential resolution scheme, the syntax for
> the Namespace Identifier is:
>
> <NID> ::= <let-num> [ 1,31<let-num-hyp> ]
>
> <let-num-hyp> ::= <upper> | <lower> | <number> | "-"
>
> <let-num> ::= <upper> | <lower> | <number>
>
> <upper> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
> "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
> "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
> "Y" | "Z"
>
> <lower> ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
> "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
> "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
> "y" | "z"
>
> <number> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
> "8" | "9"
>
>
> This is slightly more restrictive that what is stated in [4] (which
> allows the characters "." and "+"). Further, the Namespace
> Identifier is case insensitive, so that "ISBN" and "isbn" refer to
> the same namespace.
>
> To avoid confusion with the "urn:" identifier, the NID "urn" is
> reserved and MUST NOT be used.
>
> 2.2 Namespace Specific String Syntax
>
> As required by RFC 1737, there is a single canonical representation
> of the NSS portion of an URN. The format of this single canonical
> form follows:
>
> <NSS> ::= 1*<URN chars>
>
> <URN chars> ::= <trans> | "%" <hex> <hex>
>
> <trans> ::= <upper> | <lower> | <number> | <other> | <reserved>
>
> <hex> ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
> "a" | "b" | "c" | "d" | "e" | "f"
>
> <other> ::= "(" | ")" | "+" | "," | "-" | "." |
> ":" | "=" | "@" | ";" | "$" |
> "_" | "!" | "*" | "'"
>
> Depending on the rules governing a namespace, valid identifiers in a
> namespace might contain characters that are not members of the URN
> character set above (<URN chars>). Such strings MUST be translated
> into canonical NSS format before using them as protocol elements or
> otherwise passing them on to other applications. Translation is done
> by encoding each character outside the URN character set as a
> sequence of one to six octets using UTF-8 encoding [5], and the
> encoding of each of those octets as "%" followed by two characters
> from the <hex> character set above. The two characters give the
> hexadecimal representation of that octet.
>
> 2.3 Reserved characters
>
> The remaining character set left to be discussed above is the
> reserved character set, which contains various characters reserved
> from normal use. The reserved character set follows, with a
> discussion on the specifics of why each character is reserved.
>
> The reserved character set is:
>
> <reserved> ::= '%" | "/" | "?" | "#"
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20141008/804aed76/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1626 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20141008/804aed76/attachment-0001.bin>
More information about the nsi-wg
mailing list