[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-lee-ccamp-wson-signal-compatibility-ospf) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 7688

Network Working Group                                            Y. Lee
Internet Draft                                                   Huawei
Intended status: Standards Track                           G. Bernstein
Expires: November 2014                                Grotto Networking





                                                           May 22, 2014

    GMPLS OSPF Enhancement for Signal and Network Element Compatibility
                 for Wavelength Switched Optical Networks


          draft-ietf-ccamp-wson-signal-compatibility-ospf-15.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 November 22,2014.

Copyright Notice

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



   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Lee and Bernstein       Expires November 2014                  [Page 1]


Internet-Draft         OSPF Enhancement for WSON          May 2014


   (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 Generalized Multiprotocol Label Switching
   (GMPLS) Open Shortest Path First (OSPF) routing enhancements to
   support signal compatibility constraints associated with Wavelength-
   Switched Optical network (WSON) elements. These routing enhancements
   are applicable 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 Optical-Electronic-Optical
   (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 [RFC2119].

Table of Contents


   1. Introduction...................................................3
   2. The Optical Node Property TLV..................................3
      2.1. Resource Accessibility....................................4
      2.2. Resource Wavelength Constraints...........................5
      2.3. Resource Block Pool State.................................5
      2.4. Resource Block Shared Access Wavelength Availability......5
   3. Interface Switching Capability Descriptor (ISCD) Format
   Extensions........................................................5
      3.1. Switching Capability Specific Information.................6
   4. WSON Specific Scalability and Timeliness.......................7
   5. Security Considerations........................................8
   6. IANA Considerations............................................8
      6.1. Optical Node Property TLV.................................8



Lee and Bernstein       Expires November 2014                  [Page 2]


Internet-Draft         OSPF Enhancement for WSON          May 2014


         6.1.1. Optical Node Property Sub-TLV........................8
      6.2. WSON-LSC Switching Type TLV...............................9
         6.2.1. WSON-LSC SCSI Sub-TLVs...............................9
   7. References....................................................10
      7.1. Normative References.....................................10
      7.2. Informative References...................................11
   8. Authors' Addresses............................................11
   Intellectual Property Statement..................................12
   Disclaimer of Validity...........................................12

1. Introduction

   The documents [RFC6163, WSON-Info, WSON-Encode] explain how to
   extend the Wavelength Switched Optical Network (WSON) control plane
   to support 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 applicable 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.

   Related to this document is [GEN-OSPF] which provides GMPLS OSPF
   routing enhancements to support the generic routing and label
   assignment process that can be applicable to a wider range of
   technologies beyond WSON.

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 comprised of a set of sub-TLVs. There are no ordering
   requirements for the sub-TLVs. Only one Optical Node Property TLV
   shall be advertised in each LSA.



Lee and Bernstein       Expires November 2014                  [Page 3]


Internet-Draft         OSPF Enhancement for WSON          May 2014


   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

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

   The detailed 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                               4.1
   Resource Accessibility                                   3.1
   Resource Wavelength Constraints                          3.2
   Resource Block Pool State                                3.3
   Resource Block Shared Access Wavelength Availability     3.4


   All sub-TLVs defined here may occur at most once in any given
   Optical Node TLV. If more than one copy of a sub-TLV is received,
   only the first one of the same type is processed and the rest are
   ignored upon receipt. These restriction need not apply to future
   sub-TLVs. Unrecognized sub-TLVs are ignored.

   Among the sub-TLVs defined above, the Resource Block Pool State sub-
   TLV and Resource 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].


2.1. Resource 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.



Lee and Bernstein       Expires November 2014                  [Page 4]


Internet-Draft         OSPF Enhancement for WSON          May 2014


2.2. Resource 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. The Resource Wavelength
   Constraints sub-TLV describes these properties.

2.3. Resource Block Pool State

   This sub-TLV describes the usage state of a resource that can be
   encoded as either a list of 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.4. Resource 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.

3. Interface Switching Capability Descriptor (ISCD) Format Extensions

   The ISCD describes switching capability of an interface [RFC4202].
   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.






Lee and Bernstein       Expires November 2014                  [Page 5]


Internet-Draft         OSPF Enhancement for WSON          May 2014


3.1. Switching 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 sub-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                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                               ...                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     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].





Lee and Bernstein       Expires November 2014                  [Page 6]


Internet-Draft         OSPF Enhancement for WSON          May 2014


   The label format defined in [RFC6205] MUST be used when advertising
   interfaces with a WSON-LSC type Switching Capability.



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 exceeds 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 computation 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 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 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.

   In case where the new sub-TLVs or their attendant encodings are
   malformed, the proper action would be to log the problem and ignore




