One document matched: draft-ietf-ccamp-flexi-grid-fwk-01.xml


<?xml version="1.0" encoding="iso-8859-1"?>
<!-- 
     vim: set softtabstop=2 shiftwidth=2 expandtab
     RCAS: uploaded version
     version=201302121230
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml">
<!ENTITY RFC4206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4206.xml">
<!ENTITY RFC4397 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4397.xml">
<!ENTITY RFC5150 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5150.xml">
<!ENTITY RFC6163 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml">
]>


<rfc category="std" docName="draft-ietf-ccamp-flexi-grid-fwk-01" ipr="trust200902" >
  <front>
    <title abbrev="GMPLS Flexi-grid Framework">Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks</title>

    <author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios">
      <organization>Telefonica I+D</organization>
      <address>
        <postal>
          <street>Don Ramon de la Cruz 82-84</street>
          <city>Madrid</city>
          <region></region>
          <code>28045</code>
          <country>Spain</country>
        </postal>
        <phone>+34913128832</phone>
        <email>ogondio@tid.es</email>
      </address>
    </author>

    <author fullname="Ramon Casellas" initials="R." role="editor" surname="Casellas">
      <organization>CTTC</organization>
      <address>
        <postal>
          <street>Av. Carl Friedrich Gauss n.7</street>
          <city>Castelldefels</city>
          <region></region>
          <code>Barcelona</code>
          <country>Spain</country>
        </postal>
        <phone>+34 93 645 29 00</phone>
        <email>ramon.casellas@cttc.es</email>
      </address>
    </author>

    <author fullname="Fatai Zhang" initials="F."  surname="Zhang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Huawei Base, Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <region></region>
          <code>518129</code>
          <country>China</country>
        </postal>
        <phone>+86-755-28972912</phone>
        <email>zhangfatai@huawei.com</email>
      </address>
    </author>

    <author fullname="Xihua Fu" initials="X"  surname="Fu">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street>Ruanjian Avenue</street>
          <city>Nanjing</city>
          <region></region>
          <code></code>
          <country>China</country>
        </postal>
        <email>fu.xihua@zte.com.cn</email>
      </address>
    </author> 

    <author fullname="Daniele Ceccarelli" initials="D."  surname="Ceccarelli">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Via Calda 5</street>
          <city>Genova</city>
          <region></region>
          <code></code>
          <country>Italy</country>
        </postal>
        <phone>+39 010 600 2512</phone>
        <email>daniele.ceccarelli@ericsson.com</email>
      </address>
    </author>

    <author fullname="Iftekhar Hussain" initials="I." surname="Hussain">
      <organization>Infinera</organization>
      <address>
        <postal>
          <street>140 Caspian Ct.</street>
          <city>Sunnyvale</city>
          <region></region>
          <code>94089</code>
          <country>USA</country>
        </postal>
        <phone>408-572-5233</phone>
        <email> ihussain@infinera.com</email>
      </address>
    </author>


    <date year="2014" />
    <area>Routing</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>DWDM</keyword>
    <keyword>flexi-grid</keyword>
    <keyword>GMPLS</keyword>

    <abstract>
      <t>This document defines a framework and the associated control plane
        requirements for the GMPLS based control of flexi-grid DWDM networks.
        To allow efficient allocation of optical spectral bandwidth for high
        bit-rate systems, the International Telecommunication Union
        Telecommunication Standardization Sector (ITU-T) has extended the
        recommendations <xref target="G.694.1"/> and <xref target="G.872"/> to
        include the concept of flexible grid. A new DWDM grid has been
        developed within the ITU-T Study Group 15 by defining a set of nominal
        central frequencies, channel spacings and the concept of
        "frequency slot". In such environment, a data plane connection is
        switched based on allocated, variable-sized frequency ranges within 
        the optical spectrum.</t>
    </abstract>
</front>

<middle>
  <!-- ===================================================================
         Requirements Language
       =================================================================== -->
  <section title ="Requirements Language">
    <t> 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 <xref target="RFC2119"/>.
    </t>
  </section>


  <!-- ===================================================================
       Introduction
       =================================================================== -->
  <section title="Introduction">

    <t>The term "Flexible grid" (flexi-grid for short) as defined by the
      International Telecommunication Union Telecommunication Standardization
      Sector (ITU-T) Study Group 15 in the latest version of <xref
        target="G.694.1"/>, refers to the updated set of nominal central
      frequencies (a frequency grid), channel spacing and optical spectrum
      management/allocation considerations that have been defined in order to
      allow an efficient and flexible allocation  and configuration of optical
      spectral bandwidth for high bit-rate systems.</t>

    <t>A key concept of flexi-grid is the "frequency slot"; a variable-sized
      optical frequency range that can be allocated to a data connection. As
      detailed later in the document, a frequency slot is characterized by its
      nominal central frequency and its slot width which, as per  <xref
        target="G.694.1"/>, is constrained to be a multiple of a given slot
      width granularity.</t>

    <t>Compared to a traditional fixed grid network, which uses fixed size
      optical spectrum frequency ranges or "frequency slots" with typical
      channel separations of 50 GHz, a flexible grid network can select
      its media channels with a more flexible choice of slot widths,
      allocating as much optical spectrum as required, allowing high bit rate signals
      (e.g., 400G, 1T or higher) that do not fit in the fixed grid. </t>

    <t>From a networking perspective, a flexible grid network is assumed to be
      a layered network <xref target="G.872"/><xref target="G.800"/> in which
      the media layer is the server layer and the optical signal layer is the
      client layer. In the media layer, switching  is based on a frequency
      slot, and the size of a media channel is given by the properties of the
      associated frequency slot. In this layered network, the media channel
      transports an Optical Tributary Signal.</t>

    <t>A Wavelength Switched Optical Network (WSON), addressed in <xref
        target="RFC6163"/>, is a term commonly used to refer to the
      application/deployment of a Generalized Multi-Protocol Label Switching
      (GMPLS)-based control plane for the control (provisioning/recovery, etc)
      of a fixed grid WDM network in which media (spectrum) and signal are jointly considered</t> 

    <t>This document defines the framework for a GMPLS-based control of
      flexi-grid enabled DWDM networks (in the scope defined by ITU-T layered
      Optical Transport Networks <xref target="G.872"/>), as well as a set
      of associated control plane requirements. An important design
      consideration relates to the decoupling of the management of the optical
      spectrum resource and the client signals to be transported. </t>


  </section>

<!-- ===================================================================
       Acronyms
     =================================================================== -->
  <section title="Acronyms">
    <t>EFS: Effective Frequency Slot</t>
    <t>FS: Frequency Slot</t>
    <t>NCF: Nominal Central Frequency</t>
    <t>OCh: Optical Channel</t>
    <t>OCh-P: Optical Channel Payload</t>
    <t>OTS: Optical Tributary Signal</t>
    <t>OCC: Optical Channel Carrier</t>
    <t>SWG: Slot Width Granularity</t>

  </section>


