Dear All,
This is an excellent discussion! Thank you for sharing; I want to make
sure the control plane working group is also aware of (I am cc'ing
them) this wealth of knowledge and experiences. I agree with the
conclusions each of you have raised:
- It must be scalable
- It must be secure
- It would be nice to be both human readable (as Freek suggested)
as well as machine readable
- Useful for both control plane as well as management plane
implementations
- apply KISS (keep it simple and SMART)
- do not re-invent the wheel if already out there..
I would also like to suggest that we have a working session on this
topic during our upcoming winter meeting for the joint working group
time slots.
Kind regards,
Gigi
Leon Gommans wrote:
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@xxxxxxxxxxxxxxxx.
>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
--
--------------------------------------
Gigi Karmous-Edwards
Principal Scientist
MCNC
Research Triangle Park, NC
gigi@xxxxxxxx
+1 (919) 248-4121
---------------------------------------
|
