Global Lambda Integrated Facility

Subject Re: globally unique identifiers for lightpaths?
From Leon Gommans <lgommans@xxxxxxxxxxxxxx>
Date Mon, 10 Dec 2007 08:50:37 +0100

Hi Jerry,

Thanks for your comments and observations

Jerry Sobieski schreef:
THis is an interesting discussion.   A couple observations:

We do need this to be simple yet scalable - and secure.
Indeed.

A globally unique session ID  should not be generated centrally.
Agree. In addition, a globally unique Session ID should be independent of the signalling model used: Inter-domain signalling can be performed in chain or tree fashion. Also, imho, the domain or agent, which receives the request from the end-user/application, is the most logical entity responsible for creating a Session ID (either for ad-hoc use or advance reservations). The session-ID or GRI therefore should always have some point of origin. We need to agree on the principle that a GRI:
-  has some logical point of origin / generation
-  has conventions for designating the point of origin
and subsequently consider its implications, e.g. what the responsibilities for the point of origin would be (how long it should keep state for the GRI, what happens if the GRI refers to a path that can not be committed, etc..)
   I suggests a standard Global Resouce Identifier format something like:
      <Global_resource_ID>  ::=  <admin_domain_id>-<admin_resource_id>
This would allow any domain to create a globally unique identifier simply by prefixing their administrative domain identifier to a locally unique number. The domain id could be an ASN, or some other Enterprise ID (ala SNMP MIBs), or something else. The key is that an administrative domain only needs to obtain a globally unique domain ID once from a central issuing authority.
Indeed, conventions need to be established. Would this be something that we could arrange in the GLIF or do people feel we should go for example to the IETF for this? I believe the GRI should allow names and conventions that needs a broad discussion. The presented idea's have good rationales, but people may have concerns about one way or the other. We need some (rough) consensus and possibly running code to make choices, keeping the KISS principle in mind.

We could also look at re-using concepts from the SIP protocol. SIP knows the concept of a Call-ID:
e.g. a84b4c76e66710@xxxxxxxxxxxxxxxxx

From RFC3261 we can read:

Call-ID contains a globally unique identifier for this call,
generated by the combination of a random string and the softphone's
host name or IP address.

SIP, however, talks about peer-to-peer relationships between end-users. I don't know if we want to go here as we are talking about
connections from a network-ingress point to a network-egress point.

RFC3261 continues with the concept of a dialog, identified by additional tags:

The combination of the To tag, From tag,
and Call-ID completely defines a peer-to-peer SIP relationship
between Alice and Bob and is referred to as a dialog.

The above it just to spur some additional thoughts. We must be clear that we do not want to go into dialogs between peers.
We could stipulate formats for the GRI in general. For example, the <admin_domain_id> could be seven characters, alphanumeric, Left justified, underscore filled, case insensitive. Followed by a single dash. Followed by <admin_resource_id> of 16 characters, alphanumeric, case insitive, underscore filled.
...or something like this...

As for security: I don't think any information about the light path itself should be present in the GRI. An agent (outside of the control plane itself) wishing to learn more information should be authorized by the issuing domain. (I don't think just anybody should be able to query the details of a light path - there should be some authroization architecture associated with giving out such information)
Indeed. GRIs should be abstract and only have a meaning for domains that can associate a service to it. Each domain can map a GRI to a Local Resource Indentifier (LRI).
If an arbitrary agent has a GRI, there is enough information present in the name to locate the authoritative domain that established (or "owns") the light path. The curious agent should ask the "owner" to provide details about the light path. (such as a loose hop ERO, or Next Hop Admin_Doamin_ID) Network agents that are authorized components of the the domains along the path will already have access to information about the lightpath as allocated within their local domain, but (IMO) they need to be authorized and authenticated to query any information about the light path beyond their domain (information such as path details thru other domains). Access Authorization by the administrative domain responsible for the component resources is important.