<!-- ===================================================================
         Terminology
     =================================================================== -->
  <section title="Flexi-grid Networks">
    <section title="Flexi-grid in the context of OTN">
      <t> <xref target="G.872"/> describes from a network level the functional
        architecture of Optical Transport Networks (OTN). The OTN is
        decomposed into independent layer networks with client/layer
        relationships among them. A simplified view of the OTN layers is shown
        in <xref target="generic_otn_overview"/>.</t>

      <figure anchor="generic_otn_overview" title="Generic OTN overview">
       <artwork><![CDATA[
                              +----------------+
                              | Digital Layer  |
                              +----------------+ 
                              | Signal Layer   |
                              +----------------+
                              |  Media Layer   |
                              +----------------+
      ]]></artwork>
  </figure>    

      <t>In the OTN layering context, the media layer is the server layer of
        the optical signal layer. The optical signal is guided to its
        destination by the media layer by means of a network media channel. In
        the media layer, switching  is based on a frequency slot, and the size
        of a media channel is given by the properties of the associated
        frequency slot. </t>

    <t>In this scope, this document uses the term flexi-grid enabled DWDM
      network to refer to a network in which switching is based on frequency
      slots defined using the flexible grid, and covers mainly the Media Layer
      as well as the required adaptations from the Signal layer. The present
      document is thus focused on the control and management of the media
      layer.</t>

  </section>  


  <section title="Terminology">
    <t>This section presents the definition of the terms used in flexi-grid
      networks. These terms are included in the ITU-T recommendations <xref target="G.694.1"/>,
      <xref target="G.872"/>), <xref target="G.870"/>, <xref
        target="G.8080"/> and <xref target="G.959.1-2013"/>.</t> 

    <t>Where appropriate, this documents also uses terminology and lexicography
      from <xref target="RFC4397"/>.</t>

    <section title="Frequency Slots">
      <t>This subsection is focused on the frequency slot related terms.
        <list style="symbols">
          <t>Frequency Slot <xref target="G.694.1"/>: The frequency range
            allocated to a slot within the flexible grid and unavailable to
            other slots.  A frequency slot is defined by its nominal central
            frequency and its slot width. </t>
        </list>
      </t>

      <t>Nominal Central Frequency: each of the allowed frequencies as per the
        definition of flexible DWDM grid in  <xref target="G.694.1"/>. The set
        of nominal central frequencies can be built using the following
        expression f = 193.1 THz + n x 0.00625 THz, where 193.1 THz is ITU-T
        ''anchor frequency'' for transmission over the C band, n is a positive
        or negative integer including 0.

        <figure anchor="anchor_frequency" title="Anchor frequency and set of nominal central frequencies">
          <artwork> <![CDATA[
   -5 -4 -3 -2 -1  0  1  2  3  4  5     <- values of n
 ...+--+--+--+--+--+--+--+--+--+--+-
                   ^ 
                   193.1 THz <- anchor frequency ]]>
                 </artwork>
        </figure>
      </t>
      <t>Nominal Central Frequency Granularity: It is the spacing between allowed
        nominal central frequencies and it is set to 6.25 GHz (note: sometimes
        referred to as 0.00625 THz).</t>

      <t>Slot Width Granularity: 12.5 GHz, as defined in <xref
          target="G.694.1"/>.</t>

      <t>Slot Width: The slot width determines the "amount" of optical
        spectrum regardless of its actual "position" in the frequency axis. A
        slot width is constrained to be m x SWG (that is, m x 12.5 GHz),
          where m is an integer greater than or equal to 1.</t>
        <figure anchor="example_frequency_slots" title="Example Frequency slots">
            <artwork>
              <![CDATA[
      Frequency Slot 1     Frequency Slot 2 
       -------------     -------------------  
       |           |     |                 |  
   -3 -2 -1  0  1  2  3  4  5  6  7  8  9 10 11     
..--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--... 
       -------------     ------------------- 
             ^                    ^ 
     Central F = 193.1THz    Central F = 193.14375 THz 
     Slot width = 25 GHz     Slot width = 37.5 GHz 
          ]]>
            </artwork>
        </figure> 

        <t><list style="symbols">
           <t>The symbol '+' represents the allowed nominal central frequencies,
          the '--' represents the nominal central frequency granularity, and
          the '^' represents the slot nominal central frequency. The number on
          the top of the '+' symbol represents the 'n' in the frequency
          calculation formula. The nominal central frequency is 193.1 THz when
          n equals zero. </t> 
        </list></t>
        
        <t>Effective Frequency Slot: the effective frequency slot of a media
          channel is the common part of the frequency slots along the media
          channel through a particular path through the optical network.  It is
          a logical construct derived from the (intersection of) frequency
          slots allocated to each device in the path. The effective frequency
          slot is an attribute of a media channel and, being a frequency slot,
          it is described by its nominal central frequency and slot width,
          according to the already described rules.</t>

          <figure anchor="effective_frequency_slot" title="Effective Frequency Slot">
            <artwork>
              <![CDATA[
                     Frequency Slot 1   
             -------------    
             |           |    
   -3 -2 -1  0  1  2  3  4  5  6  7  8  9 10 11     
   ..--+--+--+--+--X--+--+--+--+--+--+--+--+--+--+--+--... 

          Frequency Slot 2 
          -------------------
          |                 |
   -3 -2 -1  0  1  2  3  4  5  6  7  8  9 10 11     
   ..--+--+--+--+--X--+--+--+--+--+--+--+--+--+--+--+--... 

=============================================== 
        Effective Frequency Slot 
             -------------
             |           |
   -3 -2 -1  0  1  2  3  4  5  6  7  8  9 10 11     
   ..--+--+--+--+--X--+--+--+--+--+--+--+--+--+--+--+--... 
          ]]>
            </artwork>
          </figure>  

    </section>   

    <section title="Media Channels"> 

      <t>Media Channel: a media association that represents both the
        topology (i.e., path through the media) and the resource (frequency
        slot) that it occupies. As a topological construct, it represents a
        (effective) frequency slot supported by a concatenation of media
        elements (fibers, amplifiers, filters, switching matrices...). This
        term is used to identify the end-to-end physical layer entity with
        its corresponding (one or more) frequency slots local at each link
        filters.</t> 

      <t>Network Media Channel: It is a media channel that transports an
        Optical Tributary Signal [Editor's note: this definition goes beyond
        current G.870 definition, which is still tightened to a particular case
        of OTS, the OCh-P]</t>

    </section>

     <section title="Media Layer Elements"> 
      <t>Media Element: a media element only directs the optical signal or
        affects the properties of an optical signal, it does not modify the
        properties of the information that has been modulated to produce the
        optical signal <xref target="G.870"/>. Examples of media elements include fibers,
        amplifiers, filters and switching matrices.</t>
        <t>Media Channel Matrixes: the media channel matrix provides flexible
        connectivity for the media channels. That is, it represents a point
        of flexibility where relationships between the media ports at the
        edge of a media channel matrix may be created and broken. The
        relationship between these ports is called a matrix channel.
        (Network) Media Channels are switched in a Media Channel
        Matrix.</t> 
    </section>

    <section title="Optical Tributary Signals"> 
       <t>Optical Tributary Signal <xref target="G.959.1-2013"/>: The optical
        signal that is placed within a network media channel for transport
        across the optical network. This may consist of a single modulated
        optical carrier or a group of modulated optical carriers or
        subcarriers. One particular example of Optical Tributary Signal is an
        Optical Channel Payload (OCh-P) <xref target="G.872"/>.</t>
    </section>
     
  </section>  


  <section title="Flexi-grid layered network model">
    <t>In the OTN layered network, the network media channel transports a single
      Optical Tributary Signal (see <xref target="simple_layered_network_model"/>)</t>
      

    <figure anchor="simple_layered_network_model" title="Simplified Layered Network Model">
      <artwork><![CDATA[

  |                     Optical Tributary Signal                    |
  O - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O
  |                                                                 |
  | Channel Port         Network Media Channel         Channel Port |
  O - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O
  |                                                                 |
+--------+                 +-----------+                   +--------+
|  \ (1) |                 |    (1)    |                   | (1)  / |
|   \----|-----------------|-----------|-------------------|-----/  |
+--------+ Link Channel    +-----------+  Link Channel     +--------+
  Media Channel            Media Channel                Media Channel
  Matrix                   Matrix                       Matrix

(1) - Matrix Channel
      ]]></artwork>
  </figure>          

  <t>A particular example of Optical Tributary Signal is the OCh-P. Figure
    <xref target="layered_network_model"/> shows the example of the layered
    network model particularized for the OCH-P case, as defined in G.805.</t>

      <figure anchor="layered_network_model" title="Layered Network Model according to G.805">
        <artwork><![CDATA[
 OCh AP                     Trail (OCh)                    OCh AP
  O- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O
  |                                                              |
 --- OCh-P                                                OCh-P ---
 \ / source                                               sink  \ /
  +                                                              +
  | OCh-P               OCh-P Network Connection           OCh-P |
  O TCP - - - - - - - - - - - - - - - - - - - - - - - - - - -TCP O
  |                                                              |
  |Channel Port          Network Media Channel      Channel Port |
  O - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  O
  |                                                              |
+--------+                 +-----------+                 +---------+
|  \ (1) |  OCh-P LC       |    (1)    |  OCh-P LC       |  (1)  / |
|   \----|-----------------|-----------|-----------------|------/  |
+--------+ Link Channel    +-----------+  Link Channel   +---------+
Media Channel              Media Channel                Media Channel
  Matrix                     Matrix                        Matrix

(1) - Matrix Channel
      ]]></artwork>
  </figure>          

    <t>By definition a network media channel only supports a single Optical
    Tributary signal. How several Optical Tributary signals are bound together
    is out of the scope of the present document and is a matter of the signal
    layer.</t>

    <section title="Hierarchy in the Media Layer">    
        <t>In summary, the concept of frequency slot is a logical abstraction
        that represents a frequency range while the media layer represents the
        underlying media support. Media Channels are media associations,
        characterized by their (effective) frequency slot, respectively; and
        media channels are switched in media channel matrixes. 
        From the control and management perspective, a media channel can
        be logically splited in other media channels. </t>

         <t>In <xref target="media_channel_example"/> , a Media Channel has been
        configured and dimensioned to support two network media channels, each of 
        them carrying one optical tributary signal.  </t>

          <figure anchor="media_channel_example" title="Example of Media Channel / Network Media Channels and associated frequency slots">
            <artwork>
              <![CDATA[

                         Media Channel Frequency Slot 
 +-------------------------------X------------------------------+
 |                                                              |
 |       Frequency Slot                  Frequency Slot         |
 |   +------------X-----------+      +----------X-----------+   |
 |   | Opt Tributary Signal  |       | Opt Tributary Signal |   |
 |   |           o           |       |          o           |   |
 |   |           |           |       |          |           |   |
-4  -3  -2  -1   0   1   2   3   4   5   6   7  8   9  10  11  12  
 +---+---+---+---+---+---+---+---+---+---+---+--+---+---+---+---+--- 

      <- Network Media Channel->     <- Network Media Channel->

  <------------------------ Media Channel ----------------------->

     X - Frequency Slot Central Frequency

     o - signal central frequency
        ]]>
            </artwork>
          </figure>          
      </section>
<!-- ===================================================================
           Network element models
     =================================================================== -->

  <section title="DWDM flexi-grid enabled network element models">

    <t>Similar to fixed grid networks, a flexible grid network is also
      constructed from subsystems that include Wavelength Division Multiplexing
      (WDM) links, tunable transmitters and receivers, i.e, media elements
      including media layer switching elements (media matrices), as well as
      electro-optical network elements, all of them with flexible grid
      characteristics.</t>

    <t>As stated in <xref target="G.694.1"/> the flexible DWDM grid defined in
      Clause 7 has a nominal central frequency granularity of 6.25 GHz and a
      slot width granularity of 12.5 GHz. However, devices or applications that
      make use of the flexible grid may not be capable of supporting every
      possible slot width or position. In other words, applications may be
      defined where only a subset of the possible slot widths and positions are
      required to be supported.  For example, an application could be defined
      where the nominal central frequency granularity is 12.5 GHz (by only
      requiring values of n that are even) and that only requires slot widths
      as a multiple of 25 GHz (by only requiring values of m that are
      even).</t>
       </section>
  </section>

</section>





 
<!-- ===================================================================
         GMPLS applicability
     =================================================================== -->
  <section title="GMPLS applicability">

    <t>The goal of this section is to provide an insight of the application of
      GMPLS to control flexi-grid networks, while specific requirements are
      covered in the next section. The present framework is aimed at
      controlling the media layer within the Optical Transport Network (OTN)
      hierarchy and the required adaptations of the signal layer. This document
      also defines the term SSON (Spectrum-Switched Optical Network) to refer
      to a Flexi-grid enabled DWDM network that is controlled by a GMPLS/PCE
      control plane.</t> 

    <t>This section provides a mapping of the ITU-T G.872 architectural aspects
      to GMPLS/Control plane terms, and considers the relationship between the
      architectural concept/construct of media channel and its control plane
      representations (e.g. as a TE link). </t>

    <section title="General considerations">
      <t>The GMPLS control of the media layer deals with the establishment of
        media channels, which are switched in media channel matrixes. GMPLS
        labels locally represent the media channel and its associated frequency
        slot. Network media channels are considered a particular case of media
        channels when the end points are transceivers (that is, source and
        destination of an Optical Tributary Signal)</t>
    </section>


    <section title="Considerations on TE Links">
    <t>From a theoretical / abstract point of view, a fiber can be modeled has
      having a frequency slot that ranges from (-inf, +inf). This representation
      helps understand the relationship between frequency slots / ranges.</t>

    <t>The frequency slot is a local concept that applies locally to a
      component / element. When applied to a media channel, we are referring to its
      effective frequency slot as defined in <xref target="G.872"/>.</t>

    <t>The association of a filter, a fiber and a filter is a media channel in
      its most basic form, which from the control plane perspective may modeled
      as a (physical) TE-link with a contiguous optical spectrum at start of
      day. A means to represent this is that the portion of spectrum available
      at time t0 depends on which filters are placed at the ends of the fiber
      and how they have been configured. Once filters are placed we have the
      one hop media channel. In practical terms, associating a fiber with the
      terminating filters determines the usable optical spectrum. </t>

    <t>
      <figure anchor="media_channel_te_link" title="(Basic) Media channel and TE link">
        <artwork>
          <![CDATA[
-----------------+                             +-----------------+
                 |                             |
        +--------+                             +--------+
        |        |                             |        |  +---------
    ---o|        ===============================        o--|
        |        |             Fiber           |        |  | --\  /-- 
    ---o|        |                             |        o--|    \/
        |        |                             |        |  |    /\
    ---o|        ===============================        o--| --/  \--
        | Filter |                             | Filter |  |
        |        |                             |        |  +---------
        +--------+                             +--------+
                 |                             |              
              |------- Basic Media Channel  ---------|
-----------------+                             +-----------------+


      --------+                                      +--------
              |--------------------------------------|
       LSR    |               TE link                |  LSR
              |--------------------------------------|
     +--------+                                      +--------                                                  
          ]]>
        </artwork>
      </figure>          
    </t>


    <t>Additionally, when a cross-connect for a specific frequency slot is
      considered, the underlying media support is still a media channel, augmented,
      so to speak, with a bigger association of media elements and a resulting
      effective slot.  When this media channel is the result of the association of
      basic media channels and media layer matrix cross-connects, this architectural
      construct can be represented as / corresponds to a Label Switched Path (LSP)
      from a control plane perspective.  In other words, It is possible to
      "concatenate" several media channels (e.g.  Patch on intermediate nodes) to
      create a single media channel.</t>

      <figure anchor="media_channel_te_link2" title="Extended Media Channel">
        <artwork>
          <![CDATA[
-----------+       +------------------------------+       +----------
           |       |                              |       |                  
    +------+       +------+                +------+       +------+
    |      |       |      |  +----------+  |      |       |      |
 --o|      =========      o--|          |--o      =========      o--
    |      | Fiber |      |  | --\  /-- |  |      | Fiber |      |
 --o|      |       |      o--|    \/    |--o      |       |      o--
    |      |       |      |  |    /\    |  |      |       |      |
 --o|      =========      o--***********|--o      =========      o--
    |Filter|       |Filter|  |          |  |Filter|       |Filter|
    |      |       |      |                |      |       |      |
    +------+       +------+                +------+       +------+
           |       |                              |       |
       <- Basic Media ->    <- Matrix ->       <- Basic Media-> 
           |Channel|           Channel            |Channel|
-----------+       +------------------------------+       +----------

       <--------------------  Media Channel  ----------------> 
    
  -----+                  +---------------+                  +-------
       |------------------|               |------------------|
  LSR  |       TE link    |       LSR     |   TE link        |   LSR
       |------------------|               |------------------|
  -----+                  +---------------+                  +-------
          ]]>
        </artwork>
      </figure>          


      <t> Additionally, if appropriate, it can also be represented as a TE link
        or Forwarding Adjacency (FA), augmenting the control plane network model. </t>

      <figure anchor="media_channel_te_link3" title="Extended Media Channel / TE Link / FA">
        <artwork>
          <![CDATA[
-----------+       +------------------------------+       +----------
           |       |                              |       |                  
    +------+       +------+                +------+       +------+
    |      |       |      |  +----------+  |      |       |      |
 --o|      =========      o--|          |--o      =========      o--
    |      | Fiber |      |  | --\  /-- |  |      | Fiber |      |
 --o|      |       |      o--|    \/    |--o      |       |      o--
    |      |       |      |  |    /\    |  |      |       |      |
 --o|      =========      o--***********|--o      =========      o--
    |Filter|       |Filter|  |          |  |Filter|       |Filter|
    |      |       |      |                |      |       |      |
    +------+       +------+                +------+       +------+
           |       |                              |       |
-----------+       +------------------------------+       +----------
      
        <------------------------  Media Channel  -----------> 
     
 +-----+                                                      +------
       |------------------------------------------------------| 
 LSR   |                               TE link                |  LSR
       |------------------------------------------------------| 
 +-----+                                                      +------
          ]]>
        </artwork>
      </figure>          
