Skip to main content

GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signal-compatibility-ospf-10

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7688.
Authors Young Lee , Greg M. Bernstein
Last updated 2012-08-08
Replaces draft-lee-ccamp-wson-signal-compatibility-ospf
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7688 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ccamp-wson-signal-compatibility-ospf-10
Network Working Group                                            Y. Lee  
Internet Draft                                                   Huawei 
Intended status: Standards Track                           G. Bernstein 
Expires: February 2013                                Grotto Networking 
                                                                         
                                                                        
                                                                        
                                    
                                    
                                                         August 8, 2012 
                                      
    GMPLS OSPF Enhancement for Signal and Network Element Compatibility 
                 for Wavelength Switched Optical Networks 

          draft-ietf-ccamp-wson-signal-compatibility-ospf-10.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with 
   the provisions of BCP 78 and 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 

   This Internet-Draft will expire on February 8, 2007. 

Copyright Notice 

   Copyright (c) 2012 IETF Trust and the persons identified as the 
   document authors.  All rights reserved.  

    

 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 1] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents 
   (http://trustee.ietf.org/license-info) in effect on the date of 
   publication of this document. Please review these documents 
   carefully, as they describe your rights and restrictions with 
   respect to this document.  Code Components extracted from this 
   document must include Simplified BSD License text as described in 
   Section 4.e of the Trust Legal Provisions and are provided without 
   warranty as described in the Simplified BSD License. 

Abstract 

   This document provides GMPLS OSPF routing enhancements to support 
   signal compatibility constraints associated with WSON network 
   elements. These routing enhancements are required in common optical 
   or hybrid electro-optical networks where not all of the optical 
   signals in the network are compatible with all network elements 
   participating in the network.  

   This compatibility constraint model is applicable to common optical 
   or hybrid electro optical systems such as OEO switches, 
   regenerators, and wavelength converters since such systems can be 
   limited to processing only certain types of WSON signals. 

Conventions used in this document 

   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 [RFC2119]. 

Table of Contents 

    
   1. Introduction...................................................3
      1.1. Revision History..........................................3
   2. The Optical Node Property TLV..................................4
      2.1. Sub-TLV Details...........................................5
         2.1.1. Resource Pool Accessibility..........................6
         2.1.2. Resource Block Wavelength Constraints................6
         2.1.3. Resource Pool State..................................6
         2.1.4. Block Shared Access Wavelength Availability..........6
   3. ISCD format extensions.........................................7
      3.1. Switch Capability Specific Information....................7
   4. WSON Specific Scalability and Timeliness.......................8
   5. Security Considerations........................................9
 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 2] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   6. IANA Considerations............................................9
   7. References....................................................11
      7.1. Normative References.....................................11
      7.2. Informative References...................................11
   8. Authors and Contributors......................................12
   Authors' Addresses...............................................12
   Intellectual Property Statement..................................13
   Disclaimer of Validity...........................................13
    
1. Introduction 

   The documents [RFC6163, WSON-Info, WSON-Encode] explain how to 
   extend the wavelength switched optical network (WSON) control plane 
   to allow both multiple WSON signal types and common hybrid electro 
   optical systems as well hybrid systems containing optical switching 
   and electro-optical resources. In WSON, not all of the optical 
   signals in the network are compatible with all network elements 
   participating in the network. Therefore, signal compatibility is an 
   important constraint in path computation in a WSON.  

   This document provides GMPLS OSPF routing enhancements to support 
   signal compatibility constraints associated with general WSON 
   network elements. These routing enhancements are required in common 
   optical or hybrid electro-optical networks where not all of the 
   optical signals in the network are compatible with all network 
   elements participating in the network.  

   This compatibility constraint model is applicable to common optical 
   or hybrid electro optical systems such as OEO switches, 
   regenerators, and wavelength converters since such systems can be 
   limited to processing only certain types of WSON signals. 

   1.1. Revision History 

   From 00 to 01: The details of the encodings for compatibility moved 
   from this document to [WSON-Encode]. 

   From 01 to 02: Editorial changes. 

   From 02 to 03: Add a new Top Level Node TLV, Optical Node Property 
   TLV to carry WSON specific node information.  

   From 03 to 04: Add a new sub-TLV, Block Shared Access Wavelength 
   Availability TLV to be consistent with [WSON-Encode] and editorial 
   changes.  
 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 3] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   From 04 to 05: Add a new section that discusses OSPF scalability and 
   timeliness and editorial changes. 

   From 05 to 06: Change the title of the draft to "GMPLS OSPF 
   Enhancement" from "OSPF Enhancement" to make sure the changes apply 
   to the GMPLS OSPF rather than the base OSPF. Add specific OSPF 
   procedures on how sub-TLVs are packaged per [RFC3630] and editorial 
   changes.  

   From 06 to 07: Add clarifying texts on how to sub-divide the Optical 
   Node TLV in case it exceeds the IP MTU fragmentation limit. Delete 
   Section 3.2. to avoid multiple rules so as to avoid confusion.  

   From 07 to 08: Clean some old texts in Section 3. Align with [WSON-
   Encode] on the modulation and FEC type.  

   From 08 to 09: Added ISCD extensions for available labels and shared 
   backup labels. 

   From 09 to 10: Revised for OIC changes consistent with encoding 
   document. 

2. The Optical Node Property TLV  

   [RFC3630] defines OSPF TE LSA using an opaque LSA. This document 
   adds a new top level TLV for use in the OSPF TE LSA: the Optical 
   Node Property TLV. The Optical Node property TLV describes a single 
   node. It is constructed of a set of sub-TLVs. There are no ordering 
   requirements for the sub-TLVs. Only one Optical Node TLV shall be 
   advertised in each LSA. 

   The Optical Node Property TLV contains all WSON-specific node 
   properties and signal compatibility constraints. The detailed 
   encodings of these properties are defined in [WSON-Encode].  

   The following sub-TLVs of the Optical Node Property TLV are defined: 

   Value       Length      Sub-TLV Type 

 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 4] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   TBA         variable    Resource Block Information 
   TBA         variable    Resource Pool Accessibility 
   TBA         variable    Resource Block Wavelength Constraints 
   TBA         variable    Resource Pool State 
   TBA         variable    Block Shared Access Wavelength Availability 
    
   The detail encodings of these sub-TLVs are found in [WSON-Encode] as 
   indicated in the table below. 

   Sub-TLV Type                              Section [WSON-Encode]     
    
   Resource Block Information                      5.1 
   Resource Pool Accessibility                     4.1 
   Resource Block Wavelength Constraints           4.2 
   Resource Pool State                             4.3 
   Block Shared Access Wavelength Availability     4.4 
    

    
    

   All sub-TLVs defined here may occur at most once in any given 
   Optical Node TLV. "At most once" means that if there is sub-TLV 
   related information, it should be always included. These 
   restrictions need not apply to future sub-TLVs. Unrecognized sub-
   TLVs are ignored. 

   2.1. Sub-TLV Details  

   Among the sub-TLVs defined above, the Resource Pool State sub-TLV 
   and Block Shared Access Wavelength Availability are dynamic in 
   nature while the rest are static. As such, they can be separated out 
   from the rest and be advertised with multiple TE LSAs per OSPF 
   router, as described in [RFC3630] and [RFC5250]. Resource Block 
   Information 

   Resource Block Information sub-TLVs are used to convey relatively 
   static information about individual resource blocks including the 
   resource block properties and the number of resources in a block. 

   There are five nested sub-TLVs defined in the Resource Block 
   Information sub-TLV.  

   Value          Length      Sub-TLV Type    

 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 5] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   TBA            variable    Optical Interface Class List  
   TBA            variable    Input Client Signal List  
   TBA            variable    Processing Capability List  
    

   The detail encodings of these sub-TLVs are found in [WSON-Encode] as 
   indicated in the table below. 

   Name                             Section [WSON-Encode] 

   Optical Interface Class List           5.2 
   Input Client Signal List               5.3 
   Processing Capability List             5.4 
    
    
    
   2.1.1. Resource Pool Accessibility 

   This sub-TLV describes the structure of the resource pool in 
   relation to the switching device. In particular it indicates the 
   ability of an ingress port to reach a resource block and of a 
   resource block to reach a particular egress port. 

   2.1.2. Resource Block Wavelength Constraints 

   Resources, such as wavelength converters, etc., may have a limited 
   input or output wavelength ranges. Additionally, due to the 
   structure of the optical system not all wavelengths can necessarily 
   reach or leave all the resources. Resource Block Wavelength 
   Constraints sub-TLV describe these properties.  

   2.1.3. Resource Pool State 

   This sub-TLV describes the usage state of a resource that can be 
   encoded as either a list of 16 bit integer values or a bit map 
   indicating whether a single resource is available or in use. This 
   information can be relatively dynamic, i.e., can change when a 
   connection is established or torn down.  

   2.1.4. Block Shared Access Wavelength Availability 

   Resources blocks may be accessed via a shared fiber. If this is the 
   case then wavelength availability on these shared fibers is needed 
   to understand resource availability. 

 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 6] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

3. ISCD format extensions 

   The Interface Switching Capability Descriptor describes switching   
   capability of an interface [RFC 4202].  This document defines a new   
   Switching Capability value for WSON as follows: 

      Value                       Type 
      -----                       ---- 
      151 (TBA by IANA)           WSON-LSC capable (WSON-LSC) 
    
   Switching Capability and Encoding values MUST be used as follows: 

           Switching Capability = WSON-LSC 

           Encoding Type = Lambda [as defined in RFC3471] 

   When Switching Capability and Encoding fields are set to values as 
   stated above, the Interface Switching Capability Descriptor MUST be 
   interpreted as in RFC4203 with the optional inclusion of one or more 
   Switching Capability Specific Information sub-TLVs. 

   3.1. Switch Capability Specific Information 

   The technology specific part of the WSON ISCD may include a variable 
   number of sub-TLVs called Bandwidth sub-TLVs.  Two types of 
   Bandwidth TLV are defined (TBA by IANA): 

         - Type 1 - Available Labels 

         - Type 2 - Shared Backup Labels 

   The format of the SCSI MUST be as depicted in the following figure: 

      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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |        Type = 1 (Available)   |           Length              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      |                 Available Label Sub-TLV                       | 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      ~                               ...                             ~ 
 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 7] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Type = 2 (Shared backup)  |           Length              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      |                 Shared Backup Label Sub-TLV                   | 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 

                              Figure 1: SCSI format 

   Where the Available Label Sub-TLV and Shared Backup Label sub-TLV 
   are defined in [Gen-Encode]. 

4. WSON Specific Scalability and Timeliness 

   This document has defined five sub-TLVs specific to WSON. The 
   examples given in [WSON-Encode] show that very large systems, in 
   terms of channel count, ports, or resources, can be very efficiently 
   encoded.  

   There has been concern expressed that some possible systems may 
   produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In 
   a typical node configuration, the optical node property TLV will not 
   exceed the IP MTU. In a rare case where the TLV exceed the IP MTU, 
   IP fragmentation/reassembly can be used, which is an acceptable 
   method.  

   If the size of this LSA is greater than the MTU, then these sub-TLVs 
   can be packed into separate LSAs. From the point of view of path 
   computation, the presence of the Resource Block Information sub-TLV 
   indicates that resources exist in the system and may have signal 
   compatibility or other constraints. The other four sub-TLVs indicate 
   constraints on access to, and availability of those resources.  

   Hence the "synchronization" procedure from a path computation point 
   of view is quite simple. Until a Resource Block Information sub-TLV 
   is received for a system path cannot make use of the other four sub-
   TLVs since it does not know the nature of the resources, e.g., are 
   the resources wavelength converters, regenerators, or something 
   else. Once this sub-TLV is received path computation can proceed 
   with whatever of the additional types of sub-TLVs it may have 
   received (there use is dependent upon the system type). If path 
   computation proceeds with out of date or missing information from 
 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 8] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   these sub-TLVs then there is the possibility of either (a) path 
   computation computing a path that does not exist in the network, (b) 
   path computation failing to find a path through the network that 
   actually exists. Both situations are currently encountered with 
   GMPLS, i.e., out of date information on constraints or resource 
   availability. 

   Note that the connection establishment mechanism (signaling or 
   management) is ultimately responsible for the establishment of the 
   connection, and this implies that such mechanisms must insure signal 
   compatibility. 

    

    
5. Security Considerations 

   This document does not introduce any further security issues other   
   than those discussed in [RFC3630], [RFC4203]. 

6. IANA Considerations 

   This document introduces a new Top Level Node TLV (Optical Node 
   Property TLV) under the OSPF TE LSA defined in [RFC3630].   

   Value    TLV Type 

   TBA      Optical Node Property  

   IANA is to allocate a new TLV Type and its Value for this Top Level 
   Node TLV. 

   This document also introduces the following sub-TLVs associated with 
   the Optical Node Property TLV as defined in Section 2.1 as follows:  

   Value       Length      Sub-TLV Type 

   TBA         variable    Resource Block Information 
   TBA         variable    Resource Pool Accessibility 
   TBA         variable    Resource Block Wavelength Constraints 
   TBA         variable    Resource Pool State 
   TBA         variable    Block Shared Access Wavelength Availability 
 

 
 
 
Lee and Bernstein      Expires February 8, 2013                [Page 9] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   IANA is to allocate new sub-TLV Types and their Values for these 
   sub-TLVs defined under the Optical Node Property TLV.  

    

   There are five nested sub-TLVs defined in the Resource Block 
   Information sub-TLV as follows:  

   Value          Length      Sub-TLV Type 

   TBA            variable    Optical Interface Class List  
   TBA            variable    Input Client Signal List  
   TBA            variable    Processing Capability List  
 

   IANA is to allocate new Sub-TLV Types and their Values for these 
   Sub-TLVs defined under the Resource Block Information Sub-TLV.  

   Upon approval of this document, IANA will make the assignment of a    
   new Switching Capability value for the existing ISCD located at http:   
   //www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-
   tlvs.xml: 

   15     Interface Switching Capability Descriptor      [RFC4203] 

   Switching capability     Description                Reference 
   ----------------------  --------------------------  ---------- 
   151 (suggested)         WSON-LSC capable (WSON-LSC) [This.I-D] 
    
This document defines the following sub-TLVs of the ISCD TLV: 

          Value  Sub-TLV 
          -----  ------------------------------------------------- 
          1      Available Labels 
          2      Shared Backup Labels 

 
 
 
Lee and Bernstein      Expires February 8, 2013               [Page 10] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

 

7. References 

   7.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic                   
             Engineering (TE) Extensions to OSPF Version 2", RFC                 
             3630, September 2003. 

   [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 
             applications: DWDM frequency grid", June, 2002. 

   [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions 
             in Support of Generalized Multi-Protocol Label Switching 
             (GMPLS)", RFC 4203, October 2005.  

    

   [WSON-Encode]  G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 
             Wavelength Assignment Information Encoding for Wavelength 
             Switched Optical Networks", draft-ietf-ccamp-rwa-wson-
             encode, work in progress. 

   [Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General 
             Network Element Constraint Encoding for GMPLS Controlled 
             Networks", draft-ietf-ccamp-general-constraint-encode, 
             work in progress. 

   7.2. Informative References 

   [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 
             Wavelength Assignment Information Model for Wavelength 
             Switched Optical Networks", draft-ietf-ccamp-rwa-info, 
             work in progress. 

   [RFC6250] T. Otani, Ed., D. Li, Ed., "Generalized Labels for G.694    
             Lambda-Switching Capable Label Switching Routers", RFC 
             6250, March 2011. 

 
 
 
Lee and Bernstein      Expires February 8, 2013               [Page 11] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

   [RFC6163] Y. Lee, G. Bernstein,  W. Imajuku, "Framework for GMPLS 
             and PCE Control of Wavelength Switched Optical Networks", 
             RFC 6163, April 2011. 

   [RFC5250] Berger, L., et al., "The OSPF Opauqe LSA option", RFC 
             5250, July 2008. 

 

    

    

    

     

    

8. Authors and Contributors 

    

    
Authors' Addresses 

   Young Lee (ed.) 
   Huawei Technologies 
   1700 Alma Drive, Suite 100 
   Plano, TX 75075 
   USA 
    
   Phone: (972) 509-5599 (x2240) 
   Email: ylee@huawei.com 
 

   Greg M. Bernstein (ed.) 
   Grotto Networking 
   Fremont California, USA 
       
   Phone: (510) 573-2237 
   Email: gregb@grotto-networking.com 
    

 
 
 
 
Lee and Bernstein      Expires February 8, 2013               [Page 12] 


Internet-Draft OSPF Enhancement for WSON Signal Compatibility    August 
2012 
    

Intellectual Property Statement 

   The IETF Trust 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 any IETF 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.  

   Copies of Intellectual Property 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 
   any standard or specification contained in an IETF Document. Please 
   address the information to the IETF at ietf-ipr@ietf.org. 

Disclaimer of Validity 

   All IETF Documents and the information contained therein are 
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 
   HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 
   THE IETF TRUST 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 THEREIN WILL NOT INFRINGE 
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
   FOR A PARTICULAR PURPOSE. 

Acknowledgment 

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

    

 
 
 
Lee and Bernstein      Expires February 8, 2013               [Page 13]