|
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