</section>
<section title="Considerations on Labeled Switched Path (LSP) in Flexi-grid">
      <t>The flexi-grid LSP is seen as a control plane representation of a media channel.
        Since network media channels are media channels, an LSP may also be the control
        plane representation of a network media channel, in a particular context. From
        a control plane perspective, the main difference (regardless of the actual
        effective frequency slot which may be dimensioned arbitrarily) is that the LSP
        that represents a network media channel also includes the endpoints
        (transceivers) , including the cross-connects at the ingress / egress nodes.
        The ports towards the client can still be represented as interfaces from the
        control plane perspective.</t>

      <t><xref target="lsp_mchan1"/> describes an LSP routed along 3 nodes.  The LSP is terminated before
        the optical matrix of the ingress and egress nodes and can represent a Media
        Channel.  This case does NOT (and cannot) represent a network media channel as
        it does not include (and cannot include) the transceivers.</t>

      <figure anchor="lsp_mchan1" title="Flex-grid LSP representing a media channel that starts at the filter of the outgoing interface of the ingress LSR and ends at the filter of the incoming interface of the egress LSR">
        <artwork>
          <![CDATA[
----------+       +--------------------------------+       +---------
          |       |                                |       |                  
   +------+       +------+                  +------+       +------+
   |      |       |      |   +----------+   |      |       |      |
 -o|      =========      o---|          |---o      =========      o-
   |      | Fiber |      |   | --\  /-- |   |      | Fiber |      |
 -o|>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>o-
   |      |       |      |   |    /\    |   |      |       |      |
 -o|      =========      o---***********|---o      =========      o-
   |Filter|       |Filter|   |          |   |Filter|       |Filter|
   |      |       |      |                  |      |       |      |
   +------+       +------+                  +------+       +------+
          |       |                                |       |
----------+       +--------------------------------+       +---------

        >>>>>>>>>>>>>>>>>>>>>>>>>>>> LSP >>>>>>>>>>>>>>>>>>>>>>>>
   -----+                  +---------------+                +-----
        |------------------|               |----------------|
   LSR  |       TE link    |     LSR       |      TE link   | LSR
        |------------------|               |----------------|
   -----+                  +---------------+                +----- 
          ]]>
        </artwork>
      </figure>

      <t>In <xref target="lsp_mchan2"/> a Network Media Channel is represented
        as terminated at the DWDM side of the transponder, this is commonly named as
        OCh-trail connection.</t>

      <figure anchor="lsp_mchan2" title="LSP representing a network media channel (OCh-Trail)">
        <artwork>
          <![CDATA[
|--------------------- Network Media Channel ----------------------|

     +----------------------+           +----------------------+
     |                                  |                      |
     +------+        +------+           +------+        +------+
     |      | +----+ |      |           |      | +----+ |      |OCh-P
OCh-P|      o-|    |-o      |  +-----+  |      o-|    |-o      |sink
 src |      | |    | |      ===+-+ +-+==|      | |    | |      O---|R
T|***o******o******************************************************** 
     |      | |\  /| |         | | | |  |      | |\  /| |      |
     |      o-| \/ |-o      ===| | | |==|      o-| \/ |-o      |
     |      | | /\ | |      |  +-+ +-+  |      | | /\ | |      |
     |      o-|/  \|-o      |  |  \/ |  |      o-|/  \|-o      |
     |Filter| |    | |Filter|  |  /\ |  |Filter| |    | |Filter|
     +------+ |    | +------+  +-----+  +------+ |    | +------+
     |        |    |        |           |        |    |        |
     +----------------------+           +----------------------+
                                   LSP 
<------------------------------------------------------------------->

                                   LSP 
 <------------------------------------------------------------------>
      +-----+                   +--------+                +-----+
 o--- |     |-------------------|        |----------------|     |---o
      | LSR |       TE link     |  LSR   |   TE link      | LSR |
      |     |-------------------|        |----------------|     |
      +-----+                   +--------+                +-----+ 
          ]]>
        </artwork>
      </figure>

      <t>In a third case, a Network Media Channel terminated on the Filter
        ports of the Ingress and Egress nodes. This is named in G.872 as OCh-NC (we
        need to discuss the implications, if any, once modeled at the control plane
        level of models B and C).</t>

      <figure anchor="lsp_mchan3" title="LSP representing a network media channel (OCh-P NC)">
        <artwork>
          <![CDATA[
  |---------------------  Network Media Channel --------------------|
 
  +------------------------+               +------------------------+
  +------+        +------+                 +------+          +------+
  |      | +----+ |      |                 |      | +----+ |      |
  |      o-|    |-o      |    +------+     |      o-|    |-o      |
  |      | |    | |      =====+-+  +-+=====|      | |    | |      |
T-o******o********************************************************O-R
  |      | |\  /| |           | |  | |     |      | |\  /| |      |
  |      o-| \/ |-o      =====| |  | |=====|      o-| \/ |-o      |
  |      | | /\ | |      |    +-+  +-+     |      | | /\ | |      |
  |      o-|/  \|-o      |    |  \/  |     |      o-|/  \|-o      |
  |Filter| |    | |Filter|    |  /\  |     |Filter| |    | |Filter|
  +------+ |    | +------+    +------+     +------+ |    | +------+
  |        |    |        |                 |        |    |        |
  +----------------------+                 +----------------------+
  <----------------------------------------------------------------->
                                 LSP
 
                                  LSP 
  <-------------------------------------------------------------->
   +-----+                    +--------+                   +-----+
o--|     |--------------------|        |-------------------|     |--o
   | LSR |       TE link      |  LSR   |      TE link      | LSR |
   |     |--------------------|        |-------------------|     |
   +-----+                    +--------+                   +-----+ 
          ]]>
        </artwork>
      </figure>
      <t>[Note: not clear the difference, from a control plane perspective,
        of figs <xref target="lsp_mchan2"/> and <xref target="lsp_mchan3"/>.]
      </t>

      <t>Applying the notion of hierarchy at the media layer, by using the LSP as a FA, the media channel created can support multiple (sub) media channels.  [Editot note : a specific behavior related to Hierarchies will be verified at a later point in time].
        <figure anchor="mrn_mln_topology_view" title="MRN/MLN topology view with TE link / FA">
          <artwork>
            <![CDATA[
+--------------+                      +--------------+
|    OCh-P     |           TE         |     OCh-P    |  Virtual TE 
|              |          link        |              |    link
|    Matrix    |o- - - - - - - - - - o|    Matrix    |o- - - - - -  
+--------------+                      +--------------+
               |     +---------+      |
               |     |  Media  |      |
               |o----| Channel |-----o|
                     |         | 
                     | Matrix  | 
                     +---------+
          ]]>
        </artwork>
      </figure>          
    </t>

    <t>Note that there is only one media layer switch matrix (one
      implementation is FlexGrid ROADM) in SSON, while "signal layer LSP is
      mainly for the purpose of management and control of individual optical
      signal". Signal layer LSPs (OChs) with the same attributions (such as
      source and destination) could be grouped into one media-layer LSP
      (media channel), which has advantages in spectral efficiency
      (reduce guard band between adjacent OChs in one FSC) and LSP management.
      However, assuming some network elements indeed perform signal layer
      switch in SSON, there must be enough guard band between adjacent OChs in
      one media channel, in order to compensate filter concatenation
      effect and other effects caused by signal layer switching elements. In
      such condition, the separation of signal layer from media layer cannot
      bring any benefit in spectral efficiency and in other aspects, but make
      the network switch and control more complex.  If two OChs must switch to
      different ports, it is better to carry them by diferent FSCs and the
      media layer switch is enough in this scenario. </t>
    </section>







    <section title="Control Plane modeling of Network elements">
      <!-- TO BE REWRITTEN M-->
      <t> Optical transmitters/receivers may have different tunability
        constraints, and media channel matrixes may have switching
        restrictions. Additionally, a key feature of their implementation is
        their highly asymmetric switching capability which is described in
        <xref target="RFC6163"/> in detail.  Media matrices include line side
        ports which are connected to DWDM links and tributary side input/output
        ports which can be connected to transmitters/receivers.</t>
        
      <t>A set of common constraints can be defined:
        <list style="symbols"> 
          <t>The minimum and maximum slot width.</t>

          <t>Granularity: the optical hardware may not be able to select
            parameters with the lowest granularity (e.g. 6.25 GHz for nominal
            central frequencies or 12.5 GHz for slot width granularity).</t>

          <t>Available frequency ranges: the set or union of frequency ranges
            that are not allocated (i.e. available).  The relative grouping and
            distribution of available frequency ranges in a fiber is usually
            referred to as ''fragmentation''. </t>

          <t>Available slot width ranges: the set or union of slot width ranges
            supported by media matrices. It includes the following information.

            <list style="symbols"> 
              <t>Slot width threshold: the minimum and maximum Slot Width supported
                by the media matrix.  For example, the slot width can be from 50GHz to
                200GHz.</t>

              <t>Step granularity: the minimum step by which the optical filter
                bandwidth of the media matrix can be increased or decreased. This parameter is
                typically equal to slot width granularity (i.e. 12.5GHz) or integer
                multiples of 12.5GHz.</t>
            </list>
          </t>
        </list>
      </t>

      <t>[Editor's note: different configurations such as C/CD/CDC will be
        added later. This section should state specifics to media channel
        matrices, ROADM models need to be moved to an appendix].
      </t>

   
  </section>

 <section title="Media Layer Resource Allocation considerations">
    
      <t>A media channel has an associated effective frequency slot. From the
        perspective of network control and management, this effective slot is seen as
        the "usable" frequency slot end to end. The establishment of an LSP related the
        establishment of the media channel and effective frequency slot.</t>

      <t>In this context, when used unqualified, the frequency slot is a local
        term, which applies at each hop.  An effective frequency slot applies at the
        media chall (LSP) level</t>

      <t>A "service" request is characterized as a minimum, by its required
        effective slot width.  This does not preclude that the request may
        add additional constraints such as imposing also the nominal central
        frequency.  A given frequency slot is requested for the media channel
        say, with the Path message.  Regardless of the actual encoding, the
        Path message sender descriptor sender_tspec shall specify a minimum
        frequency slot width that needs to be fulfilled.</t>

      <t>In order to allocate a proper effective frequency slot for a LSP, the
        signaling should specify its required slot width.</t>

      <t>An effective frequency slot must equally be described in terms of a
        central nominal frequency and its slot width (in terms of usable spectrum of
        the effective frequency slot). That is, one must be able to obtain an
        end-to-end equivalent n and m parameters. We refer to this as the "effective
        frequency slot of the media channel/LSP must be valid".</t>

      <t>In GMPLS the requested effective frequency slot is represented to the
        TSpec and the effective frequency slot is mapped to the FlowSpec.</t> 

      <t>The switched element corresponds in GMPLS to the 'label'. As in
        flexi-grid the switched element is a frequency slot, the label
        represents a frequency slot. Consequently, the label in flexi-grid must
        convey the necessary information to obtain the frequency slot
        characteristics (i.e, center and width, the n and m parameters). The
        frequency slot is locally identified by the label</t>

      <t>The local frequency slot may change at each hop, typically given
        hardware constraints (e.g. a given node cannot support the finest
        granularity). Locally n and m may change. As long as a given downstream
        node allocates enough optical spectrum, m can be different along the
        path. This covers the issue where concrete media matrices can have
        different slot width granularities. Such "local" m will appear in the
        allocated label that encodes the frequency slot as well as the flow
        descriptor flowspec.</t>

      <t>Different modes are considered: RSA with explicit label control, and
        for R+DSA, the GMPLS signaling procedure is similar to the one described in
        section 4.1.3 of <xref target="RFC6163"/> except that the label set should
        specify the available nominal central frequencies that meet the slot width
        requirement of the LSP.  The intermediate nodes can collect the
        acceptable central frequencies that meet the slot width requirement hop by hop.
        The tail-end node also needs to know the slot width of a LSP to assign the
        proper frequency resource. Compared with <xref target="RFC6163"/>, except
        identifying the resource (i.e., fixed wavelength for WSON and frequency
        resource for flexible grids), the other signaling requirements (e.g.,
        unidirectional or bidirectional, with or without converters) are the same as
        WSON described in the section 6.1 of <xref target="RFC6163"/>. </t>

      <t>Regarding how a GMPLS control plane can assign n and m, different cases can apply:
        <list>
          <t>a) n and m can both change. It is the effective slot what matters.
            Some entity needs to make sure the effective frequency slot remains valid.</t>
          <t>b) m can change; n needs to be the same along the path. This
            ensures that the nominal central frequency stays the same.</t>
          <t>c) n and m need to be the same. </t>
          <t>d)n can change, m needs to be the same.</t>
        </list>
      </t>

      <t>In consequence, an entity such as a PCE can make sure that the n and m
        stay the same along the path. Any constraint (including frequency slot and
        width granularities) is taken into account during path computation.
        alternatively, A PCE (or a source node) can compute a path and the actual
        frequency slot assignment is done, for example, with a distributed (signaling)
        procedure: 
        <list>
          <t>Each downstream node ensures that m is >= requested_m. </t>

          <t>Since a downstream node cannot foresee what an upstream node will
            allocate in turn, a way we can ensure that the effective frequency slot is
            valid is then by ensuring that the same "n" is allocated. By forcing the same
            n, we avoid cases where the effective frequency slot of the media
            channel is invalid (that is, the resulting frequency slot cannot be described
            by its n and m parameters). </t>

          <t>Maybe this is a too hard restriction, since a node (or even a
            centralized/combined RSA entity) can make sure that the resulting end to end
            (effective) frequency slot is valid, even if n is different locally. That
            means, the effective (end to end) frequency slot that characterizes the
            media channel is one and determined by its n and m, but are logical,
            in the sense that they are the result of the intersection of local (filters)
            freq slots which may have different freq. slots </t>
        </list>
      </t>

      <t>For Figure <xref target="effslot1"/> the effective slot is valid by
        ensuring that the minimum m is greater than the requested m.  The effective
        slot (intersection) is the lowest m (bottleneck).</t>

      <t>For Figure <xref target="effslot2"/> the effective slot is valid by
        ensuring that it is valid at each hop in the upstream direction. The
        intersection needs to be computed. Invalid slots could result otherwise. 
      
        <figure anchor="effslot1" title="Distributed allocation with different m and same n">
          <artwork>
            <![CDATA[
          |Path(m_req)   |                ^                |
          |--------->    |                #                |
          |              |                #                ^  
         -^--------------^----------------#----------------#--
Effective #              #                #                #
FS n, m   # . . . . . . .#. . . . . . . . # . . . . . . . .# <-fixed
          #              #                #                #   n
         -v--------------v----------------#----------------#---
          |              |                #                v
          |              |                #          Resv  |
          |              |                v        <------ |
          |              |                |flowspec(n, m_a)|
          |              |       <--------|                |
          |              |  flowspec (n,  |                     
                <--------|      min(m_a, m_b))
          flowspec (n,  |                   
            min(m_a, m_b, m_c))
            ]]>
          </artwork>
        </figure>
             
        <figure anchor="effslot2" title="Distributed allocation with different m and different n">
          <artwork>
            <![CDATA[
          |Path(m_req)  ^                | 
          |--------->   #                |                 |
          |             #                ^                 ^  
         -^-------------#----------------#-----------------#--------
Effective #             #                #                 #
FS n, m   #             #                #                 # 
          #             #                #                 # 
         -v-------------v----------------#-----------------#--------
          |             |                #                 v
          |             |                #           Resv  |
          |             |                v         <------ |
          |             |                |flowspec(n_a, m_a) 
          |             |       <--------|                 |
          |             |  flowspec (FSb [intersect] FSa)
               <--------|        
         flowspec ([intersect] FSa,FSb,FSc)
            ]]>
          </artwork>
        </figure>

      
      
      
      </t>

      <t>Note, when a media channel is bound to one OCh-P (i.e is a Network
        media channel), the EFS  must be the one of the Och-P. The media channel setup
        by the LSP may contains the EFS of the network media channel EFS. This is an
        endpoint property, the egress and ingress SHOULD constrain the EFS to Och-P EFS
        .</t>

  
    </section>

    <section title="Neighbor Discovery and Link Property Correlation">
      <t>Potential interworking problems between fixed-grid DWDM and
        flexible-grid DWDM nodes, may appear. Additionally, even two
        flexible-grid optical nodes may have different grid properties, leading
        to link property conflict.</t> 

      <t>Devices or applications that make use of the flexible-grid may not be
        able to support every possible slot width.  In other words,
        applications may be defined where different grid granularity can be
        supported.  Taking node F as an example, an application could be
        defined where the nominal central frequency granularity is 12.5 GHz
        requiring slot widths being multiple of 25 GHz.  Therefore the link
        between two optical nodes with different grid granularity must be
        configured to align with the larger of both granularities.  Besides,
        different nodes may have different slot width tuning ranges.</t>

      <t>In summary, in a DWDM Link between two nodes, at least the following properties
        should be negotiated:
        <list>
          <t>Grid capability (channel spacing) - Between fixed-grid and
            flexible-grid nodes.</t>

          <t>Grid granularity - Between two flexible-grid nodes.</t>

          <t>Slot width tuning range - Between two flexible-grid nodes.</t>
        </list>
      </t>
    </section>


    <section title="Path Computation / Routing and Spectrum Assignment (RSA)">
      <t> Much like in WSON, in which if there is no (available) wavelength
        converters in an optical network, an LSP is subject to the ''wavelength
        continuity constraint'' (see section 4 of <xref target="RFC6163"/>), if
        the capability of shifting or converting an allocated frequency slot, the
        LSP is subject to the Optical ''Spectrum Continuity Constraint''.</t>

      <t>Because of the limited availability of wavelength/spectrum converters
        (sparse translucent optical network) the wavelength/spectrum continuity
        constraint should always be considered. When available, information
        regarding spectrum conversion capabilities at the optical nodes may be
        used by RSA (Routing and Spectrum Assignment) mechanisms.</t>

      <t>The RSA process determines a route and frequency slot for a LSP.
        Hence, when a route is computed the spectrum assignment process (SA)
        should determine the central frequency and slot width based on the slot
        width and available central frequencies information of the transmitter
        and receiver, and the available frequency ranges information and
        available slot width ranges of the links that the route traverses.</t>
          
      <section title="Architectural Approaches to RSA">

        <t>Similar to RWA for fixed grids, different ways of performing RSA in
          conjunction with the control plane can be considered. The approaches
          included in this document are provided for reference purposes only;
          other possible options could also be deployed. </t>

        <section title="Combined RSA (R&SA)">
          <t>In this case, a computation entity performs both routing and
            frequency slot assignment. The computation entity should have the
            detailed network information, e.g.  connectivity topology constructed
            by nodes/links information, available frequency ranges on each link,
            node capabilities, etc. </t> 

          <t>The computation entity could reside either on a PCE or the
            ingress node.</t>
        </section>

        <section title="Separated RSA (R+SA)">
          <t>In this case, routing computation and frequency slot assignment
            are performed by different entities. The first entity computes the
            routes and provides them to the second entity; the second entity
            assigns the frequency slot.</t> 

          <t>The first entity should get the connectivity topology to compute
            the proper routes; the second entity should get the available
            frequency ranges of the links and nodes' capabilities information to
            assign the spectrum.</t>
        </section>

        <section title=" Routing and Distributed SA (R+DSA)">
          <t>In this case, one entity computes the route but the frequency slot
            assignment is performed hop-by-hop in a distributed way along the
            route. The available central frequencies which meet the spectrum
            continuity constraint should be collected hop by hop along the route.
            This procedure can be implemented by the GMPLS signaling protocol.</t>
        </section>

      </section>
    </section>



    <section title="Routing / Topology dissemination">

      <t>In the case of combined RSA architecture, the computation
        entity needs to get the detailed network information, i.e. connectivity
        topology, node capabilities and available frequency ranges of the
        links. Route computation is performed based on the connectivity
        topology and node capabilities; spectrum assignment is performed based
        on the available frequency ranges of the links. The computation entity
        may get the detailed network information by the GMPLS routing protocol.
        Compared with <xref target="RFC6163"/>, except wavelength-specific
        availability information, the connectivity topology and node
        capabilities are the same as WSON, which can be advertised by GMPLS
        routing protocol (refer to section 6.2 of <xref target="RFC6163"/>.
        This section analyses the necessary changes on link information brought
        by flexible grids.</t>

      <section title="Available Frequency Ranges/slots of DWDM Links">
        <t>In the case of flexible grids, channel central frequencies span from
          193.1 THz towards both ends of the C band spectrum with 6.25 GHz
          granularity.  Different LSPs could make use of different slot widths
          on the same link. Hence, the available frequency ranges should be
          advertised.
        </t> 
      </section>

      <section title="Available Slot Width Ranges of DWDM Links">
        <t>The available slot width ranges needs to be advertised, in
          combination with the Available frequency ranges, in order to verify
          whether a LSP with a given slot width can be set up or not; this is
          is constrained by the available slot width ranges of the media matrix
          Depending on the availability of the slot width ranges, it is
          possible to allocate more spectrum than strictly needed by the
          LSP.</t>
      </section>

      <section title="Spectrum Management">
        <t>[Editors' note: the part on the hierarchy of the optical spectrum
          could be confusing, we can discuss it].  The total available spectrum
          on a fiber could be described as a resource that can be divided by a
          media device into a set of Frequency Slots. In terms of managing
          spectrum, it is necessary to be able to speak about different
          granularities of managed spectrum. For example, a part of the spectrum
          could be assigned to a third party to manage. This need to partition
          creates the impression that spectrum is a hierarchy in view of
          Management and Control Plane. The hierarchy is created within a
          management system, and it is an access right hierarchy only. It is a
          management hierarchy without any actual resource hierarchy within
          fiber.  The end of fiber is a link end and presents a fiber port which
          represents all of spectrum available on the fiber. Each spectrum
          allocation appears as Link Channel Port (i.e., frequency slot port)
          within fiber.
        </t>

      </section>
     <section title="Information Model">
      <t>Fixed DM grids can also be described via suitable choices of slots in
        a flexible DWDM grid. However, devices or applications that make use of
        the flexible grid may not be capable of supporting every possible slot
        width or central frequency position. Following is the definition of
        information model, not intended to limit any IGP encoding
        implementation. For example, information required for routing/path
        selection may be the set of available nominal central frequencies from
        which a frequency slot of the required width can be allocated. A
        convenient encoding for this information (may be as a frequency slot or
        sets of contiguous slices) is further study in IGP encoding
        document.
      </t>

      <t>
        <figure anchor="routing_information_model" title="Routing Information model">
          <artwork><![CDATA[
<Available Spectrum in Fiber for frequency slot> ::= 
    <Available Frequency Range-List>
    <Available Central Frequency Granularity >
    <Available Slot Width Granularity>
    <Minimal Slot Width>
    <Maximal Slot Width>

<Available Frequency Range-List> ::= 
    <Available Frequency Range >[< Available Frequency Range-List>]

<Available Frequency Range >::= 
  <Start Spectrum Position><End Spectrum Position> | 
  <Sets of contiguous slices>

<Available Central Frequency Granularity> ::= n × 6.25GHz, 
  where n is positive integer, such as 6.25GHz, 12.5GHz, 25GHz, 50GHz
  or 100GHz

<Available Slot Width Granularity> ::= m × 12.5GHz, 
  where m is positive integer

<Minimal Slot Width> ::= j x 12.5GHz, 
  j is a positive integer

<Maximal Slot Width> ::= k x 12.5GHz, 
    k is a positive integer (k >= j)
              ]]>
            </artwork>
        </figure>
      </t>
      </section>
    </section>

  </section>





<!-- ===================================================================
     Control plane requirements
     =================================================================== -->
  <section title="Control Plane Requirements">
    <t> The GMPLS based control plane of a flexi-grid networks provides aditional requirements to GMPLS. In this section the features to be covered by GMPLS signaling for flexi-grid are identified. [Editor's note: Only discussed requirements are included at this stage. Routing requirements will come in the next version] </t>

    <section title="Support for Media Channels">

        <t>The control plane SHALL be able to support Media Channels, characterized by a single frequency slot. The representation of the Media Channel in the GMPLS Control plane is the so-called flexi-grid LSP. Since network media channels are media channels, an LSP may also be the control plane representation of a network media channel. Consequently, the control plane SHALL be able to support Network Media Channels.</t>
         <t>The signaling procedure SHALL be able to configure the nominal central frequency (n) of a flexi-grid LSP.</t>
        <t>The control plane protocols SHALL allow flexible range of values for the frequency slot width (m)  parameter. Specifically, the control plane SHALL allow  setting up a media channel with frequency slot width (m) ranging from a minimum of m=1 (12.5GHz) to a maximum of the entire C-band with a slot width granularity of 12.5GHz.</t>
          <t>The signaling procedure of the GMPLS control plane SHALL be able to configure the minimum width (m) of a flexi-grid LSP. In adition, the control plane SHALL be able to configure local frecuency slots,</t>
         <t>The control plane architecture SHOULD allow for the support of L-band and S-band</t>  
          <t>The signalling process of the control plane SHALL allow to collect the local frequency slot asigned at each link along the path</t>   
    </section>    
  
    <section title="Support for Media Channel Resizing">
      <t>The control plane SHALL allow resizing (grow or shrink) the frequency slot width of a media channel/network media channel. The resizing MAY imply resizing the local frequency slots along the path of the flexi-grid LSP.</t>
    </section> 

    <section title="Support for Logical Associations of multiple media channels ">
      <t>A set of media channels can be used to transport signals that have a logical association between them. The control plane architecture SHOULD allow multiple media channels to be logically associated. The control plane SHOULD allow the co-routing of a set of media channels logically associated</t>
    </section> 
       
  </section> <!-- end control plane requirements -->




<!-- ===================================================================
         SECURITY CONSIDERATIONS
     =================================================================== -->
  <section title="Security Considerations">
    <t>TBD</t>
  </section>


<!-- ===================================================================
           CONTRIBUTING AUTHORS
     =================================================================== -->
  <section title="Contributing Authors">
    <t>
      <list>
        <t>
          Qilei Wang<vspace blankLines='0'/>
          ZTE<vspace blankLines='0'/>
          Ruanjian Avenue, Nanjing, China<vspace blankLines='0'/>
          wang.qilei@zte.com.cn<vspace blankLines='0'/>
        </t>
        <t>
          Malcolm Betts<vspace blankLines='0'/>
          ZTE<vspace blankLines='0'/>
          malcolm.betts@zte.com.cn<vspace blankLines='0'/>
        </t>
        <t>
          Xian Zhang<vspace blankLines='0'/>
          Huawei<vspace blankLines='0'/>
          zhang.xian@huawei.com<vspace blankLines='0'/>
        </t>
        <t>
          Cyril Margaria<vspace blankLines='0'/>
          Nokia Siemens Networks<vspace blankLines='0'/>
          St Martin Strasse 76, Munich,   81541, Germany<vspace blankLines='0'/>
          +49 89 5159 16934<vspace blankLines='0'/>
          cyril.margaria@nsn.com<vspace blankLines='0'/>
        </t>
        <t>
          Sergio Belotti<vspace blankLines='0'/>
          Alcatel Lucent<vspace blankLines='0'/>
          Optics CTO<vspace blankLines='0'/>
          Via Trento 30 20059 Vimercate (Milano) Italy<vspace blankLines='0'/>
          +39 039 6863033<vspace blankLines='0'/>
          sergio.belotti@alcatel-lucent.com<vspace blankLines='0'/>
        </t>
        <t>
          Yao Li<vspace blankLines='0'/>
          Nanjing University<vspace blankLines='0'/>
          wsliguotou@hotmail.com<vspace blankLines='0'/> 
        </t>
        <t>
          Fei Zhang<vspace blankLines='0'/>
          ZTE<vspace blankLines='0'/>
          Zijinghua Road, Nanjing, China<vspace blankLines='0'/>
          zhang.fei3@zte.com.cn<vspace blankLines='0'/>
        </t>
        <t>
          Lei Wang<vspace blankLines='0'/>
          ZTE<vspace blankLines='0'/>
          East Huayuan Road, Haidian district, Beijing, China<vspace blankLines='0'/>
          wang.lei131@zte.com.cn <vspace blankLines='0'/>
        </t>
        <t>
          Guoying Zhang<vspace blankLines='0'/>
          China Academy of Telecom Research<vspace blankLines='0'/>
          No.52 Huayuan Bei Road, Beijing, China<vspace blankLines='0'/>
          zhangguoying@ritt.cn<vspace blankLines='0'/>
        </t>
        <t>
          Takehiro Tsuritani<vspace blankLines='0'/>
          KDDI R&D Laboratories Inc.<vspace blankLines='0'/>
          2-1-15 Ohara, Fujimino, Saitama, Japan<vspace blankLines='0'/>
          tsuri@kddilabs.jp<vspace blankLines='0'/>
        </t>
        <t>
          Lei Liu<vspace blankLines='0'/>
          KDDI R&D Laboratories Inc.<vspace blankLines='0'/>
          2-1-15 Ohara, Fujimino, Saitama, Japan<vspace blankLines='0'/>
          le-liu@kddilabs.jp<vspace blankLines='0'/>
        </t>
        <t>
          Eve Varma<vspace blankLines='0'/>
          Alcatel-Lucent<vspace blankLines='0'/>
          +1 732 239 7656<vspace blankLines='0'/>
          eve.varma@alcatel-lucent.com<vspace blankLines='0'/>
        </t>
        <t>
          Young Lee<vspace blankLines='0'/>
          Huawei<vspace blankLines='0'/>
        </t>
        <t>
          Jianrui Han<vspace blankLines='0'/>
          Huawei<vspace blankLines='0'/>
        </t>
        <t>
          Sharfuddin Syed<vspace blankLines='0'/>
          Infinera<vspace blankLines='0'/>
        </t>
        <t>
          Rajan Rao<vspace blankLines='0'/>
          Infinera<vspace blankLines='0'/>
        </t>
        <t>
          Marco Sosa<vspace blankLines='0'/>
          Infinera<vspace blankLines='0'/>
        </t>
        <t>
          Biao Lu<vspace blankLines='0'/>
          Infinera<vspace blankLines='0'/>
        </t>
        <t>
          Abinder Dhillon<vspace blankLines='0'/>
          Infinera<vspace blankLines='0'/>
        </t>
        <t>
          Felipe Jimenez Arribas<vspace blankLines='0'/>
          Telefónica I+D<vspace blankLines='0'/>
        </t>
        <t>
          Andrew G. Malis<vspace blankLines='0'/>
          Verizon<vspace blankLines='0'/>
        </t>
        <t>
          Adrian Farrel<vspace blankLines='0'/>
          Old Dog Consulting<vspace blankLines='0'/>
        </t>
        <t>
          Daniel King<vspace blankLines='0'/>
          Old Dog Consulting<vspace blankLines='0'/>
        </t>
        <t>
          Huub van Helvoort<vspace blankLines='0'/>
        </t>
      </list>
    </t>
  </section>


<!-- ===================================================================
                                 ACKNOWLEDGEMENTS
     =================================================================== -->
  <section title="Acknowledgments">
    <t>The authors would like to thank Pete Anslow for his insights and
      clarifications. This work was supported in part by the FP-7 IDEALIST project under grant
agreement number 317999.</t>
  </section>
</middle>


<back>
  <references title="Normative References">
    &RFC2119;
    &RFC3945;
    &RFC4206;
    &RFC5150;
    &RFC6163;
    <reference anchor="G.800">
      <front>
        <title>ITU-T Recommendation G.800, Unified functional architecture of transport networks.</title>
        <author> <organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2012" month="February"/>
      </front>
    </reference>

    <reference anchor="G.805">
      <front>
        <title>ITU-T Recommendation G.805, Generic functional architecture of transport networks.</title>
        <author> <organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2000" month="March"/>
      </front>
    </reference>

    <reference anchor="G.709">
      <front>
        <title>ITU-T Recommendation G.709, Interfaces for the Optical Transport Network (OTN).
        </title>
        <author> <organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2009" month="March"/>
      </front>
    </reference>
    <reference anchor="G.694.1">
      <front>
        <title>ITU-T Recommendation G.694.1, Spectral grids for WDM applications: DWDM frequency grid</title>
        <author> <organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2012" month="November"/>
      </front>
    </reference>

    <reference anchor="G.872">
      <front>
        <title>ITU-T Recommendation G.872, Architecture of optical transport networks, draft v0.16 2012/09 (for discussion)</title>
        <author><organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2012"/>
      </front>
    </reference>
<reference anchor="G.8080">
      <front>
        <title>ITU-T Recommendation G.8080/Y.1304, Architecture for the automatically switched
optical network</title>
        <author><organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2012" month=""/>
      </front>
    </reference>

     <reference anchor="G.870">
      <front>
        <title>ITU-T Recommendation G.870/Y.1352, Terms and definitions for optical transport
networks</title>
        <author><organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2012" month="November"/>
      </front>
    </reference>
    <reference anchor="G.959.1-2013">
      <front>
        <title>Update of ITU-T Recommendation G.959.1, Optical transport network physical layer interfaces (to appear in July 2013)</title>
        <author><organization abbrev="ITU-T">International Telecomunications Union</organization></author>
        <date year="2013"/>
      </front>
    </reference>
  </references> 



  <references title="Informative References">
    &RFC4397;
  </references> 

</back>
</rfc>

PAFTECH AB 2003-20262026-04-24 04:41:32