With the signal compatibility draft and signaling extensions we
introduce more configuration information via attributes in the ERO.
If we add the tunable transponder id (very similar to a wavelength
converter id) to the label will this be sufficient for restart or would
we need to add some of our other attributes such as (FEC and modulation
format) to permit restart.
Greg
Lou Berger wrote:
Anders,
What I'm saying is that up until now GMPLS has supported labels that
allow a node (based on it's local value allocation policy, or fixed TDM
slots) to uniquely map from a label back to internal transport
resources. The current draft breaks this. IMO there are two options:
(a) accept this (model) change, or
(b) fix the draft.
I'm in favor of (b) particularly as there are some straight forward
solutions to this.
Lou
On 11/4/2009 1:19 PM, Anders Gavler wrote:
Hi Lou,
Are you saying that there is no way to store and/or access this type of information in a good enough way and this is the reason why you need it at a restart event (re-signalling), or are you saying that you would need it anyway?
Cheers,
Anders
-----Original Message-----
From: Lou Berger [mailto:lberger at labn.net]
Sent: den 3 november 2009 20:36
To: Anders Gavler
Cc: Greg Bernstein; ccamp at ietf.org
Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
resource identification
Anders,
See below.
On 11/3/2009 1:55 PM, Anders Gavler wrote:
Lou,
I still do not get it.
As long as a node uniquely can identify an LSP that starts, ends, or
transits this node it should also be able to uniquely map which local
resources the LSP corresponds to (e.g. tunable or non-tunable transponder,
wavelength, ports etc).
How does one specify use of a particular laser from an upstream node?
Today that is done using label in ERO.
If this is true I do not see why the label needs to directly map to a
certain laser since they both can map to a uniquely identifiable LSP and
this information could be stored and used at restart.
So what happens when the node losses all/some state?
Lou
/Anders
-----Original Message-----
From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On Behalf
Of
Lou Berger
Sent: den 3 november 2009 18:58
To: Greg Bernstein
Cc: ccamp at ietf.org
Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
unique
resource identification
Greg,
In the cases I'm referring to we're talking per node resource
information which typically has node (pair) local scope with the
exception of ERO and RROs. So no, I don't think an end-to-end LSP
attribute is a match.
Lou
On 11/3/2009 12:50 PM, Greg Bernstein wrote:
Lou, do you think this information is better in a label or in some
kind
of LSP attribute? In the WSON compatibility draft we tentatively put
similar information into a new ERO subobject for attributes. Those
attributes included things like modulation format, FEC, and whether
regeneration should occur at a node along the path. We didn't put them
with the traffic descriptor since they can change along a path. I
didn't
think we should put them into labels... But I'm flexible.
Regards
Greg
Lou Berger wrote:
Jonas,
A very good question! In the common/general setup case I think
it
won't matter. But there are cases where it may:
- In GMPLS we have a precedent of being able to use the label to
represent a specific physical resource, be it a time slot, frequency
or
even port. If we assume that this is a function worth preserving
(and
I
believe it is, at least with today's equipment) than it is
desirable/required to be able to use GMPLS to control a specific
laser.
Even a tunable one. With the current definition, this isn't
possible.
- The more practical/import case is graceful restart. In certain
restart cases, the restarting node may need to match particular node
resources (e.g., tunable lasers) against a particular frequency to
ensure no data loss and the restarting node may no longer have the
information to do the matching. In all other cases that I know about,
GMPLS allows for sufficient information for a node to reconstruct
this
mapping.
- MP to CP handover may also need to identify specific node resources
(e.g., tunable lasers).
I believe these are the primary cases.
I hope this helps,
Lou
On 11/2/2009 5:35 AM, Jonas Mårtensson wrote:
Lou,
Maybe this is a silly question but if all lasers in the system are
tunable, why does it matter which one is used? Can't the node decide
this
locally?
Regards,
Jonas
-----Original Message-----
From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org]
On Behalf Of Lou Berger
Sent: den 30 oktober 2009 14:02
To: Richard Rabbat
Cc: ccamp at ietf.org
Subject: Re: [CCAMP]
draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
resource identification
Richard,
Okay let me try again with a specific case. If I have an rro
or ero that identifies the label (lambda) per your document,
how does a node know which laser the label corresponds to
when all lasers in the system are tunable?
Thanks,
Lou
On 10/29/2009 2:22 PM, Richard Rabbat wrote:
sorry for the lag.
do you want to describe your use-case further in terms of what you
can't do and your proposed change?
thanks,
Richard.
On Thu, Oct 15, 2009 at 8:53 AM, Lou Berger <lberger at labn.net
<mailto:lberger at labn.net>> wrote:
Authors,
Have you given any additional thought on the
repesentation of
tunable
lasers (and unique resource identification) beyond what
is currently in
the draft? The current text is:
If the node has a tunable wavelength transponder, the tuning
wavelength is considered as a part of wavelength switching
operation.
In the past, labels used for TE LSPs always represented
a specific
resource that is uniquely identifiable by the node that
allocates the
label and resource. Such unique identification is
important/required
for certan restart and other corner cases. Your current
definition works
fine for fixed lasers that can only be mapped to a
single fiber. But,
the defined global label will not uniquely identify a
resource on a node
when (a) tunable lasers are used, or (b) when a node
supports multiple
fixed lasers that can be (optically) switched to a
particular output
interface.
What are your thoughts on how to provide such link-scoped
unique
resource identification in the context of your draft?
I don't think it'll be too difficult to address this
critical point, and
see a couple of straightforward solutions if you'd like
to discuss
off-line.
Much thanks,
Lou
_______________________________________________
CCAMP mailing list
CCAMP at ietf.org <mailto:CCAMP at ietf.org>
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP at ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP at ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
_______________________________________________
CCAMP mailing list
CCAMP at ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
|