Subject: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 27 Oct 2005 10:15:13 +0200

hi,

there is a specific point to be clarified in this document:

semanticless vs semanticful label (even here there is a distinction 
between spectral vs indexes i.e. using the wavelength index)

domain-wide vs link local significant label

so, the comparison from this perspective with TDM labels is difficult to
parse, the latter is semanticful but link local

now, i don't specifically see what has changed the late 90's, early 
y2k's, to have a change in the wavelength label definition; there are 
several solution possible

- absolute values: the freq. of the wavelength: difficult to adopt 
because referenced values are nominal and knowing all interactions 
between wavelengths this knowledge is at the end of little practical 
usage; (introduces implicit ordering)

- indexed values: the # of the wavelength: it does not provide for a 
future proof label space for inst. in case new frequencies are inserted 
in the grid (introduces explicit ordering)

- diff. values e.g. freq spacing starting from a reference value: pauses 
the question of the reference value and does suffer from the former 
issue (introduces implicit ordering)

- the solution available today - cumbersome in some control plane 
operations (e.g. label set translation) and not easy to troubleshoot but 
independent of any physical consideration (spectral), scale to any 
number of wavelength per fiber, does not introduce any ordering, the 
most flexible (since allowing each system to maintain its specific 
control operations) and the less constraining since maintaining the 
control plane operations independent of any data plane specifics

<http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-00.txt>

CCAMP Working Group                              Sidney Shiba (Fujitsu) 
Internet Draft                                 Richard Rabbat (Fujitsu) 
Updates: 3471                                                           
Proposed Category: Standards Track                                      
Expires: March 2006                                      September 2005 
    
      Generalized Labels of Lambda-Switching Capable Label Switching 
                              Routers (LSR)s 
    
             draft-shiba-ccamp-gmpls-lambda-labels-00.doc.txt 
     
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."  
    
   The list of current Internet-Drafts can be accessed at  
   http://www.ietf.org/ietf/1id-abstracts.txt  
    
   The list of Internet-Draft Shadow Directories can be accessed at  
   http://www.ietf.org/shadow.html. 

Requirements Language 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119, reference 
   [RFC2119]. 
    
Abstract  
    
   Technology in the optical domain is constantly evolving and as a 
   consequence new equipment providing lambda switching capability has 
   been developed and is currently being deployed. [RFC3471] has defined 
   that a wavelength label (section 3.2.1.1) "only has significance 
   between two neighbors". However, in a network composed of a new 
 
                          Expires March 2006                    [Page 1] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

   generation of lambda switch-capable equipment, this document explains 
   why the label should have global meaning similarly to the label 
   defined for SONET/SDH technology (SUKLM format defined in [RFC3946]) 
   and describes extensions to enable global meaning. 
    
   This document is a companion to the Generalized Multi-Protocol Label 
   Switching (GMPLS) signaling. It defines the Label Switching Capable 
   (LSC) technology specific information needed when using GMPLS. 

Table of Contents 
    
   1. Introduction.....................................................2 
   1.1. Problem Description............................................2 
   2. Label Related Formats............................................4 
   2.1. Wavelength Labels..............................................4 
   2.2. Label Set Wavelength Subchannel................................4 
   2.3. RSVP-TE Extensions.............................................5 
   3. IANA Considerations..............................................5 
   4. Security Considerations..........................................5 
   5. Acknowledgements.................................................6 
   6. References.......................................................7 
   6.1. Normative References...........................................7 
   6.2. Informative Reference..........................................8 
   7. Copyright Statement.............................................10 
   8. Intellectual Property Statement.................................11 

1.   Introduction 
    
   As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from 
   supporting only packet (Packet Switching Capable - PSC) interfaces 
   and switching to also include support of four new classes of 
   interfaces and switching: Layer-2 Switch Capable (L2SC), Time-
   Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-
   Switch Capable (FSC). A functional description of the extensions to 
   MPLS signaling needed to support new classes of interfaces and 
   switching is provided in [RFC3471].  
    
1.1.     Problem Description 
    
   This document presents details that are specific to the use of GMPLS 
   with a new generation of Lambda Switch Capable (LSC) equipment as 
   opposed to a the prior generation of LSC equipment composed of of 
   Wavelength Division Multiplexing (WDM) + Photonic Cross Connect (PXC) 
   combined system (shown below) that was originally considered at the 
   time of writing of RFC 3471.  

                         Expires October 2005              [Page 2] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

   Technologies such as Reconfigurable Optical Add/Drop Multiplex 
   (ROADM) and Dynamic-OADM operate at the wavelength switching level. 
   As such, the wavelength is important information that is necessary to 
   successfully setup a wavelength LSP. 
    
          _______                _______               _______ 
       /|_|6     1|_|\       /|_|5     1|_|\        /|_|5     1|_|\ 
      | |_|7 PXC 2|_| | WDM | |_|6 PXC 2|_| | WDM  | |_|6 PXC 2|_| | WDM 
   ===| |_|8 (1) 3|_| |=====| |_|7 (2) 3|_| |======| |_|7 (3) 3|_| |==== 
      | |_|9     4|_| |     | |_|8     4|_| |      | |_|8     4|_| |  
       \| |_______| |/       \| |_______| |/        \| |_______| |/ 

   For technologies such as the ROADM and DOADM, the WDM port mapping 
   does not provide sufficient information for selecting the required 
   wavelength for an LSP. Here are four cases that highlight where it is 
   important to have wavelength information available globally. 
    
   1. Label Set:  A Label Set object may be used to limit the label 
      choices of a downstream node (section 3.5 of RFC 3471).  This 
      Label Set object needs to carry one of the labels defined in 
      section 3.2 of that same document, i.e. either port, wavelength 
      label or waveband label.  In order to be able to generate that 
      wavelength information, it is important to have global 
      dissemination of wavelength information.  
   2. Explicit Route Object/Record Route Object: Here as well, any 
      meaningful information should be global, which implies the use of 
      wavelength since a locally-significant label will have no meaning. 
   3. In SONET/SDH, one can think of the label with the set values of 
      SUKLM bits as locally significant and set their values as a 
      matter of policy to have global meaning. This would add undue 
      burden on the operator to enforce policy. In addition, manual 
      provisioning may lead to misconfiguration.  
   4. Finally, the values for the wavelengths need to be out of the 
      same pool of values to have global meaning.  Any representation 
      of the lambdas needs to be the same on all nodes irrespective of 
      the manufacturer. 
             
                _______           _______           _______ 
                |       |         |       |         |       | 
           WDM  |  LSC  |   WDM   |  LSC  |   WDM   |  LSC  |   WDM 
         =======|1     2|=========|1     2|=========|1     2|======= 
                |       |         |       |         |       | 
                |_______|         |_______|         |_______| 

                         Expires October 2005              [Page 3] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

   The ITU-T frequency grid specified in [G.694.1] for Dense WDM (DWDM) 
   and [G.694.2] for Coarse WDM (CWDM) are the labels that SHOULD be 
   used by these LSC LSRs. 

2.   Label Related Formats 
    
   To deal with the widening scope of MPLS into the optical and time 
   domains, several new forms of "label" have been defined in [RFC3471]. 
   This section contains clarifications for the Wavelength label and 
   Label Set definition specific for LSC LSRs. 
    
2.1.     Wavelength Labels 
    
   In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to 
   have significance between two neighbors, and the receiver may need to 
   convert the received value into a value that has local significance. 
    
   Equipment providing "true" lambda switching (LSC) uses multiple 
   wavelengths controlled by a single control channel. In such case, the 
   label indicates the wavelength to be used for the LSP. In order to 
   allow global meaning, this document redefines the Wavelength label as 
   being an IEEE floating point encoding of the wavelength. As an 
   example of wavelength values, the reader is referred to [G.694.1] 
   which lists the frequencies from the ITU-T DWDM frequency grid. The 
   same can be done for CWDM technology by using the wavelength defined 
   in [G.694.2]. 

   The information carried in a Wavelength label is: 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             Label                             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Label: 32 bits 
    
     The label indicates the frequency value to be used. The value is 
     IEEE Floating point encoded. This may be an ITU-T DWDM frequency. 
     For convenience, Appendix 1 provides the list of IEEE Floating 
     point values for the ITU-T DWDM frequency grid. 
 
2.2.     Label Set Wavelength Subchannel 
    
   This document aligns with the general definition of Label Set in 
   section 3.5 of [RFC3471]. However, it provides a clarification 
 
                         Expires October 2005              [Page 4] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

   related to the subchannel value to be used by an LSC LSR. For this 
   type of equipment the subchannel field SHOULD represent the 
   Wavelength label (ITU-T DWDM frequency grid). 
    
2.3.     RSVP-TE Extensions 
    
   In other to distinguish Wavelength label with local significance from 
   the Wavelength label with global meaning, the latter SHOULD use the 
   same format as the generalized label with the new C-Type (TBA). 

   In the context of "true" lambda switching, the generalized label has 
   the following format: 
    
   0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |            Length             | Class-Num (16)| C-Type (TBA)  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |               ITU-T DWDM Frequency Grid Label                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

3.   IANA Considerations 
    
   IANA assigns values to RSVP protocol parameters. Within the current 
   document an object is defined. This object contains a C-Type. This 
   section defines the rules for the assignment of the related C-Type 
   value. This section uses the terminology of BCP 26 "Guidelines for 
   Writing an IANA Considerations Section in RFCs" [BCP26]. 
    
   As per [RFC2205], C-Type is an 8-bit number that identifies the 
   function of an object. All possible values except zero are available 
   for assignment. 
    
   The assignment of the C-Type value of the object defined in this 
   document inherits C-Type from the Label object, i.e., object class 
   number 16 [RFC3209]. 
    
   The Wavelength Switching Label defined in this document has the 
   following C-Type value to be assigned by IANA: 
    
     o RSVP_LABEL (Class-Num = 16) 
          - Wavelength Switching Label (C-Type = To Be Assigned) 

