Internet Engineering Task Force                           M. Kattan, Ed.
Internet-Draft                                             G. Martinelli
Intended status: Informational                                D. Bianchi
Expires: April 17, 2011                                            Cisco
                                                        October 14, 2010


                  WSON Wavelenght Property Information
                     draft-kattan-wson-property-00

Abstract

   Wavelength Switched Optical Network will extend GMPLS protocols to to
   manage wavelength across DWDM optical networks.  In many situations
   the control plane needs to know additional information regarding
   wavelengths.  The current proposal identify a way to carry some
   property information along with wavelength information.  Control
   plane can leverage the knowledge of such properties during its
   operations.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 17, 2011.

Copyright Notice

   Copyright (c) 2010 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
   (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



Kattan, et al.           Expires April 17, 2011                 [Page 1]


Internet-Draft              Abbreviated Title               October 2010


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Lambda Properties Definitions . . . . . . . . . . . . . . . . . 5
   4.  Lambda Properties Encoding  . . . . . . . . . . . . . . . . . . 6
     4.1.  OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . 6
     4.2.  RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9






























Kattan, et al.           Expires April 17, 2011                 [Page 2]


Internet-Draft              Abbreviated Title               October 2010


1.  Introduction

   One of the current Generalized MPLS (GMPLS) evolutions is toward the
   Wavelength Switched Optical Networks (WSON) as described in
   [I-D.ietf-ccamp-rwa-wson-framework].  A related work is defined
   within [I-D.ietf-ccamp-gmpls-g-694-lambda-labels] defining the GMPLS
   label in a format suitable for Lambda Switched Capable (LSC
   equipments).

   Todays WSON networks are implemented through DWDM technologies and
   they treats all light paths as equal regardless of the type of data,
   bandwidth and mission criticality of the traffic it is carrying.

   This draft suggests the introduction of some properties like
   prioritizing light paths for scenarios such as restoration, fiber
   congestion and resource contention.  This could be achieved in
   assigning properties information to each light path.  Following
   sections will describe some scenarios where such information will be
   useful.  How those information are assigned is out of the scope of
   this draft.

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


2.  Scenarios

   The following list identify several scenarios occurring in operating
   WSON networks where some wavelength information will help.  Note that
   this scenarios are triggered by the availability of new
   reconfigurable equipments allowing new level of flexibility within
   DWDM networks.

   Example of this hardware would be multi-degree Reconfigurable Optical
   Add Drop Multiplexers or ROADMs to support mesh DWDM networks.  Fiber
   1 is an example of a meshed DWDM network where multiple light path
   are being set up to and from node C.











Kattan, et al.           Expires April 17, 2011                 [Page 3]


Internet-Draft              Abbreviated Title               October 2010


               +++++
               + B +
               +++++
               / | \        A-C Fiber has 30 wavelengths setup
              /  |  \       D-C Fiber has 20 Wavelengths setup
             /  +++  \
            /  + D +  \
           /  / +++ \  \    Most wavelengths on B-C fiber are used, only
          /  /       \  \   10 wavelengths are still available.
         /  /         \  \
       +++++           \ +++++
       + A + ----------- + C +
       +++++             +++++


                                 Figure 1

   (a)  Prioritize then Restore

        With the reference to Figure 2 we can consider a dual fiber cut
        on the path A-C and D-C.  A lambda prioritization might be used
        to ensure high priority light paths be served first.  This will
        ensure both a faster restoration time compared to other channels
        as well as the ability of high priority light paths to grab
        first (before other lower priority light paths) the available
        resources on the working fiber.


                +++++
                + B +
                +++++
                / | \        A-C Fiber has 30 wavelengths setup
               /  |  \       D-C Fiber has 20 Wavelengths setup
              /  +++  \
             /  + D +  \     Question is which wavelengths out of the 50
            /  / +++ \  \    are going to be restored (selection of
           /  /       X  \   10 only)?
          /  /         \  \
        +++++           \ +++++
        + A + ---- X ---- + C +
        +++++             +++++


                                 Figure 2







Kattan, et al.           Expires April 17, 2011                 [Page 4]


Internet-Draft              Abbreviated Title               October 2010


   (b)  Revertive Operation

        In this scenario, a fiber is being restored and hence having a
        high priority light paths restored first might or might not be
        desirable.  Setting a revertive or not revertive option would be
        useful in this scenario.  Moreover, in the event of multiple
        fiber cuts with only one fiber restored as an example,
        prioritizing light paths will ensure higher priority traffic
        will get the best service as well as up time once the WSON
        restoration mechanism kicks in.  Other possibilities inlcude
        defining some others lambda properties like a "no not restore
        bit" or "Wait time to restore" to allow the control plane
        operates according to different restoration strategies.

   (c)  Network Optimization

        Similar to revertive operation, prioritizing light paths will
        also be useful in network optimization.  High priority traffic
        will always get the option to ride on the best available fiber
        path.  Also high priority light path could be provided with the
        option to get the best performance OI parameters to chose from.

   (d)  Service Level Agreement support

        This could be useful for DWDM service providers where light
        paths are tagged with different parameters so that to create a
        desirable and configurable level of SLA.  This SLA could be
        derived from bandwidth (100G, 40G and 10G), traffic type (TDM vs
        IP/Eth or FC payload) or just a network management defined
        requirement.

   (e)  Resource Contention

        In the event of one or multiple fiber cuts, we could be faced
        with a situation whereby the number of light paths to be
        restored is larger than the available light path resources on
        the working fiber (see Figure 2 above).  Having light paths
        prioritization together with a wait-time-to-restore will ensure
        that the high priority traffic will be served first and hence
        will be able to grab the available resources first.


3.  Lambda Properties Definitions

   This section provide a list of wavelengths properties that worths to
   include in a control plane.

   Priority.  This information will allow a preferred treatment to a



Kattan, et al.           Expires April 17, 2011                 [Page 5]


Internet-Draft              Abbreviated Title               October 2010


   wavelength with higher priority.

   Do Not Restore.  If this information will not restore try to restore
   the wavelength after a failure.

   Wait-Time-to-Restore.  This information will report a time elapsed
   before a wavelength go through a restoration process.

   Hold-OfF-Time.


4.  Lambda Properties Encoding

   The lambda priority will be encoded over three bits.  There are
   different encoding possibility depending on the protocol used to
   distribute this information over the control plane.

   It worth noting that GMPLS extension in [RFC4202] and [RFC4203]
   already define LSP priority bandwidth within Interface Switching
   Capability Descriptor sub-TLV.  This concept however does not suffice
   for WSON LSP for the scenario represented above.



   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Reserved           |    HOT  |   WTR   |R| PRI |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 3

   The 3 bits PRI field represent the lambda priority encoding.  Zero
   means no priority, Seven means maximum priority

   R is the "Do not restore bit".  If set the wavelength will be exclude
   from any restoration

   WRT is the wait time to restore. 5 bits with a granularity of 0.5
   second will allow up to 16 seconds of delay on restoration.

   Hold Off timer.

4.1.  OSPF Extensions

   In order to improve the WSON path computation it make sense to add
   such information through the chosen IGP.  Current WSON proposal are



Kattan, et al.           Expires April 17, 2011                 [Page 6]


Internet-Draft              Abbreviated Title               October 2010


   available for OSPF-TE extentions.

   Document [I-D.ietf-ccamp-rwa-wson-encode] report the information on
   how to encode Dynamic Link Information through the label set
   specification.

   Efficient encoding through a Link Attributes shall be identified.  An
   initial proposal may looks like the label set attribute as explained
   in the following picture.  The wavelength property encoding will be a
   sub-TLV (type TBD) of the link TLV.  The set of


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TBD    | Reserved  |    Length = 16 bytes                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Grid |  C.S. |    Reserved   | n  for lowest frequency = -11 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Wavelength Property Field  <1>                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ....                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Wavelength Property Field  <n>                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   Where:

      TBD: is the sub-TLV type (to be defined)

      The Grid provide the current WSON wavelength encoding in use and
      must match with the label set defined in
      [I-D.ietf-ccamp-general-constraint-encode].

      A list of Wavelength property field, defined n Figure 4 in an
      order they match with the last label set advertised.

4.2.  RSVP Extensions

   WSON signalling extentions are reported through
   [draft-bernstein-ccamp-wson-signaling-07].  In addition to this a new
   LSP_ATTRIBUTES as defined in [RFC5420] will be required to carry the
   lambda priority information.

   A new LSP_ATTRIBUTE shall include the Wavelength Property Field as
   defined in Figure 4



Kattan, et al.           Expires April 17, 2011                 [Page 7]


Internet-Draft              Abbreviated Title               October 2010


5.  Acknowledgements


6.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   for a guide).  If the draft does not require IANA to do anything, the
   section contains an explicit statement that this is the case (as
   above).  If there are no requirements for IANA, the section will be
   removed during conversion into an RFC by the RFC Editor.


7.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.


8.  References

8.1.  Normative References

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

8.2.  Informative References

   [I-D.ietf-ccamp-general-constraint-encode]
              Bernstein, G., "General Network Element Constraint
              Encoding for GMPLS Controlled Networks",
              draft-ietf-ccamp-general-constraint-encode-03 (work in
              progress), October 2010.

   [I-D.ietf-ccamp-gmpls-g-694-lambda-labels]
              Otani, T., Rabbat, R., Shiba, S., Guo, H., Miyazaki, K.,
              Caviglia, D., Li, D., and T. Tsuritani, "Generalized
              Labels for Lambda-Switching Capable Label Switching
              Routers", draft-ietf-ccamp-gmpls-g-694-lambda-labels-07
              (work in progress), April 2010.

   [I-D.ietf-ccamp-rwa-wson-encode]
              Bernstein, G., "Routing and Wavelength Assignment
              Information Encoding for Wavelength Switched Optical
              Networks", draft-ietf-ccamp-rwa-wson-encode-05 (work in
              progress), July 2010.



Kattan, et al.           Expires April 17, 2011                 [Page 8]


Internet-Draft              Abbreviated Title               October 2010


   [I-D.ietf-ccamp-rwa-wson-framework]
              Bernstein, G., Lee, Y., and W. Imajuku, "Framework for
              GMPLS and PCE Control of Wavelength Switched Optical
              Networks (WSON)", draft-ietf-ccamp-rwa-wson-framework-07
              (work in progress), October 2010.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.


Authors' Addresses

   Moustafa Kattan (editor)
   Cisco
   DUBAI,   500321
   UNITED ARAB EMIRATES

   Phone: + 1 408 527 5101
   Email: mkattan@cisco.com


   Giovanni Martinelli
   Cisco
   Italy

   Phone: +39 039 209 2044
   Email: giomarti@cisco.com


   David Bianchi
   Cisco
   Italy

   Phone: +39 039 209
   Email: davbianc@cisco.com






Kattan, et al.           Expires April 17, 2011                 [Page 9]