Internet DRAFT - draft-cbcs-ccamp-sson-guard-bands-reqs

draft-cbcs-ccamp-sson-guard-bands-reqs






CCAMP Working Group                                        D. Ceccarelli
Internet-Draft                                                G. Bottari
Intended status: Informational                                  Ericsson
Expires: September 6, 2012                                      N. Sambo
                                                 Scuola Superiore S.Anna
                                                               F. Cugini
                                                                C.N.I.T.
                                                                F. Zhang
                                                     Huawei Technologies
                                                             R. Casellas
                                                                    CTTC
                                                           March 5, 2012


     Guard Bands requirements for GMPLS controlled optical networks
               draft-cbcs-ccamp-sson-guard-bands-reqs-00

Abstract

   The continuous increase of flexibility and bit rate in optical
   networks has higher and higher impacts on inter-channel effects (e.g.
   Cross-phase modulations).  This effect leads to the introduction of
   Guard Bands between adjacent light paths in order to reduce the
   inter-channel detrimental effects.

   This document provides requirements for the devolpment of protocol
   extensions to support Generalized Multi-Protocol Label Switching
   (GMPLS) and Path Computation Element (PCE) management of Guard Bands.

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 September 6, 2012.

Copyright Notice




Ceccarelli, et al.      Expires September 6, 2012               [Page 1]


Internet-Draft       Guard bands in optical networks          March 2012


   Copyright (c) 2012 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
   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Guard Band definition . . . . . . . . . . . . . . . . . . . . . 4
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  PCE Requirements  . . . . . . . . . . . . . . . . . . . . . 5
     5.2.  PCEP Requirements . . . . . . . . . . . . . . . . . . . . . 7
     5.3.  GMPLS Requirements  . . . . . . . . . . . . . . . . . . . . 7
       5.3.1.  OSPF-TERequirements . . . . . . . . . . . . . . . . . . 7
       5.3.2.  RSVP-TE Requirements  . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
















Ceccarelli, et al.      Expires September 6, 2012               [Page 2]


Internet-Draft       Guard bands in optical networks          March 2012


1.  Introduction

   Given the advancement of optical transmission technology, optical
   channels may use thinner granularity of the spectrum, which are
   configurable depending on the modulation format and bit-rate
   [G.FLEXIGRID].  Thus, thanks to this flexibility, the capacity of
   optical networks is strongly increasing.  However, the spacing
   between channels may be limited by the inter-channel effects (e.g,
   cross-phase modulation - XPM) which can lead to a bit error rate
   increase.  Typically, as the case of XPM or cross-talk, the larger
   the spectral distance among interfering signals, the less detrimental
   the effect.  Thus, a guard band (i.e., a spectral distance such that
   detrimental effects are mitigated) may be considered to counteract
   inter-channel detrimental effects [sambo-jlt].

   Guard Bands (GB) may be required in either fixed- [RFC6163] or
   flexible-grid networks [G.694.1v1] [G.FLEXIGRID].  As an example, in
   fixed-grid networks, high-speed signals (100Gbit/s and beyond) may be
   deployed together with low-speed signals (10Gb/s).  In such a
   scenario, high-speed signals utilizing phase-modulated formats (e.g.,
   dual polarization quadrature phase shift keying - DP-QPSK - 100Gb/s)
   suffer from XPM induced by low-speed signals, exploiting intensity
   modulation (e.g. on off keying - OOK - 10Gb/s).  Thus, GB may be used
   to avoid problems of XPM between low- and high-speed signals.
   Similarly, in flex-grid networks, high-speed signals may exploit
   quadrature amplitude modulation (QAM), which experience both
   intensity and phase modulation.  Also in such a scenario, XPM may be
   very detrimental.

   The value of a guard band may depend on physical properties of the
   traversed links and on the bit rate and modulation format of the
   interfering signals.  Given two interfering signals, inter-channel
   effects among the two signals are counteracted if they are separated
   by GB.  This document describes the requirements of PCE and GMPLS
   control to account for guard bands.

1.1.  Terminology

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


2.  Definitions

      Demeaning LSP: an LSP which induces a detrimental effect on
      another LPS




Ceccarelli, et al.      Expires September 6, 2012               [Page 3]


Internet-Draft       Guard bands in optical networks          March 2012


      Degraded LSP: an LSP which may be degraded by inter-channel
      effects induced by a demeaning GB: guard band

      Working LSP: an active LSP

      RSA: routing and spectrum assignment

      IV: impairment validated (e.g., a route is impairment validated if
      its bit error rate is acceptable for any channel)


3.  Scenarios

   Fixed-grid network is here assumed as a particular case of flex-grid
   network, thus hereafter only the case of flex-grid networks will be
   treated.  Similarly, RWA is assumed as a particular case of RSA and
   only RSA will be treated.  The following PCE scenarios are considered
   [draft-flexible]:

      - IV and RSA PCE : From a GB point of view there is no difference
      between IV+RSA and IV&RSA, so a general IV+RSA case will be
      considered.  In this case the PCE provides the ingress node with
      an impairment-validated route and a set of frequency slots.

      - IV PCE: PCE provides ingress node with an impairment-validated
      route.  Then, slot assignment is distributed and performed by the
      egress node which may rely on collecting link status through the
      signaling protocol (RSVP-TE).

      - IV Candidate path PCE: PCE provides ingress node with a set of
      candidate routes (i.e., a set of impairment-validated routes).
      Then, a route is selected by the ingress node.  Slot assignment is
      distributed and performed by the egress node through the signaling
      protocol (RSVP-TE).


4.  Guard Band definition

   GB is defined as the minimum frequency range which separates two
   contiguous signals, S1 at bit rate B1 and modulation format M1 and S2
   at a bit rate B2 and modulation format M2, such that detrimental
   effects are negligible.









Ceccarelli, et al.      Expires September 6, 2012               [Page 4]


Internet-Draft       Guard bands in optical networks          March 2012


                              S1(B1;M1)           S2(B2;M2)
                           -------------     -------------------
                           |           |     |                 |
     -9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9 10 11
   ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--...
                           -------------     -------------------
                                        <--->
                                         GB


                           Figure 1: Guard Band

   Assuming fixed-grid networks, a number of channels (e.g. of a grid
   spacing of 50 GHz), instead of a number of slots would be considered
   for GB.

   The computation of GB may require the knowledge of:

      a. bit rate B and modulation format M of the interfering signals

      b. the power P values of the signals at each span.  In order to
      limit the stored and exchanged information, an unique value of P
      (worst-case scenario) may be considered for the demeaning LSP:
      i.e., the maximum value P experienced by an LSP of type (B2,M2).
      Similarly, an unique value P (worst-case scenario) may be
      considered for the degraded LSP: the minimum value P experienced
      by an LSP of type (B1,M1).

      c.  Fiber parameters: e.g. fiber attenuation, dispersion
      parameter, and fiber nonlinear Kerr coefficient

   Bit rate and modulation format should be mandatory information for GB
   computation (e.g., PCE may select the value of GB from a stored set
   of GB values, each one associated to a bit rate and modulation format
   pair), thus treated in the rest of the document.


5.  Requirements

5.1.  PCE Requirements

      - IV+RSA PCE: given an LSP request, by exploiting a TED, PCE may
      account for GB in the IV+RWA (or IV&RSA) process, if needed.  In
      the case of:

         + Stateful PCE: PCE has a TED (in simple terms as disseminated
         by OSPF-TE) plus an LSP-DB which are the active LSPs state.
         (e.g., the route and the slot used by a working LSP).  In order



Ceccarelli, et al.      Expires September 6, 2012               [Page 5]


Internet-Draft       Guard bands in optical networks          March 2012


         to identify the required GB, the TED plus the LSP-DB exploited
         by the PCE should be extended to store the following
         information:

            ++ Bit rate B of any working LSP in the network

            ++ Modulation format M of any working LSP in the network

            ++ Allocated central frequency and slot width for any active
            LSP in the network.

         + Stateless PCE: PCE exploits a TED which includes per-link
         information regarding the usage of the optical spectrum
         resource (e.g., Available Frequency Ranges).  If the PCE
         obtains the TED via e.g.  OSPF-TE this may also add additional
         requirements to OSPF-TE as detailed later on.  In order to
         identify the required GB, the TED exploited by the PCE should
         be extended to store the set of required information.  An
         example of such pieces of information could be:

            ++ Used frequency slots

            ++ Bit rate B associated to any frequency slot in use

            ++ Modulation format M associated to any frequency slot in
            use

      - IV PCE: given an LSP request, PCE provides the ingress node with
      an impairment validated route.  Then, wavelength or the slot
      assignment is distributed, e.g. performed through a signaling
      protocol (RSVP-TE).  In this case, PCE should inform the ingress
      node about the requirements of GB to separate the given LSP from
      other LSPs of specific bit rate B and modulation format M. Thus,
      PCEP and RSVP-TE may require extensions to account for GB.

      - IV Candidate path PCE: given an LSP request, PCE provides the
      ingress node with a set of impairment validated routes.  A route
      is selected by the ingress node.  Then, wavelength or the slot
      assignment is distributed, e.g. performed through a signaling
      protocol (RSVP-TE).  In this case, PCE should inform, for each
      candidate route, the ingress node about the requirements of GB to
      separate the given LSP from other LSPs of specific bit rate B and
      modulation format M. Thus, PCEP and RSVP-TE may require extensions
      to account for GB.







Ceccarelli, et al.      Expires September 6, 2012               [Page 6]


Internet-Draft       Guard bands in optical networks          March 2012


5.2.  PCEP Requirements

      - IV&RSA PCE: in this case, no extensions for GB are required by
      PCEP because PCEP client (e.g., the ingress node) does not require
      to know GB information

      - IV PCE: in this case, an extension may be needed in the PCEP
      Path Computation Reply message to inform the ingress node about
      required GBs along the route.  Then, GB information should be
      considered in the routing and slot assignment.

      - IV candidate path PCE: in this case, an extension may be needed
      in the PCEP Path Computation Reply message to inform the ingress
      node, for any candidate route, about required GBs along the
      candidate routes.  Then, GB information should be considered in
      the routing and slot assignment.

5.3.  GMPLS Requirements

5.3.1.  OSPF-TERequirements

      - Stateful PCE: the LSP-DB is not filled through OSPF-TE, thus no
      OSPF-TE extension is required.

      - Stateless PCE: the TED may be filled through OSPF-TE, thus
      OSPF-TE extensions may be required to carry used frequency slot
      information, such as the associated bit-rate B and modulation
      format M.

5.3.2.  RSVP-TE Requirements

   If the PCE only provides the ingress node with a route (IV PCE and IV
   candidate path PCE), the slot assignment is performed at the egress
   node.  To this aim, RSVP-TE Path message gathers frequency range slot
   availability information along the route.

      - IV&RSA PCE: no extensions for GB are required by RSVP-TE

      - IV PCE: extensions to RSVP-TE may be required to enable
      distributed RSA process which accounts for GB.  In particular,
      extensions to RSVP-TE may be required to identify the frequency
      spectrum along the route that should be not selected because of
      GB.

      - IV candidate path PCE: extensions to RSVP-TE may be required to
      enable distributed RSA process which accounts for GB.  In
      particular, extensions to RSVP-TE may be required to identify
      frequency spectrum along the route that should be not selected



Ceccarelli, et al.      Expires September 6, 2012               [Page 7]


Internet-Draft       Guard bands in optical networks          March 2012


      because of GB.


6.  Security Considerations

   TBD


7.  IANA Considerations

   TBD


8.  Contributors

      Fabio Cavaliere, Ericsson

      Email: fabio.cavalier@ericsson.com



      Paola Iovanna, Ericsson

      Email: paola.iovanna@ericsson.com



      Piero Castoldi, Scuola Superiore S.Anna

      EMail: castoldi@sssup.it


9.  Acknowledgements


10.  References

10.1.  Normative References

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

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





Ceccarelli, et al.      Expires September 6, 2012               [Page 8]


Internet-Draft       Guard bands in optical networks          March 2012


10.2.  Informative References

   [G.694.1v1]
              ITU-T, "Spectral grids for WDM applications: DWDM
              frequency grid", G.694.1 Recommendation (v1),
              December 2011.

   [draft-flexible]
              F.Zhang, Y.Lee, O. Gonzales de Dios, R.Casellas,
              D.Ceccarelli, "Framework for GMPLS Control of Spectrum
              Switched Optical Networks, work in progress
              draft-zhang-ccamp-sson-framework-00", March 2011.

   [sambo-jlt]
              Sambo, N.; Secondini, M.; Cugini, F.; Bottari, G.;
              Iovanna, P.; Cavaliere, F.; Castoldi, P, "Modeling and
              Distributed Provisioning in 10-40-100-Gb/s Multirate
              Wavelength Switched Optical Networks, Lightwave
              Technology, Journal of , vol.29, no.9, pp.1248-1257",
              May 2011.


Authors' Addresses

   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com


   Giulio Bottari
   Ericsson
   Via G.Moruzzi, 1
   Pisa
   Italy

   Email: giulio.bottari@ericsson.com











Ceccarelli, et al.      Expires September 6, 2012               [Page 9]


Internet-Draft       Guard bands in optical networks          March 2012


   Nicola Sambo
   Scuola Superiore S.Anna
   Via G.Moruzzi, 1
   Pisa
   Italy

   Email: nicola.sambo@sssup.it


   Cugini
   C.N.I.T.
   Via G.Moruzzi, 1
   Pisa
   Italy

   Email: filippo.cugini@cnit.it


   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129 P.R.China  Bantian, Longgang District
   Phone: +86-755-28972912

   Email: zhangfatai@huawei.com


   Ramos Casellas
   CTTC
   Av. Carl Friedrich Gauss, 7
   Castelldefels
   Spain

   Email: ramon.casellas@cttc.es

















Ceccarelli, et al.      Expires September 6, 2012              [Page 10]