Lee and Bernstein       Expires November 2014                  [Page 7]


Internet-Draft         OSPF Enhancement for WSON          May 2014


   just the sub-TLVs in GMPLS path computations rather than ignoring
   the entire LSA.

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

   For general security aspects relevant to Generalized Multiprotocol
   Label Switching (GMPLS)-controlled networks, please refer to
   [RFC5920].

6. IANA Considerations



6.1. Optical Node Property TLV

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

   New IANA registry will be created for the Optical Node Property TLV
   to allocate a new TLV Type and its Value for this Top Level Node TLV
   in the "Top Level Types in TE LSAs" section of the "OSPF Traffic
   Engineering TLVs" registry located at
   http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-
   eng-tlvs.xhtml.

   The following TLV is allocated in this specification.

   Value             TLV Type                           Reference

   6 (suggested)     Optical Node Property              [This.I-D]



   6.1.1. Optical Node Property Sub-TLV

   Additionally, new IANA registry will be created for sub-TLVs of the
   Optical Node Property TLV to create a new section named "Types of



Lee and Bernstein       Expires November 2014                  [Page 8]


Internet-Draft         OSPF Enhancement for WSON          May 2014


   sub-TLVs of Optical Node Property TLV (Value TBA)" in the "OSPF
   Traffic Engineering TLVs" registry located at
   http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-
   eng-tlvs.xml, and allocate new sub-TLV Types and their Values for
   these sub-TLVs defined under the Optical Node Property TLV as
   follows:

   Value          Length      Sub-TLV Type                    Reference

   0                          Reserved
   1 (suggested)  variable    Resource Block Information     [This.I-D]
   2 (suggested)  variable    Resource Accessibility         [This.I-D]
   3 (suggested)  variable    Resource Wavelength
                              Constraints                    [This.I-D]
   4 (suggested)  variable    Resource Block Pool State      [This.I-D]
   5 (suggested)  variable    Resource Block Shared
                            Access Wavelength Availability [This.I-D]
  6-65535         Unassigned

   Types are to be assigned via Standards Action as defined in
   [RFC5226].

6.2. WSON-LSC Switching Type TLV

   A new IANA registry will be created to make the assignment of a new
   value for the existing "Switching Types" TLV of the "GMPLS Signaling
   Parameters" registry located at
   http://www.iana.org/assignments/gmpls-sig-parameters as follows:

   Switching capability     Description                Reference
   ----------------------  --------------------------  ----------
   151 (suggested)         WSON-LSC capable (WSON-LSC) [This.I-D]


   6.2.1. WSON-LSC SCSI Sub-TLVs

   Additionally, a new IANA registry will be created for sub-TLVs of
   the WSON-LSC SCSI sub-TLV to create a new section/sub-registry named
   "Types for sub-TLVs of WSON-LSC SCSI (Switch Capability-Specific
   Information)" section under the "OSPF Traffic Engineering TLVs"
   registry, with the following sub-TLV types:

          Value               Sub-TLV                      Refenrence
          0                   Reserved




Lee and Bernstein       Expires November 2014                  [Page 9]


Internet-Draft         OSPF Enhancement for WSON          May 2014


          1  (suggested)      Available Labels             [This.I-D]
          2  (suggested)      Shared Backup Labels         [This.I-D]
          3-65535             Unassigned

   Types are to be assigned via Standards Action as defined in
   [RFC5226].


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.

   [RFC6205] T. Otani, Ed. and D. Li, Ed., "Generalized Labels for
             Lambda-Switch-Capable (LSC) Label Switching Routers", RFC
             6205, March 2011.

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

   [GEN-OSPF] F. Zhang, Y. Lee, J. Han, G, Bernstein and Y. Xu, "OSPF-
             TE Extensions for General Network Element Constraints",
             draft-ietf-ccamp-gmpls-general-constraints-ospf-te, work
             in progress.




Lee and Bernstein       Expires November 2014                 [Page 10]


Internet-Draft         OSPF Enhancement for WSON          May 2014


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.

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

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

   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
             May 2008.

   [RFC5920] Luyuan Fang(Ed.), "Security Framework for MPLS and GMPLS N
            Networks", RFC5920, July 2010.



8. Authors' Addresses

   Young Lee (ed.)
   Huawei Technologies
   5340 Legacy Drive, Building 3
   Plano, TX 75024
   USA

   Phone: (469)277-5838
   Email: leeyoung@huawei.com


   Greg M. Bernstein (ed.)
   Grotto Networking
   Fremont California, USA

   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com




Lee and Bernstein       Expires November 2014                 [Page 11]


Internet-Draft         OSPF Enhancement for WSON          May 2014




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 November 2014                 [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/