I think there also needs to be a means for authenticating. I can imagine the situation where GRIs are spoofed, or otherwise duplicated. The confusion caused could be substantial, and could be a malicious act.
The above mentioned reasons are reason for our experiments during SC07 & 06 & 05 where we essentially stamped a GRI into a "token" using a secure hashing algoritm that uses a key. This mechanism will allow domains to recognize the authenticity of the GRI, in particular in cases when you do advance reservation and a lightpath is something you intend to make public accessible. This requires mechanisms which can enforce the validity of a tokenized GRI, at the time you want to use the lightpath. We have shown that these tokenized GRIs can be placed inside GMPLS RSVP-TE messages, WS based signalling messages and even inside the options-field of an IP packet where hardware did the enforcement. This will also allow separation between authorized application streams and non-authorized streams when a lightpath is a public accessible facility. In the Phosphorus project we are almost ready to test a token based router which can sit in between a campus network, a GOLE and a regular transit network. This is a solution to a case presented in chapter 3.3.4 of OGF document GFD.083

Further, there is no guarrantee that a single GRI represents the end-to-end path. It is easy to concatenate two (or more) separate LSPs together, which completely torpedos the ability to discern information about and end-to-end notion. Note that this can be the case even if the entire [real] end to end light path is provisioned using automated/dynamic agents
Maybe a GRI could refer to "whatever is requested and is possible" and the GRI could be abstract enough to also refer to concatenated connections, which each domain is free to implement in its specific way, like you descibe below.


Fundamentally, I think the aspect of end-to-end perfomance analysis of light paths is going to be extremely difficult as the capability becomes more widely adopted. There will be many (most) domains that will be very reluctant to provide outside agents with access to internal detailed information on a LSP by LSP basis. "peered" models of ENNI provisioning may never be common. I believe we need to develop an architecture that allows each domain to independently characterize and/or verify the performance across their specific components regardless of upstream or down stream network engineering or performance, and then commnicate just those results along to authorized agents. I think for scalability reasons (and policy reasons) we should pursue a performance verification (or fault isolation) architecture that does not rely on full end-to-end visibility. A "a trusted, delegated, blackbox performance verification process" is whats needed (IMHO:-)

Jerry
Regards .. Leon Gommans.


Freek Dijkstra wrote:
Ronald van der Pol wrote:

Two possibilities, I think:
- central repository
- random number

For scalability reasons, I prefer the latter.

As to ensure global uniqueness, Ronald proposed timestamps. Another
method is to use a hierarchy and use DNS, AS numbers, or -as Ronald
suggested- location of the nearest city. This reduces the global
uniqueness constraint to a more local uniqueness constraint, which is
often manageable. As an example, put the timestamp and your GPS
coordinates together, and as long as your not standing to a big random
generator, you are pretty sure it is a unique number.

- RDF uses URIs as unique identifiers, and relies on DNS + whatever the
domain name owner comes up with.
- Universally Unique IDentifiers (UUID) rely on timestamp and node ID
(See RFC 4122, ITU-T X.667 or ISO/IEC 9834-8)

Note that cities in UN Location codes
(http://www.unece.org/cefact/locode/) are country dependent. For
example, there is also an "AMS" in the United States. So this example:

20071205200042-AMS-CHI
20071206070809-NYC-TYO

Ought to be:
20071205200042-NLAMS-USCHI
20071206070809-USNYC-JPTYO

As Kevin Pointed out, these are not unique. What if we get two GOLEs in
the same city? That is not unthinkable. (The problem of 1 GOLE in more
cities is solvable. Pacific Wave can either use US-SEA, US-SNN or
US-LAX, depending on the terminating device).

I would not create a repository for GOLE codes. This has two problems:
1) Yet Another Global Name Repository. Why not use an existing one. If
UN location codes or AS numbers (not all GOLEs have IP addresses) are
not sufficient, simply use another, like their domain name.
2) We should not restrict the end points to GOLEs. While that is the
current practice, our goal is lightpaths towards end-users (at least
it's mine!). So the end points in user domains should be possible.


The discussion seems to be whether the ID should be contain information
or not. I personally don't like UUIDs, and I now think why. I never can
remember them!

The -AMS-CHI appendix are really nice. It helps me, as a human,
understand it. Why not use the domain name of the requester, rather than
the GOLE id? So:
20071205200042-amc.nl
20071206070809-uhvem.osaka-u.ac.jp


Regards,
Freek


PS: When checking the ITU-T reference for UUID, I just found that since
last month you can download ITU-T recommendations for free! That is
excellent news; with RFCs and W3C recommendations always free and the
Get IEEE program, only ISO standards have restricted access.
http://www.itu.int/ITU-T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx