One document matched: draft-ietf-ccamp-flexi-grid-fwk-05.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
vim: set softtabstop=2 shiftwidth=2 expandtab
version=20150522
-->
<?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 RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC4202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4202.xml">
<!ENTITY RFC4204 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4204.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 RFC4606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4606.xml">
<!ENTITY RFC4783 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4783.xml">
<!ENTITY RFC4802 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4802.xml">
<!ENTITY RFC4803 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4803.xml">
<!ENTITY RFC5511 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5511.xml">
<!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">
<!ENTITY RFC6163 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml">
<!ENTITY RFC6344 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6344.xml">
<!ENTITY RFC7139 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7139.xml">
<!ENTITY RFC7260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7260.xml">
]>
<rfc category="info" docName="draft-ietf-ccamp-flexi-grid-fwk-05" 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>oscar.gonzalezdedios@telefonica.com</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>ZTE Plaza,No.10,Tangyan South Road, Gaoxin District</street>
<city>Xi'An</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="2015" />
<area>Routing</area>
<workgroup>CCAMP Working Group</workgroup>
<keyword>DWDM</keyword>
<keyword>flexi-grid</keyword>
<keyword>GMPLS</keyword>
<abstract>
<t>To allow efficient allocation of optical spectral bandwidth for high
bit-rate systems, the International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) has extended its
Recommendations G.694.1 and G.872 to include a new dense wavelength
division multiplexing (DWDM) grid by defining a set of nominal central
frequencies, channel spacings and the concept of "frequency slot". In
such an environment, a data plane connection is switched based on
allocated, variable-sized frequency ranges within the optical spectrum
creating what is known as a flexible grid (flexi-grid).</t>
<t>This document defines a framework and the associated control plane
requirements for the GMPLS-based control of flexi-grid DWDM networks.</t>
</abstract>
</front>
<middle>
<!-- ===================================================================
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.</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, a media channel
can transport more than one Optical Tributary Signals (OTSi), as defined
later in this document.</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 GMPLS-based control plane for the control
(provisioning/recovery, etc.) of a fixed grid wavelength division
multiplexing (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 dense wavelength division multiplexing (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>
<!-- ===================================================================
Terminology
=================================================================== -->
<section title ="Terminology">
<t>Further terminology specific to flexi-grid networks can be found in
<xref target="terms"/>.</t>
<!-- ===================================================================
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>
<t>While <xref target="RFC2119"/> describes interpretations of these key
words in terms of protocol specifications and implementations, they are
used in this document to describe design requirements for protocol
extensions.
</t>
</section>
<!-- ===================================================================
Acronyms
=================================================================== -->
<section title="Abbreviations">
<t>EFS: Effective Frequency Slot</t>
<t>FS: Frequency Slot</t>
<t>FSC: Fiber-Switch Capable</t>
<t>LSR: Label Switching Router</t>
<t>NCF: Nominal Central Frequency</t>
<t>OCh: Optical Channel</t>
<t>OCh-P: Optical Channel Payload</t>
<t>OTN: Optical Transport Network</t>
<t>OTSi: Optical Tributary Signal</t>
<t>OTSiG: OTSi Group is a set of OTSi</t>
<t>OCC: Optical Channel Carrier</t>
<t>PCE: Path Computation Element</t>
<t>ROADM: Reconfigurable Optical Add-Drop Multiplexer</t>
<t>SSON: Spectrum-Switched Optical Network</t>
<t>SWG: Slot Width Granularity</t>
</section>
</section>
<!-- ===================================================================
Overview
=================================================================== -->
<section title="Overview of 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 an OTN. It 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.</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 anchor="terms" title="Flexi-grid Terminology">
<t>This section presents the definition of the terms used in flexi-grid
networks. More detail about these terms can be found 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 and 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>
<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
<figure><artwork><![CDATA[f = 193.1 THz + n x 0.00625 THz]]></artwork></figure>
where 193.1 THz is ITU-T "anchor frequency" for transmission over the
C band, and 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: This is the spacing between
allowed nominal central frequencies and it is set to 6.25 GHz <xref target="G.694.1"/>.</t>
<t>Slot Width Granularity (SWG): 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.
<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>
<list style="symbols">
<t>The symbol '+' represents the allowed nominal central frequencies</t>
<t>The '--' represents the nominal central frequency granularity</t>
<t>The '^' represents the slot nominal central frequency</t>
<t>The number on the top of the '+' symbol represents the 'n' in the
frequency calculation formula.</t>
<t>The nominal central frequency is 193.1 THz when n equals to zero.</t>
</list>
</t>
<t>Effective Frequency Slot <xref target="G.870"/>: The effective
frequency slot of a media channel is that part of the frequency
slots of the filters along the media channel that is common to
all of the filters' frequency slots. Note that both the Frequency
Slot and Effective Frequency Slot are local terms.
<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>
</t>
</list>
</t>
</section>
<section title="Media Layer Elements">
<t><list style="symbols">
<t>Media Element: A media element directs an 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>
</list></t>
</section>
<section title="Media Channels">
<t>This section defines concepts such as (Network) Media Channel; the
mapping to GMPLS constructs (i.e., LSP) is detailed in
<xref target="GMPLSapplicability"/>.</t>
<t><list style="symbols">
<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
frequency slot (an 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: <xref target="G.870"/> defines the Network
Media Channel as a media channel that transports a single OTSi, defined
next. </t>
</list></t>
</section>
<section title="Optical Tributary Signals">
<t><list style="symbols">
<t>Optical Tributary Signal (OTSi) <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. To provide a connection between the OTSi source and
the OTSi sink the optical signal must be assigned to a network
media channel.</t>
<t>OTSi Group (OTSiG): The set of OTSi that are carried by a
group of network media channels. Each OTSi is carried by one
network media channel. From a management perspective it SHOULD be
possible to manage both the OTSiG and a group of Network Media
Channels as single entities.</t>
</list></t>
</section>
<section anchor="compositeMediaChannels" title="Composite Media Channels">
<t><list style="symbols">
<t>It is possible to construct an end-to-end media channel as a
composite of more than one network media channels. A composite
media channel carries a group of OTSi (i.e., OTSiG). Each OTSi is
carried by one network media channel. This group of OTSi are
carried over a single fibre.</t>
<!-- TODO: Clarify the "Should"
- Should we talk in terms of "Composite Network Media Channels", instead of "Composite Media Channels"?
- Should we mention where the term "composite" comes from? e.g. adding something like "A composite (network) media channel is a control plane construct that encompasses multiple network media channels
-->
<t>In this case, the effective frequency slots may be contiguous (i.e., there
is no spectrum between them that can be used for other media channels) or
non-contiguous.</t>
<t>It is not currently envisaged that such composite media channels may be
constructed from slots carried on different fibers whether those fibers
traverse the same hop-by-hop path through the network or not.</t>
<t>Furthermore, it is not considered likely that a media channel may be
constructed from a different variation of slot composition on each hop.
That is, the slot composition must be the same from one end to the other
of the media channel even if the specific slots and their spacing may
vary hop by hop.</t>
<t>How the signal is carried across such groups of network media channels is out of
scope for this document.</t>
</list></t>
</section>
</section>
<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 split into
network 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 OTSi.</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-----------+ |
| | OTSi | | OTSi | |
| | 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>
<section title="Flexi-grid Layered Network Model">
<t>In the OTN layered network, the network media channel transports a single
OTSi (see <xref target="simple_layered_network_model"/>)</t>
<figure anchor="simple_layered_network_model" title="Simplified Layered Network Model">
<artwork><![CDATA[
| OTSi |
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
The symbol (1) indicates a Matrix Channel
]]></artwork>
</figure>
<t>Note that a particular example of OTSi is the OCh-P.
<xref target="layered_network_model"/> shows this specific example as
defined in G.805 <xref target="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
The symbol (1) indicates a Matrix Channel
]]></artwork>
</figure>
<section title="DWDM Flexi-grid Enabled Network Element Models">
<t>A flexible grid network is constructed from subsystems that include
WDM links, tunable transmitters, and receivers, (i.e, media elements
including media layer switching elements that are media matrices) as
well as electro-optical network elements. This is just the same as in
a fixed grid network except that each element has flexible grid
characteristics.</t>
<t>As stated in Clause 7 of <xref target="G.694.1"/> the flexible DWDM
grid 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 might 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" anchor="GMPLSapplicability">
<t>The goal of this section is to provide an insight into the application of
GMPLS as a control mechanism in flexi-grid networks. Specific control
plane requirements for the support of flexi-grid networks are covered in
<xref target="CPrequirements"/>. This framework is aimed at controlling
the media layer within the OTN hierarchy, and controlling the required
adaptations of the signal layer. This document also defines the term
Spectrum-Switched Optical Network (SSON) 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 that are switched in media channel matrices. GMPLS
labels are used to 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 OTSi).</t>
</section>
<section title="Consideration of TE Links">
<t>From a theoretical / abstract point of view, a fiber can be modeled as
having a frequency slot that ranges from minus infinity to plus infinity.
This representation helps understand the relationship between frequency
slots and ranges.</t>
<t>The frequency slot is a local concept that applies within a component or
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 sequence of the three components (i.e., a filter, a fiber, and a filter),
is a media channel in its most basic form. From the control plane
perspective this may modeled as a (physical) TE-link with a contiguous
optical spectrum. This can be represented by saying 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 a 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 resulting media support of joining basic media channels
is still a media channel, i.e., a longer association sequence of media
elements and its effective frequency slot. In other words, It is
possible to "concatenate" several media channels (e.g., patch on
intermediate nodes) to create a single media channel.</t>
<t>The architectural construct resulting of the association sequence of
basic media channels and media layer matrix cross-connects can be
represented as (i.e., corresponds to) a Label Switched Path (LSP) from
a control plane perspective. </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>Furthermore, if appropriate, the media channel can also be
represented as a TE link or Forwarding Adjacency (FA)
<xref target="RFC4206"/>, 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 anchor="lsps" title="Consideration of LSPs in Flexi-grid">
<t>The flexi-grid LSP is 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
(without considering the adaptation functions). 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 and egress
nodes. The ports towards the client can still be represented as
interfaces from the control plane perspective.</t>
<t><xref target="lsp_mchan1"/> shows an LSP routed between 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 because 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 network side of the trnaponders. This is commonly
names as OTSi-trail connection.</t>
<figure anchor="lsp_mchan2" title="LSP Representing a Network Media Channel (OTSi Trail)">
<artwork>
<![CDATA[
|--------------------- Network Media Channel ----------------------|
+----------------------+ +----------------------+
| | |
+------+ +------+ +------+ +------+
| | +----+ | | | | +----+ | |OTSi
OTSi| 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 is terminated on the Filter
ports of the Ingress and Egress nodes. This is named in G.872 as OTSi Network Connection.
As can be seen from the figures, there is no difference from a GMPLS modelling
perspective between these cases, but they are shown as distinct examples to
highlight the differences in the data plane.</t>
<figure anchor="lsp_mchan3" title="LSP Representing a Network Media Channel (OTSi Network Connection)">
<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>Applying the notion of hierarchy at the media layer, by using the
LSP as an FA (i.e., by using hierarchical LSPs), the media channel
created can support multiple (sub-)media channels.</t>
<figure anchor="mrn_mln_topology_view" title="Topology View with TE Link / FA">
<artwork>
<![CDATA[
+--------------+ +--------------+
| Media Channel| TE | Media Channel| Virtual TE
| | link | | link
| Matrix |o- - - - - - - - - - o| Matrix |o- - - - - -
+--------------+ +--------------+
| +---------+ |
| | Media | |
|o----| Channel |-----o|
| |
| Matrix |
+---------+
]]>
</artwork>
</figure>
<t>Note that there is only one media layer switch matrix (one
implementation is a FlexGrid ROADM) in SSON, while a signal layer LSP
(Network Media Channel) is established mainly for the purpose of
management and control of individual optical signals. Signal layer
LSPs with the same attributes (such as source and destination) can be
grouped into one media-layer LSP (media channel): this has advantages
in spectral efficiency (reduce guard band between adjacent OChs in one
FSC channel) and LSP management. However, assuming some network
elements perform signal layer switching in an SSON, there must be
enough guard band between adjacent OTSis in any media channel to
compensate for the filter concatenation effects and other effects caused by
signal layer switching elements. In such a situation, the separation
of the signal layer from the media layer does not bring any benefit in
spectral efficiency or in other aspects, but makes the network switch
and control more complex. If two OTSis must be switched to different
ports, it is better to carry them by diferent FSC channels, and the
media layer switch is enough in this scenario.</t>
<t>As discussed in <xref target="compositeMediaChannels"/>, a media channel
may be constructed from a compsite of network media channels. This may be
achieved in two ways using LSPs. These mechanisms may be compared to the
techniques used in GMPLS to support inverse multiplexing in Time Division
Multiplexing (TDM) networks and in OTN <xref target="RFC4606"/>,
<xref target="RFC6344"/>, and <xref target="RFC7139"/>.
<list style="symbols">
<t>In the first case, a single LSP may be established in the control plane.
The signaling messages include information for all of the component
network media channels that make up the composite media channel.
</t>
<t>In the second case, each component network media channel is
established using a separate control plane LSP, and these LSPs are
associated within the control plane so that the end points may see
them as a single media channel.
</t>
</list>
</t>
</section>
<section title="Control Plane Modeling of Network Elements">
<t>Optical transmitters and 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 detail
in <xref target="RFC6163"/>. Media matrices include line side
ports that are connected to DWDM links, and tributary side input/output
ports that can be connected to transmitters/receivers.</t>
<t>A set of common constraints can be defined:
<list style="symbols">
<t>Slot widths: 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 have not been allocated (i.e., are 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 could 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>
</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" end-to-end frequency slot. The establishment of
an LSP is related to the establishment of the media channel and the configuration of
the effective frequency slot.</t>
<t>A "service request" is characterized (at a minimum) by its required
effective frequency slot width. This does not preclude that the request
may add additional constraints such as also imposing the nominal central
frequency. A given effective frequency slot may be requested for the
media channel in the control plane LSP setup messages, and a specific
frequency slot can be requeste on any specific hop of the LSP setup.
Regardless of the actual encoding, the LSP setup message specifies a
minimum frequency slot width that needs to be fulfilled in order to
successful establish the requsted LSP.</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, it must be possible to determine the
end-to-end values of the n and m parameters. We refer to this by saying that
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 present in the Path message, and the effective frequency slot is mapped
to the FlowSpec carried in the Resv message.</t>
<t>In GMPLS-controlled systems, the switched element corresponds to the
'label'. In flexi-grid where the switched element is a frequency slot, the
label represents a frequency slot. In consequence, the label in flexi-grid
conveys the necessary information to obtain the frequency slot characteristics
(i.e, central frequency and slot 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, given hardware constraints
and capabilities (e.g., a given node might not support the finest granularity).
This means that the values of n and m may change at each hop. As long as a
given downstream node allocates enough optical spectrum, m can be different
along the path. This covers the issue where media matrices can have different
slot width granularities. Such variations in the local value of m will appear
in the allocated label that encodes the frequency slot as well as the in the
FlowSpec that describes the flow.</t>
<t>Different operational modes can be considered. For Routing and Spectrum
Assignment (RSA) with explicit label control, and for Routing and Distributed
Spectrum Assignment (R+DSA), the GMPLS signaling procedures are similar to
those described in section 4.1.3 of <xref target="RFC6163"/> for Routing and
Wavelength Assignment (RWA) and for Routing and Distributed Wavelength
Assignment (R+DWA). The main difference is that the label set specifies the
available nominal central frequencies that meet the slot width requirements of
the LSP. The intermediate nodes use the control plane to 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 an LSP to assign the
proper frequency resource. Except for 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 for WSON as described in section 6.1 of
<xref target="RFC6163"/>.</t>
<t>Regarding how a GMPLS control plane can assign n and m hop-by-hop along the
path of an LSP, different cases can apply:
<list style="letters">
<t>n and m can both change. It is the effective frequency slot that matters,
it needs to remain valid along the path.</t>
<t>m can change, but n needs to remain the same along the path. This
ensures that the nominal central frequency stays the same, but the
width of the slot can vary along the path. Again, the important thing
is that the effective frequency slot remains valid and satisfies the
requested parameters along the whole path of the LSP.</t>
<t>n and m need to be unchanging along the path. This ensures that
the frequency slot is well-known end-to-end, and is a simple way to
ensure that the effective frequency slot remains valid for the whole
LSP.</t>
<t>n can change, but m needs to remain the same along the path. This
ensures that the effective frequency slot remains valid, but allows the
frequency slot to be moved within the spectrum from hop to hop.
</t>
</list>
</t>
<t>The selection of a path that ensures n and m continuity can be delegated to
a dedicated entity such as a Path Computation Element (PCE). Any constraint (including
frequency slot and width granularities) can be taken into account during path
computation. Alternatively, A PCE can compute a path leaving the actual
frequency slot assignment to be done, for example, with a distributed (signaling)
procedure:
<list style="symbols">
<t>Each downstream node ensures that m is >= requested_m.</t>
<t>A downstream node cannot foresee what an upstream node will allocate. A
way to ensure that the effective frequency slot is valid along the length
of the LSP is to ensure that the same value of n is allocated at each hop.
By forcing the same value of 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>This may be too restrictive, since a node (or even a centralized/combined
RSA entity) may be able to ensure that the resulting end-to-end effective
frequency slot is valid even if n varies locally. That means, the effective
frequency slot that characterizes the media channel from end to end is
consistent and is determined by its n and m values, but that the effective
frequency slot and those values are logical (i.e., do not map direct to the
physically assigned spectrum) in the sense that they are the result of the
intersection of locally-assigned frequency slots applicable at local
components (such as filters) each of which may have assigned different
frequency slots.</t>
</list>
</t>
<t>For <xref target="effslot1"/> the effective slot is made 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 <xref target="effslot2"/> the effective slot is made valid by
ensuring that it is valid at each hop in the upstream direction. The
intersection needs to be computed because invalid slots could result otherwise.</t>
<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>Note, when a media channel is bound to one OTSi (i.e., is a network
media channel), the EFS must be the one of the OTSi. 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 have to constrain the EFS to be the
OTSi EFS.</t>
</section>
<section title="Neighbor Discovery and Link Property Correlation">
<t>There are potential interworking problems between fixed-grid DWDM and
flexi-grid DWDM nodes. Additionally, even two flexi-grid nodes may
have different grid properties, leading to link property conflict with
resulting limited interworking.</t>
<t>Devices or applications that make use of the flexi-grid might not be
able to support every possible slot width. In other words,
different applications may be defined where each supports a different
grid granularity. Consider a node with an application where the nominal
central frequency granularity is 12.5 GHz and where slot widths are
multiples of 25 GHz. In this case the link between two optical nodes
with different grid granularities must be configured to align with the
larger of both granularities. Furthermore, 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 need to be negotiated:
<list style="symbols">
<t>Grid capability (channel spacing) - Between fixed-grid and
flexi-grid nodes.</t>
<t>Grid granularity - Between two flexi-grid nodes.</t>
<t>Slot width tuning range - Between two flexi-grid nodes.</t>
</list>
</t>
</section>
<section title="Path Computation / Routing and Spectrum Assignment (RSA)">
<t> In WSON, if there is no (available) wavelength converter in an optical
network, an LSP is subject to the "wavelength continuity constraint" (see
section 4 of <xref target="RFC6163"/>). Similarly in flexi-grid, if the
capability to shift or convert an allocated frequency slot is absent, the
LSP is subject to the "Spectrum Continuity Constraint".</t>
<t>Because of the limited availability of wavelength/spectrum converters
(in what is called a "sparse translucent optical network") the
wavelength/spectrum continuity constraint always has to be considered.
When available, information regarding spectrum conversion capabilities at
the optical nodes may be used by RSA mechanisms.</t>
<t>The RSA process determines a route and frequency slot for an LSP.
Hence, when a route is computed the spectrum assignment process (SA)
determines the central frequency and slot width based on the slot
width and available central frequencies information of the transmitter
and receiver, and utilizing 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 <xref target="RFC6163"/>, 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>
<t>Note that all of these models allow the concept of a composite media
channel supported by a single control plane LSP or by a set of
associated LSPs.</t>
<section title="Combined RSA (R&SA)">
<t>In this case, a computation entity performs both routing and
frequency slot assignment. The computation entity needs access to
detailed network information, e.g., the connectivity topology of
the nodes and links, the available frequency ranges on each link,
the node capabilities, etc.</t>
<t>The computation entity could reside on a dedicated PCE server, in the
provisioning application that requests the service, or on 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 needs the connectivity topology to compute the
proper routes. The second entity needs information about the
available frequency ranges of the links and the capabilities of the
nodes in order to assign the spectrum.</t>
</section>
<section title="Routing and Distributed SA (R+DSA)">
<t>In this case an 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 need to 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 and Topology Dissemination">
<t>In the case of the combined RSA architecture, the computation
entity needs 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, while spectrum assignment is performed
based on the available frequency ranges of the links. The computation
entity may get the detailed network information via the GMPLS routing
protocol.</t>
<t>For WSON, the connectivity topology and node capabilities can be
advertised by the GMPLS routing protocol (refer to section 6.2 of
<xref target="RFC6163"/>. Except for wavelength-specific availability
information, the information for flexi-grid is the same as for WSON
and can equally be distributed by the GMPLS routing protocol.</t>
<t>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 need to be
advertised.
</t>
</section>
<section title="Available Slot Width Ranges of DWDM Links">
<t>The available slot width ranges need to be advertised in combination
with the available frequency ranges, in order that the computing entity
can verify whether an LSP with a given slot width can be set up or not.
This 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>The total available spectrum on a fiber can be described as a
resource that can be partitioned. For example, a part of the spectrum
could be assigned to a third party to manage, or parts of the spectrum
could be assigned by the operator for different classes of traffic.
This partitioning creates the impression that spectrum is a hierarchy
in view of Management and Control Plane: each partition could be itself
be partitioned. However, the hierarchy is created purely within a
management system: it defines a hierarchy of access or management rights,
but there is no corresponding resource hierarchy within the fiber.
</t>
<t>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. Thus, while there is a hierarchy of ownership (the
Link Channel Port and corresponding LSP are located on a fiber and
so associated with a fiber port) there is no continued nesting
hierarchy of frequency slots within larger frequency slots. In its
way, this mirrors the fixed grid behavior where a wavelength is
associated with a port/fiber, but cannot be subdivided even though it
is a partition of the total spectrum available on the fiber.
</t>
</section>
<section title="Information Model">
<t>This section defines an information model to describe the data that
represents the capabilities and resources available in an flexi-grid
network. It is not a data model and is not intended to limit any protocol
solution such as an encoding for an IGP. 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
is for further study in an IGP encoding document.
</t>
<t>Fixed DWDM 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. Thus, the information model needs to
enable:
<list style="symbol">
<t>exchange of information to enable RSA in a flexi-grid
network</t>
<t>representation of a fixed grid device participating in a flexi-grid
network</t>
<t>full interworking of fixed and flexible grid devices within the same
network</t>
<t>interworking of flexgrid devices with different capabilities.</t>
</list>
</t>
<t>The information model is represented using Routing Backus-Naur Format (RBNF)
as defined in <xref target="RFC5511"/>.
</t>
<t>
<figure anchor="routing_information_model" title="Routing Information Model">
<artwork>
<![CDATA[
<Available Spectrum> ::=
<Available Frequency Range-List>
<Available NCFs>
<Available Slot Widths>
where
<Available Frequency Range-List> ::=
<Available Frequency Range> [<Available Frequency Range-List>]
<Available Frequency Range> ::=
( <Start NCF> <End NCF> ) |
<FS defined by (n, m) containing contiguous available NCFs>
and
<Available NCFs> ::=
<Available NCF Granularity> [<Offset>]
-- Subset of supported n values given by p x n + q
-- where p is a positive integer
-- and q (offset) belongs to 0,..,p-1.
and
<Available Slot Widths> ::=
<Available Slot Width Granularity>
<Min Slot Width>
-- given by j x 12.5GHz, with j a positive integer
<Max Slot Width>
-- given by k x 12.5GHz, with k a positive integer (k >= j)
]]>
<!--
<![CDATA[
<Available Spectrum> ::=
<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> ::= (2^n) x 6.25GHz
where n is a non negative integer, giving rise to granularities
such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz
<Available Slot Width Granularity> ::= (2^m) x 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 anchor="CPrequirements" title="Control Plane Requirements">
<t> The control of a flexi-grid networks places additional requirements
on the GMPLS protocols. This section summarizes those requirements for
signaling and routing.
</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
will also be able to support Network Media Channels.
</t>
<section title="Signaling">
<t>The signaling procedure SHALL be able to configure the nominal central
frequency (n) of a flexi-grid LSP.
</t>
<t>The signaling procedure SHALL allow a 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 SHALL be able to configure the minimum width (m)
of a flexi-grid LSP. In addition, the signaling procedure SHALL be able to
configure local frequency slots.
</t>
<t>The control plane architecture SHOULD allow for the support of L-band
and S-band.
</t>
<t>The signalling process SHALL be able to collect the local frequency slot
assigned at each link along the path.
</t>
<t>The signaling procedures SHALL support all of the RSA architectural models
(R&SA, R+SA, and R+DSA) within a single set of protocol objects although
some objects may only be applicable within one of the models.
</t>
</section>
<section title="Routing">
<t>The routing protocol will support all functions as described in
<xref target="RFC4202"/> and extend them to a flexi-grid data plane.</t>
<t>The routing protocol SHALL distribute sufficient information to compute
paths to enable the signaling procedure to establish LSPs as described in
the previous sections. This includes, at a minimum the data described by
the Information Model in <xref target="routing_information_model"/>.
</t>
<t>The routing protocol SHALL update its advertisements of available resources
and capabilities as the usage of resources in the network varies with the
establishment or tear-down of LSPs. These updates SHOULD be amenable to
damping and thresholds as in other traffic engineering routing advertisements.
</t>
<t>The routing protocol SHALL support all of the RSA architectural models
(R&SA, R+SA, and R+DSA) without any configuration or change of behavior.
Thus, the routing protocols SHALL be agnostic to the computation and signaling
model that is in use.</t>
</section>
</section>
<section title="Support for Media Channel Resizing">
<t>The signaling procedures 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>
<t>The routing protocol SHALL update its advertisements of available resources
and capabilities as the usage of resources in the network varies with the
resizing of LSP. These updates SHOULD be amenable to damping and thresholds
as in other traffic engineering routing advertisements.
</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 that are
logically associated.
</t>
</section>
<section title="Support for Composite Media Channels">
<t>As described in <xref target="compositeMediaChannels"/> and
<xref target="lsps"/>, a media channel may be composed of multiple
network media channels.
</t>
<t>The signaling procedures SHOULD include support for signaling a single
control plane LSP that includes information about multiple network media channels that
will comprise the single compound media channel.
</t>
<t>The signaling procedures SHOULD include a mechanism to associate
separately signaled control plane LSPs so that the end points may
correlate them into a single compound media channel.
</t>
<t>The signaling procedures MAY include a mechanism to dynamically vary
the composition of a composite media channel by allowing network
media channels to be added to or removed from the whole.</t>
<t>The routing protocols MUST provide sufficient information for the
computation of paths and slots for composite media channels using
any of the three RSA architectural models (R&SA, R+SA, and R+DSA).
</t>
</section>
<section title="Support for Neighbor Discovery and Link Property Correlation">
<t>The control plane MAY include support for neighbor discovery such
that an flexi-grid network can be constructed in a "plug-and-play" manner.
</t>
<t>The control plane SHOULD allow the nodes at opposite ends of a link to
correlate the properties that they will apply to the link. Such correlation
SHOULD include at least the identities of the node and the identities they
apply to the link. Other properties such as the link characteristics described
for the routing information model in <xref target="routing_information_model"/>
SHOULD also be correlated.
</t>
<t>Such neighbor discovery and link property correlation, if provided, MUST
be able to operate in both an out-of-band and an out-of-fiber control channel.
</t>
</section>
</section> <!-- end control plane requirements -->
<section title="IANA Considerations">
<t>This framework document makes no requests for IANA action.</t>
</section>
<!-- ===================================================================
SECURITY CONSIDERATIONS
=================================================================== -->
<section title="Security Considerations">
<t>The control plane and data plane aspects of a flexi-grid system are
fundamentally the same as a fixed grid system and there is no substantial
reason to expect the security considerations to be any different.
</t>
<t>A good overview of the security considerations for a GMPLS-based control
plane can be found in <xref target="RFC5920"/>.
</t>
<t><xref target="RFC6163"/> includes a section describing security
considerations for WSON, and it is reasonable to infer that these
considerations apply and may be exacerbated in a flexi-grid SSON system.
In particular, the detailed and granular information describing a flexi-
grid network and the capabilities of nodes in that network could put
stress on the routing protocol or the out-of-band control channel used by
the protocol. An attacker might be able to cause small variations in the
use of the network or the available resources (perhaps by modifying the
environment of a fiber) and so trigger the routing protocol to make new
flooding announcements. This situation is explicitly mitigated in the
requirements for the routing protocol extensions where it is noted that the
protocol must include damping and configurable thresholds as already exist
in the core GMPLS routing protocols.
</t>
</section>
<!-- ===================================================================
MANAGEABILITY CONSIDERATIONS
=================================================================== -->
<section title="Manageability Considerations">
<t>GMPLS systems already contain a number of management tools.</t>
<t>
<list style="symbols">
<t>MIB modules exist to model the control plane protocols and
the network elements <xref target="RFC4802"/>, <xref target="RFC4803"/>,
and there is early work to provide similar access through YANG.
The features described in these models are currently designed to
represent fixed-label technologies such as optical networks using
the fixed grid: extensions may be needed in order to represent
bandwidth, frequency slots, and effective frequency slots in flexi-
grid networks.
</t>
<t>There are protocol extensions within GMPLS signaling to allow
control plane systems to report the presence of faults that affect
LSPs <xref target="RFC4783"/>, although it must be carefully noted
that these mechanisms do not constitute an alarm mechanism that
could be used to rapidly propagate information about faults in a
way that would allow the data plane to perform protection switching.
These mechanisms could easily be enhanced with the addition of
technology-specific reasons codes if any are needed.
</t>
<t>The GMPLS protocols, themselves, already include fault detection
and recovery mechanisms (such as the PathErr and Notify messages in
RSVP-TE signaling as used by GMPLS <xref target="RFC3473"/>. It is
not anticipated that these mechanisms will need enhancement to
support flexi-grid although additional reason codes may be needed to
describe technology-specific error cases.
</t>
<t><xref target="RFC7260"/> describes a framework for the control and
configuration of data plane Operations, Administration, and Management
(OAM). It would not be appropriate for the IETF to define or describe
data plane OAM for optical systems, but the framework described in
RFC 7260 could be used (with minor protocol extensions) to enable data
plane OAM that has been defined by the originators of the flexi-grid
data plane technology (the ITU-T).
</t>
<t>The Link Management Protocol <xref target="RFC4204"/> is designed to
allow the two ends of a network link to coordinate and confirm the
configuration and capabilities that they will apply to the link. This
protocol is particularly applicable to optical links where the
characteristics of the network devices may considerably affect how the
link is used and where misconfiguration of mis-fibering could make
physical interoperability impossible. LMP could easily be extended to
collect and report information between the end points of links in a
flexi-grid network.
</t>
</list>
</t>
</section>
<!-- ===================================================================
AUTHORS
=================================================================== -->
<section title="Authors">
<t>
<list>
<t>
Fatai Zhang<vspace blankLines='0'/>
Huawei<vspace blankLines='0'/>
Huawei Base, Longgang District, Chine<vspace blankLines='0'/>
zhangfatai@huawei.com<vspace blankLines='0'/>
</t>
<t>
Xihua Fu<vspace blankLines='0'/>
ZTE<vspace blankLines='0'/>
ZTE Plaza,No.10,Tangyan South Road, Gaoxin District, China<vspace blankLines='0'/>
fu.xihua@zte.com.cn<vspace blankLines='0'/>
</t>
<t>
Daniele Ceccarelli<vspace blankLines='0'/>
Ericsson<vspace blankLines='0'/>
Via Calda 5, Genova, Italy<vspace blankLines='0'/>
daniele.ceccarelli@ericsson.com<vspace blankLines='0'/>
</t>
<t>
Iftekhar Hussain<vspace blankLines='0'/>
Infinera<vspace blankLines='0'/>
140 Caspian Ct, Sunnyvale, 94089, USA<vspace blankLines='0'/>
ihussain@infinera.com<vspace blankLines='0'/>
</t>
</list>
</t>
</section>
<!-- ===================================================================
CONTRIBUTING AUTHORS
=================================================================== -->
<section title="Contributing Authors">
<t>
<list>
<t>
Adrian Farrel<vspace blankLines='0'/>
Old Dog Consulting<vspace blankLines='0'/>
adrian@olddog.co.uk<vspace blankLines='0'/>
</t>
<t>
Daniel King<vspace blankLines='0'/>
Old Dog Consulting<vspace blankLines='0'/>
daniel@olddog.co.uk<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'/>
Juniper Networks<vspace blankLines='0'/>
cmargaria@juniper.net<vspace blankLines='0'/>
</t>
<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>
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'/>
Huawei<vspace blankLines='0'/>
zhangfei7@huawei.com<vspace blankLines='0'/>
</t>
<t>
Lei Wang<vspace blankLines='0'/>
wang.lei@bupt.edu.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'/>
U.C. Davis, USA <vspace blankLines='0'/>
leiliu@ucdavis.edu<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'/>
Telefonica I+D<vspace blankLines='0'/>
</t>
<t>
Andrew G. Malis<vspace blankLines='0'/>
Huawei<vspace blankLines='0'/>
agmalis@gmail.com<vspace blankLines='0'/>
<!--
Andrew Malis <Andrew.Malis@huawei.com>
Andrew G. Malis <amalis@gmail.com>
Andy Malis <agmalis@gmail.com>
-->
</t>
<t>
Huub van Helvoort<vspace blankLines='0'/>
Hai Gaoming BV<vspace blankLines='0'/>
The Neterlands<vspace blankLines='0'/>
huubatwork@gmail.com <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, and to Matt Hartley and Jonas Mårtensson for their
reviews.</t>
<t>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;
&RFC4202;
&RFC4206;
&RFC5511;
<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.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</title>
<author><organization abbrev="ITU-T">International Telecomunications Union</organization></author>
<date year="2013"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC3473;
&RFC4204;
&RFC4606;
&RFC4397;
&RFC4783;
&RFC4802;
&RFC4803;
&RFC5920;
&RFC6163;
&RFC6344;
&RFC7139;
&RFC7260;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:42:09 |