4.   Security Considerations 

                         Expires October 2005              [Page 5] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

   There may be an argument that by giving the label global meaning, one 
   would decrease security.  The closest example of using global meaning 
   is the label setting for SONET/SDH. By using a global meaning for its 
   labels, SONET/SDH did not introduce any new security considerations. 
   This serves as an indication that this document introduces no new 
   security considerations to either [RFC3473] or [RFC3472]. GMPLS 
   security is described in section 11 of [RFC3471] and refers to 
   [RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP. 

5.   Acknowledgements 
    
   The authors would like to thank Adrian Farrel for his feedback and 
   comments. 

                         Expires October 2005              [Page 6] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

6.   References 
    
6.1.     Normative References 
    
   [G.694.1]  ITU-T Recommendation G.694.1, "Spectral grids for WDM 
              applications: DWDM frequency grid", June 2002. 
    
   [G.694.2]  ITU-T Recommendation G.694.2, "Spectral grids for WDM 
              applications: CWDM wavelength grid", December 2003. 
    
   [IEEE754]  "Standard for Binary Floating-Point Arithmetic", IEEE-
              754, 1985. 
    
   [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 
              Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 
              Functional Specification", RFC 2205, September 1997. 
    
   [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated 
              Services", RFC 2210, September 1997. 
    
   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 
              Tunnels", RFC 3209, December 2001. 
    
   [RFC3212]  Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, 
              L., Doolan, P., Worster, T., Feldman, N., Fredette, A., 
              Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. 
              Malis, "Constrained-Based LSP Setup using LDP", RFC 3212, 
              January 2002. 
    
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
              Requirement Levels," BCP 14, IETF RFC 2119, March 1997. 
    
   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching 
              (MPLS) Signaling Functional Description", RFC 3471, 
              January 2003. 
    
   [RFC3472]  Ashwood-Smith, P. and L. Berger, "Generalized Multi-
              Protocol Label Switching (MPLS) Signaling - Constraint-
              based Routed Label Distribution Protocol (CR-LDP) 
              Extensions", RFC 3472, January 2003. 
    
   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching 
              (MPLS} Signaling - Resource ReserVation Protocol Traffic 
              Engineering (RSVP-TE) Extensions", RFC 3473, January 
              2003. 

                         Expires October 2005              [Page 7] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

   [RFC3945]  Mannie, E., Ed., "Generalized Multiprotocol Label 
              Switching (GMPLS) Architecture", RFC 3945, October 2004. 
    
6.2.     Informative Reference 
    
   [BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing an 
              IANA Considerations Section in RFCs", BCP 26, RFC 2434, 
              October 1998. 
    
   [RFC2026]  Bradner, S., "The Internet Standards Process - Revision 
              3", BCP 9, RFC 2026, October 1996. 

Appendix 1 - ITU-T DWDM frequency grid and IEEE floating point 
    
   The list below illustrates some nominal central frequencies within 
   the C and L bands of the DWDM grid (12.5THz spacing) taken from 
   [G.694.1]and their respective IEEE floating point (32 bits encoding) 
   value [IEEE754]. 
    
          Nominal central            Wavelength label 
          Frequency (THz)         (IEEE Floating point) 
       ---------------------    ------------------------ 
               .                           . 
               .                           . 
               .                           . 
            195.9375                  0x4343F000 
            195.9250                  0x4343ECCD 
            195.9125                  0x4343E99A 
            195.9000                  0x4343E666 
            195.8875                  0x4343E333 
            195.8750                  0x4343E000 
            195.8625                  0x4343DCCD 
            195.8500                  0x4343D99A 
            195.8375                  0x4343D666 
            195.8250                  0x4343D333 
            195.8125                  0x4343D000 
            195.8000                  0x4343CCCD 
            195.7875                  0x4343C99A 
            195.7750                  0x4343C666 
            195.7625                  0x4343C333 
            195.7500                  0x4343C000 
            195.7375                  0x4343BCCD 
            195.7250                  0x4343B99A 
            195.7125                  0x4343B666 
            195.6875                  0x4343B000 
            195.6750                  0x4343ACCD 
 
                         Expires October 2005              [Page 8] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

            195.6625                  0x4343A99A 
               .                           . 
               .                           . 
               .                           . 
               .                           . 
               .                           . 
               .                           . 
            193.2375                  0x43413CCD 
            193.2250                  0x4341399A 
            193.2125                  0x43413666 
            193.2000                  0x43413333 
            193.1875                  0x43413000 
            193.1750                  0x43412CCD 
            193.1625                  0x4341299A 
            193.1500                  0x43412666 
            193.1375                  0x43412333 
            193.1250                  0x43412000 
            193.1125                  0x43411CCD 
            193.1000                  0x4341199A 
            193.0875                  0x43411666 
            193.0750                  0x43411333 
            193.0625                  0x43411000 
            193.0500                  0x43410CCD 
            193.0375                  0x4341099A 
            193.0250                  0x43410666 
            193.0125                  0x43410333 
            193.0000                  0x43410000 
            192.9875                  0x4340FCCD 
            192.9750                  0x4340F99A 
            192.9625                  0x4340F666 
               .                           . 
               .                           . 
               .                           . 
               .                           . 
               .                           . 
               .                           . 
            184.7750                  0x4338C666 
            184.7625                  0x4338C333 
            184.7500                  0x4338C000 
            184.7375                  0x4338BCCD 
            184.7250                  0x4338B99A 
            184.7125                  0x4338B666 
            184.7000                  0x4338B333 
            184.6875                  0x4338B000 
            184.6750                  0x4338ACCD 
            184.6625                  0x4338A99A 
            184.6500                  0x4338A666 
            184.6375                  0x4338A333 
 
                         Expires October 2005              [Page 9] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

            184.6250                  0x4338A000 
            184.6125                  0x43389CCD 
            184.6000                  0x4338999A 
            184.5875                  0x43389666 
            184.5750                  0x43389333 
            184.5625                  0x43389000 
            184.5500                  0x43388CCD 
            184.5375                  0x4338899A 
            184.5250                  0x43388666 
            184.5125                  0x43388333 
            184.5000                  0x43388000 
               .                           . 
               .                           . 
               .                           . 

Authors' Addresses 
    
   Sidney Shiba (Fujitsu) 
   2801 Telecom Parkway 
   Richardson, TX 75082, USA 
   Phone: +1 972 479 6041 
    
   Email: [email-masked] 

   Richard Rabbat (Fujitsu) 
   1240 East Arques Ave, MS 345 
   Sunnyvale, CA 94085, USA 
   Phone: +1 408 530 4537 
    
   Email: [email-masked] 

Disclaimer of Validity 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

7.   Copyright Statement 

                         Expires October 2005             [Page 10] 

               Generalized Labels for LSC-Capable LSRs      October 2005             

   Copyright (C) The Internet Society (2005).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

8.   Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement    
   this standard.  Please address the information to the IETF at    
   [email-masked]. 

Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

                         Expires October 2005             [Page 11]

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Oct 2005 10:44:52 +0100

Dimitri,

Thanks for your work reviewing these recent I-Ds. It is really valuable
and I'd welcome other people doing similar reviews.

> domain-wide vs link local significant label

Without being too picky, I think all labels are semanticful otherwise, we
would not know what resource they refered to.

So the point reduces to whether the scope of the semantics are link-local
or wider.

> y2k's, to have a change in the wavelength label definition;

This is the question I would like to get to the bottom of. In other words:
do we need this function?

It seems to me that the question being asked is this:

   If I want to compute a path that has some form of wavelength
   constraints, what information do I need access to?

Another question might be:

   If I want to signal a path with wavelength constraints what
   information do I need to include in the signaling message?

I'd suggest that when we started on GMPLS, we were enthusiastic about
transparent optical networks, but we were not properly focusing wavelength
constraints because lambda-switching PXCs didn't take off. Therefore we
didn't examine the requirements for wavelength constraints in routing and
signaling. The authors of this I-D are claiming new hardware requirements
for the same function.

> there are
<http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels
-00.txt>

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 27 Oct 2005 15:16:13 +0200

adrian - see in-line

> would not know what resource they refered to.

actually you have unstructured label space whose interpretation can only 
be done in the context of the link associated to this label exchange and 
if you have an additional level of indirection -> "semanticless" as the 
value in itself (with its associated link) does not tell you more about 
the resource to be used (its just equivalent to an index) you need for 
instance to perform initial LMP exchange to know the data plane resource 
correspondance

but you have also structured label spaces like TDM whose interpretation 
can be done (together with the associated link) since they provide you 
with the exact timeslot position in the SONET/SDH multiplexing tree -> 
so the label value space carries a semantic

hope this clarifies -

> So the point reduces to whether the scope of the semantics are link-local

see above - the discussion is important, in TDM this has been done in 
order to avoid timeslot position/index exchange while the structure is 
perfectly know and invariant - hence, draw an analogy with LSC requires 
careful thought

>    constraints, what information do I need access to?

you have at this level three type of constraints: spatial, spectral and link

currently GMPLS for wavelegnth constraints works with source-driven 
spatial routing (constraint-based source-routing so implying both TE 
routing and signaling exchanges) and receiver-driven spectral routing 
(via the label set/acceptable label set mechanism so implying only 
signaling exchanges)

>    information do I need to include in the signaling message?

shouldn't you ask the question, what's not workable with the present 
solution we have at hand in RFC3473 ?

> signaling. The authors of this I-D are claiming new hardware requirements

adrian, i am not sure to understand ... hence, i would like to know from 
authors how the following cornerstone problem has been solved

1. either the network is pre-engineered and you don't need to take care 
about any spectral routing specifics for traffic engineering purposes

2. or the network is not pre-engineered and i would like to know if the 
specifics of analog transmission/switching have been addressed such as 
to be compatible with the constraint-based routing mechanisms used today 
while keeping a low blocking probability

> .