[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification

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