Hi folks, at the Vancouver meeting the lambda label format of
Otani,
et. al.
draft-otani-ccamp-gmpls-lambda-labels-01.txt [Otani] was presented
for a second time and a few new issues seemed to arise. I'm writing
this note to see if we can resolve these on the list so this work can
move forward, since the label format is valuable, in general, to the
control of wavelength switched optical networks (WSON).
First, a general 32 bit lambda label has been
defined in RFC3471. This previous label does
not directly relate
to either the wavelength or frequency of the light used in a lambda LSP
in a standardized way (folks can use the 32 bits as they see fit).
To come up with a completely general "lambda label" one could/should
define both a (i)
wavelength label specified in meters and (ii) a frequency label
specified in
Hertz (Hz). These could be specified
either with a 32 bit IEEE floating point number or via a suitable 32
bit
integer by suitably adjusting the base units.
We could represent the frequency via a 32 bit integer in MHz,
then a
193.1THz light source could be characterized by the integer
193,100,000.
Similarly we could represent the wavelength label via a 32 bit integer
in pico
meters (10-12 meters), then a 1550nm wavelength could be characterized
by the
integer 1,550,000.
Now any of the previous formats
could
be used with the 32
bit lambda label already defined. The
problem here is to pick a format for interoperability and compatibility
with
potentially common wavelength switched control operations.
Issues with the previously mentioned formats:
(a)
While
floating point numbers provide great flexibility, as a label they have
issues
when it comes to comparison operations.
(b)
An
integer format with a suitably scaled exponent is relatively simple and
just
leaves the choice of “exponent” to be decided.
(c)
Neither
format contains any “context” information about the WDM system in
general.
The format proposed in [Otani]. avoids the above
three
issues and enhances common control plane operations as follows:
(a)
The
format is integer based, hence avoids issues with floating point
comparisons.
(b)
The
format is based on the widely recognized ITU-T standard grids (ITU-T
G.694.1 and .2) and
fosters interoperability more than potentially any other choice.
(c)
The
ITU-T grids come in various widths and hence have an inherent growth
path.
(d)
The
ITU-T grids come in both frequency (G.694.1) and wavelength (G.694.2)
flavored
versions an both are incorporated in the [Otani] label format.
(e)
The
format includes information on the grid spacing which is important WDM
context
information useful in many label selection processes. For
example a tunable laser associated with a
50GHz spacing WDM system could specify acceptable label range via the
inclusive
range label set mechanism. Note that
only those frequencies (labels) that fall on the grid are supported and
not
intermediate frequencies.
At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger)
that
since a lambda label already exists and that existing implementations
may make
use of it that the proposed label of [Otani] would be better off
referred to as a
“G.694 label”. With such a change I think that this label format (and
accompanying draft) should move forward as a working group document.
Comments, suggestions, issues?
Regards
Greg B.
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237