Re: globally unique identifiers for lightpaths?

[Ronald van der Pol <Ronald.vanderPol@xxxxxxxx>]

On Fri, Dec 07, 2007 at 09:40:09 +0100, Leon Gommans wrote:

> Ronald,
> 
> Within our work with Internet2 we discussed the same issue. Essentially
> your need to refer to a "network session id"
> that needs to be created in a globally unique way. Each domain may have
> to take the initiative to create such
> an identifier. In our discussion with Internet2 we started to called it
> a Global Resource Identifier (GRI).
> This identifier essentially allows local domains to assign its resources
> to this GRI. The information related to local resources can was called a
> Local Resource Identifier (LRI). Each domain can use its own conventions
> here. The GRI was essentially build using a domain identifier and some
> number which each domain is free to choose as long as it is unique and
> adheres to some format constraints posed by the inter-domain signalling
> protocol. The random number you mentioned could be one way. One may
> start to think about domain-id's that some authority will issue and this
> might need discussion in the GLIF.

All,

Not many oppinions yet. So let me make a proposal. Let's keep it simple
and just use a 14 digit number. A human being can use this convention:

YYYYMMDDhhmmss, where
YYYY: year
MM: month
DD: day
hh: hour (in UTC)
mm: minutes
ss: seconds

e.g. 20071221121256

A computer can either generate this string or generate a 14 digit random
number. In both cases the likelihood of collisions is low and when it
happens it can easily be resolved by picking a new number. No central
registration authority is needed. The sourcing GOLE (in the case of
manually provisioned lightpaths) or the dynamic provisioning/reservation
system picks the number.

This ID is just used as a unique identifier to which all parties can
refer to. Nothing more, nothing less.

Many domains will probably map this global ID to the locally used ID.

This ID does not give any information about topology, users, etc. That
information should be stored somewhere else (some may use a database
to store this information, some may encode this information in the
locally used ID, etc).

A GLIF end-to-end monitoring system should provide information about
all the domains crossed by a lightpath.

What do you all think?

PS. We can choose to use this number in the PATH TRACE overhead
(16 bytes for SDH).

	rvdp