One document matched: draft-martinelli-ccamp-optical-imp-signaling-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2205 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3945.xml">
<!ENTITY RFC3471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC4054 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4054.xml">
<!ENTITY RFC5420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5420.xml">
<!ENTITY RFC4328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4328.xml">
<!ENTITY I-D.ietf-ccamp-rwa-wson-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-rwa-wson-framework-07">
<!ENTITY I-D.ietf-ccamp-wson-impairments SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-impairments-04">
<!ENTITY I-D.bernstein-wson-impairment-info
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernstein-wson-impairment-info.xml">
<!ENTITY I-D.ietf-ccamp-wson-signaling
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-signaling-00">
<!ENTITY I-D.ietf-ccamp-gmpls-g-694-lambda-labels
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.xml">
<!ENTITY RFC5266 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5266.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- GM: Make use of editorial comments -->
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-martinelli-ccamp-optical-imp-signaling-03.txt" ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Optical Impairment Signaling ">
GMPLS
Signaling Extensions for Optical Impairment Aware Lightpath Setup
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Giovanni Martinelli" initials="G. M." role="editor" surname="Martinelli">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>via Philips 12</street>
<code>20052</code>
<city>Monza</city>
<country>Italy</country>
</postal>
<email>giomarti@cisco.com</email>
</address>
</author>
<author fullname="Andrea Zanardi" initials="A. Z." role="editor" surname="Zanardi">
<organization>CREATE-NET</organization>
<address>
<postal>
<street>via alla Cascata 56 C, Povo</street>
<code>38100</code>
<city>Trento</city>
<country>Italy</country>
</postal>
<email>andrea.zanardi@create-net.org</email>
</address>
</author>
<date day="25" month="October" year="2010" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>kw1</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
The problem of provisioning a lightpath in a transparent dense wavelength
division multiplexing (DWDM) optical island requires the evaluation of
of the optical impairments along the selected route.
In this memo we propose a GMPLS signaling protocol (RSVP/RSVP-TE) extension
to collect and provide the egress node the optical impairment parameters
needed to validate a lightpath setup request feasibility.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The current Generalized Multi-Protocol Label Switching (GMPLS) specification
<xref target="RFC3945"/> and the signaling related documents
(<xref target="RFC3471"/>, <xref target="RFC3473"/>,
<xref target="RFC4328"/>)
support optical interfaces with different switching capability.
Current optical switching technologies allow implementation of Wavelength Switched
Optical Networks (WSON) and their relationship with control plane are defined within
framework
<xref target="I-D.ietf-ccamp-rwa-wson-framework"/> and related documents.
</t>
<t>
The implementation technology for the WSON is the Dense
Wavelength Division Multiplexing (DWDM) and, one of the key issue is
the physical impairments incurred by
non-ideal optical transmission medium that accumulate along an optical path.
For a successful lightpath provisioning in a WSON, the set up process
must be aware of a set of physical impairments that has effect
on the lightpath.
From control plane perspetive the WSON probelm is divied within two main categories:
the routing and waveleght assigment problem (as the framework above), and
the impairment awareness. For this case the framework
<xref target="I-D.ietf-ccamp-wson-impairments"/>.
provides the motivation why
optical impairments are important and details all possible.
control plane architectural options.
</t>
<t>
This memo apply to an Impairment Validation process (IV) defined within the
framework as Distributed process and it is related to the approximated scenario
(<xref target="I-D.ietf-ccamp-wson-impairments"/> Scenario C, section 3.1).
Proposes extensions relates to signaling protocol (RSVP/RSVP-TE) as a way
to collect and verify optical impairments for a lightpath setup.
The management of optical impairments is done only in the
signaling process and it does
not require any extension to the traffic engineering database
and routing protocols or Path Computational Element (PCE).
</t>
<t>
For what regarding signaling, WSON network require already some specific extentions as
defined within <xref target="I-D.ietf-ccamp-wson-signaling"/>. This document will add some specific information
referring to the IV process.
</t>
</section>
<!-- ##################### END OF 'Introduction' ########################### -->
<section title="Conventions Used in This Document">
<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">RFC 2119</xref>.</t>
<t>
In additions this document will use terminology from
<xref target="RFC2205"/>,
<xref target="RFC3209"/>,
<xref target="RFC4054"/>,
and
<xref target="I-D.ietf-ccamp-rwa-wson-framework"/>.
</t>
</section>
<!-- ##################### SECTION ########################### -->
<section title="Optical Path Impairment Validation" anchor="sec_valid_procedure">
<t>
This section report an high level description on how the the distributed IV process
will work. From a procedural aspect it will be compatible with both RWA and
distributed wavelenght assignment process.
</t>
<section title="Procedure for Distributed Validation">
<t>
The signaling based validation of an optical path in downstream direction in a
transparent network (lambda switched LSP) is implemented
by the following procedure:
</t>
<t>
<list style="symbols">
<t>
Within Path message, the ingress node signals in supported signal types
(Forward Error Correction and modulation format) and wavelength set
(encoded in the LABEL_SET Object)
depending on available local transponders. These parameters refer to
signal compatibility within <xref target="I-D.ietf-ccamp-wson-signaling"/>.
</t>
<t>
Transit nodes update the Path messagecomputing or measuring the path optical characteristics up
to the outgoing interface (optical impairments).
In case of Distributed Wavelenght assignment trasit node will pruning non cross-connectable wavelengths
(LABEL_SET Object).
</t>
<t>
The egress node selects the wavelength and the signal type based on the signaled
optical impairments and the available local transponders (supported wavelengths,
sensitivity to optical impairments) and signals the selection in the Resv message.
</t>
<t>
Transit nodes process the Resv message cross-connecting the selected
wavelength in incoming and outgoing interfaces (wavelength continuity constraint).
</t>
<t>
The ingress node cross-connects the selected wavelength to a local transponder
supporting the selected signal type (Forward Error
Correction and modulation format).
</t>
</list>
</t>
<t>
In the Path message processing, the unavailability of cross-connectable wavelength
in transit nodes or of
transponders supporting the signal in the egress node causes the
request failure (PathErr message).
</t>
<t>
In the Resv message processing, the unavailability of the selected wavelength in
transit nodes or
of transponders supporting the signal in the ingress node
(race condition in allocating resources) causes the
request failure (ResvErr message).
</t>
<t>
This procedure forces the meeting of the wavelength continuity constraint:
the final effect
of pruning wavelengths (e.g. removing labels from the LABEL_SET
object) in transit nodes is the implementation of a wavelength selection process in
the signaling phase. The wavelength assignment will be done at the egress node
among all available wavelength for the LSP. The criteria used by the egress node
to assign the wavelength is out of the scope of this document and is reported in
<xref target="I-D.ietf-ccamp-wson-signaling"/>
</t>
</section>
<section title="The Wavelenght Assignment Problem">
<t>
The impairment framework document
<xref target="I-D.ietf-ccamp-wson-impairments"/>
details how the Routing and Wavelength Assignment (RWA) function
and the Impairment Validation (IV) function can be combined
withing different architectural options.
</t>
<t>
The distributed IV as detailed in this memo is compatible with different
options for implementing the WA function.
In case the WA function is implemented elsewhere the procedure
above still apply apart from considering a single wavelength instead of a wavelength
set. If optical validation fail along the path, instead of pruning a wavelet,
the node will reply directly with a PathErr and the
Lightpath setup will fail.
</t>
</section>
</section>
<!-- ######################## Section ####################### -->
<section title="Optical Parameters Classification">
<t>
The set of optical parameters carried by the signaling protocol is divided into
optical service parameters and optical path parameters. The
actual list is defined elsewhere like
<xref target="ITU.G680"/> and
<xref target="I-D.bernstein-wson-impairment-info"/>.
Scope of this
section is just to propose a classification appropriate for
RSVP-TE encoding.
</t>
<t>
<list style="symbols">
<t>Optical Service Parameters.
<vspace blankLines="1" />
For DWDM networks the egress node of an LSP has to know
a certain set of specific
optical parameters related to the transmitting interface.
The optical service parameters describe the requested
signal type and
are related to the characteristics of the transponder
at ingress node. They MUST NOT change at transit nodes.
<xref target="service_optical_par"/> details of parameters and their
encoding.
<vspace blankLines="0" />
In the standard signaling, GENERALIZED_LABEL_REQUEST
and TSPEC/FLOW_SPEC objects support the encoding of
equivalent information like the
service type and service QoS. In the context of WSON also
the draft
<xref target="I-D.ietf-ccamp-wson-signaling"/>
reports some of this parameters.
</t>
<t>Optical Path Parameters.
<vspace blankLines="1" />
The optical path parameters describe the signal characteristics
evolution along the path
from ingress node to egress node, are
related to the characteristics of the
various links/subsystems and are updated at each transit node.
They are divided into mandatory and optional parameters.
The mandatory parameters are related to feasibility constraints such as
power and OSNR,
whereas the optional parameters are expandable linear impairments such as chromatic
dispersion (CD), polarization mode dispersion (PMD), crosstalk, etc. The optional
parameters can be used to evaluate the feasibility of a lightpath more accurately
as an alternate solution to the bounded OSNR margin evaluation.
Parameter update methods might use appropriate
physical models and are out of scope of this document.
The <xref target="I-D.bernstein-wson-impairment-info"/>
identifies which are the parameters and the related ITU-T
source document.
<xref target="optical_path_param_section"/> shows
RSVP-TE encoding details.
</t>
</list>
</t>
</section>
<!-- ##################### SECTION ########################### -->
<section anchor="phys_par_classification_sec" title="Information
Encoding ">
<t>
This document defines how to encode the above information through new
TLVs according to <xref target="RFC5420"></xref>.
</t>
<t>
The proposed encoding scheme for the optical
parameters defines a TLV (channel optical physical information)
associated to a wavelength containing a sub-TLV for
each service and path parameter.
</t>
<t>
Additional set of parameters can be
added without affecting the already defined encoding.
</t>
<t>
A TLV sub-object for each available wavelength (Path message) or selected
wavelength (Resv message) is encoded in an LSP_REQUIRED_ATTRIBUTES Object.
</t>
<t>
The TLV sub-object encoding is defined in the next picture.
</t>
<figure align="center" anchor="tlv_top_level">
<preamble></preamble>
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Parameters Sub-TLV Sequence //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>
<list style="symbols">
<t>
Type: optical channel physical parameters info TLV type (TBA).
</t>
<t>
Length: total length of the TLV including header in octets.
</t>
<t>
Wavelength ID: wavelength label identifier according to
<xref target="I-D.ietf-ccamp-gmpls-g-694-lambda-labels"/>.
</t>
<t>
Parameters Sub-TLV Sequence: service and path parameters values.
</t>
</list>
</t>
<t>
The TLVs wavelength ID value must be
consistent with the presence of LABEL_SET
objects and its actions as defined within <xref target="RFC3471"/>
and <xref target="RFC3473"/>.
</t>
<t>
The Sub-TLV format is defined in the next picture
<figure align="center" anchor="sub_tlv_format" >
<preamble></preamble>
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
</t>
<t>
<list style="empty">
<t>Type: Sub-TLV type</t>
<t>Flags: bit-mask defining the management of the Sub-TLV
<list style="empty">
<t>bit 0: if set the parameter is mandatory, otherwise it is optional.</t>
<t>bit 1: if set the parameter is variable and
MUST be updated with the local value, otherwise
it is a constant value set by the ingress node.</t>
<t>bit 2-7: not used.</t>
</list>
</t>
<t>Length: total length of the sub-TLV including header in octects.
</t>
<t>Value: variable length Sub-TLV content</t>
</list>
</t>
<t>
The Flags field defines how transit nodes manage
the Sub-TLV:
<list style="symbols">
<t>Constant sub-TLVs are forwarded as-is.
</t>
<t>Mandatory non constant sub-TLVs MUST be updated with the local
parameter value,
if the parameter is not managed by the node, it MUST reject the
request with a failure.
</t>
<t>Optional non constant sub-TLVs MUST be updated with the local
parameter value,
if the parameter is not managed by the node, it MUST silently drop
it from the TLV (the value would be
inaccurate).
</t>
</list>
</t>
</section>
<!-- ##################### END OF SECTION ########################### -->
<!-- ##################### SECTION ########################### -->
<section anchor="service_optical_par" title="Optical Service Parameters sub-TLV">
<t>
The Optical Service Parameters define the signal transmissions characteristics
at the ingress node. This type of information is required at the egress node
to verify the
optical signal compatibility.
</t>
<figure align="center" anchor="optical_service_enc">
<preamble></preamble>
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC 1 | Mod Format 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC n | Mod Format n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>
<list style="empty">
<t>Type: sub-TLV type (=1)</t>
<t>Flags: Mandatory, Constant</t>
<t>Length: total length of the sub-TLV including header in octets</t>
<t>FEC: supported Forward Error Correction Modes (see <xref target="fec_section"/> </t>
<t>
Mod Format: supported modulation formats (see <xref target="modformat_section"/>)
associated with the FEC.
</t>
</list>
</t>
<t>
This sub-TLV is used in the PATH message to signal
the full list of optical parameters associated with the interface
(signal types and wavelengths) available at the ingress node.
A DWDM interface might have several sets of optical parameters
available, for example a tunable interface has a set of possible wavelengths,
together with a set of possible FEC encoding or modulation formats.
In the RESV message this information is associated to the selected receiving
interface at the egress node. In the RESV message only one tuple
(FEC, Mod Format) will be specified.
</t>
<section anchor="fec_section" title="Forward Error Correction (FEC)">
<t>
FEC (16 bits) field is the Forward Error Correction and has the following values:
<list style="empty">
<t>0: no FEC</t>
<t>1: standard FEC (according to <xref target="ITU.G709"/>)</t>
<t>
2-9: super-FEC according to sub clauses from I.2 to I.9 of
<xref target="ITU.G975.1"/>
</t>
</list>
</t>
<t>
Values with the format 1bbbbbbbbbbbbbbb are left to represent
vendor specific or proprietary
FEC encoding.
</t>
</section>
<section anchor="modformat_section"title="Modulation Format">
<t>
Editorial Node: this encoding section need to be reviewed with
<xref target="I-D.ietf-ccamp-wson-signaling"/>.
</t>
<t>
Mod Format (16 bits) is the modulation and has
the following values:
<list style="empty">
<t>0: NRZ</t>
<t>1: Duo Binary</t>
<t>2: DPSK</t>
</list>
</t>
<t>
Other values might be defined in the future as technology advance. Values with the
format 1bbbbbbbbbbbbbbb are left to represent vendor specific or proprietary
modulation formats.
</t>
</section>
</section>
<!-- ##################### SECTION ########################### -->
<section anchor="optical_path_param_section" title="Optical Path Parameters sub-TLV(s)">
<t>
This set of parameters is carried in
the PATH message for each available wavelength
to allow the optical feasibility evaluation.
At each hop, the optical node MUST
update these values according to information locally available at the
node (say internal amplifiers, wavelength cross connect, etc.).
This sub-TLV implements the Distributed Impairment
evaluation as per <xref target="I-D.bernstein-wson-impairment-info"/>
</t>
<t>
The way an optical node gets knowledge of this required information (e.g.
through network management system, auto-discovery etc.)
is out of the scope of this document and
highly depends on specific equipment implementation.
</t>
<t>
This document defines two groups of linear optical parameters.
<list style="hanging">
<t hangText="Mandatory Linear Optical Parameters"><vspace blankLines="0"/>
This set includes Optical Signal Power and the OSNR with
associated variances. It represents the minimum set to asses the
feasibility of an optical path. This set
will be encoded using mandatory sub-TLVs.
</t>
<t hangText="Optional Linear Optical Parameters"><vspace blankLines="0"/>
This set includes CD, PMD, XT with associated variances.
These parameters represent an additional set to
allow a more accurate optical feasibility evaluation. This set
will be encoded using optional sub-TLVs.
</t>
</list>
</t>
<t>
Separation between mandatory and optional parameters allows a rough optical feasibility
evaluation where network elements support at least the mandatory set.
Depending on how a WSON is designed, the usage of the mandatory set could be
an operational choice not to overwhelm the control plane while
maintaining reliable feasibility estimation.
Moreover it might happens that not all nodes in a networks support the full set
of optical path parameters. With this classification, the lightpath signaling
still
continues to work although with a less accurate evaluation.
</t>
<t>
The choice of the optional set of parameters depends on several considerations.
They are among those reported by the <xref target="RFC4054"/> and provide
sufficient accuracy for the linear impairments evaluation.
</t>
<!-- ################ SUBSEC ##################### -->
<section title="Optical Parameter sub-TLV overview">
<t>
Each optical parameter will be encoded using the following format:
</t>
<figure align="center" anchor="optical_param_encoding_overview">
<preamble></preamble>
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Parameter Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Parameter Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>
<list style="empty">
<t>Type: sub_TLV type > 1.</t>
<t>Flags: mandatory or optional according to each parameter classification, variable. </t>
<t>Length: total length of the Sub-TLV including header in octets
(8 octets or 12 octets depending if the optical
parameter has the variance value associated).
</t>
<t>
Value associated with the optical parameter.
</t>
<t>
Variance: the error estimation for optical parameter value calculation. Depending
on the length value may not be present.
</t>
</list>
</t>
</section>
<!-- ############ SUBSECTION ############## -->
<section title="Mandatory Linear Optical Parameters sub-TLVs">
<t>
The Sub-TLVs encode the following optical parameters of a
channel (wavelength) measured at
the node egress interface. Flags are: mandatory, variable.
</t>
<section title="Optical Power">
<t>
Type = 2.
</t>
<t>
Value: 32bit IEEE floating point number. Measurement Unit: dBm.
</t>
</section>
<section title="Optical Signal to Noise Ratio">
<t>
Type = 3.
</t>
<t>
Value: 32bit IEEE floating point number. Measurement Unit: dB.
</t>
</section>
</section>
<!-- ############ SUBSECTION ############## -->
<section title="Optional Linear Optical Parameters sub-TLVs">
<t>
The Sub-TLVs encode the following optical parameters of a
channel (wavelength) measured at
the node egress interface. Flags are: optional, variable.
</t>
<section title="Chromatic Dispersion (CD)">
<t>
Type = 4.
</t>
<t>
Value: 32bit IEEE floating point number. Measurement Unit: ps/nm.
</t>
</section>
<section title="Polarization Mode Dispersion (PMD)">
<t>
Type = 5.
</t>
<t>
Value: 32bit IEEE floating point number. Measurement Unit: ps.
</t>
</section>
<section title="Cross-Talk (XT)">
<t>
Type = 6.
</t>
<t>
Value: 32bit IEEE floating point number. Measurement Unit: dB.
</t>
</section>
</section>
</section> <!-- END OF Opticat Path Parameters -->
<!-- ##################### SECTION ########################### -->
<section anchor="message_fragmentation" title="Message Fragmentation">
<t>
In certain cases, the state information carried by the Path message
can be quite large. Size estimation for a physical Optical Channel TLV
(see <xref target="tlv_top_level"/>) can be the following:
8 bytes for type, length and wavelength ID plus, 16 bytes for the
Optical Service Parameters sub-TLV considering 3 FEC/modulation format
combinations plus, 24 bytes for the Mandatory Linear Optical Path
parameters plus 36 bytes for the Optional Linear Optical Parameter sub-TLV.
Total is 48 bytes for each wavelength by just considering mandatory sub-TLVs
and 84 bytes by considering also the optional part.
Given the number of wavelengths today available in DWDM networks,
the size of the path message end up in large values.
For example to signal just 32 wavelengths the size required for the
physical optical parameters ranges at least from 1536 to 2688 bytes.
</t>
<t>
A possible option is to let the application layer requesting the
lightpath setup to decide how many wavelengths to signal according
to the MTU available.
For example, having an MTU of 1500 bytes the application layer might
signal only 10 wavelengths with the full set of parameters taking up
840 bytes, or it might decide to signal 20 wavelengths with just the
mandatory parameters.
Note that, according to procedure described within
<xref target="sec_valid_procedure" />, the message
size may decrease as long as the Path message pass through transit
nodes.
</t>
<t>
A second solution proposed here implements the semantic fragmentation
as suggested by <xref target="RFC2205">RSVP</xref>.
The proposed encoding extends the SENDER_TEMPLATE Object
with a new Class Type (derived from the LSP_TUNNEL_IPv4 and
LSP_TUNNEL_IPv6
<xref target="RFC3209">RSVP-TE</xref>).
The Object includes the additional information on the
"fragment id" and on the requested policy for the channel selection at the egress
node
</t>
<figure align="center" anchor="sender_template_ipv4">
<preamble>
Class = SENDER_TEMPLATE, FRAGREQ_LSP_TUNNEL_IPv4 C-Type = TBA
</preamble>
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalNo | MsgId | P | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure align="center" anchor="sender_template_ipv6" >
<preamble>
Class = SENDER_TEMPLATE, FRAGREQ_LSP_TUNNEL_IPv6 C-Type = TBA
</preamble>
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalNo | MsgId | P | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Besides the fields already defined in the SENDER_TEMPLATE, the following
fields are defined:
<list hangIndent="4" style="symbols">
<t>
TotalNo: 8 bit integer representing the total number of Path messages
issued by the
ingress node to setup a single lightpath. When this values is equals to 1
all the other fields MUST be ignored.
</t>
<t>
MsgId: 8 bit integer representing the sequential number of a
single Path request.
Its value must be between 1 and TotalNo, both inclusive.
</t>
<t>
P: Policy the egress node must apply upon receiving a fragmented path request:
<list hangIndent="8" style="empty">
<t>1: Take the first message arrived and ignore the following ones.</t>
<t>2: After the first message arrives, wait for any message within the
specified Timeout.</t>
<t>3: After the first message arrives, waits for all messages.
Fail, if the timeout expires, and there's at least one message missing
</t>
</list>
The egress node should "reject" (PathErr) all
the requests except for the selected one, even if it could
rely on the RSVP timeout to clear the unselected requests status
in upstream nodes.
</t>
<t>
Timeout: 12 bits integer number representing the timeout value used by the policy.
The value is in s/100 (hundreds of seconds)
All messages MUST have the same value.
</t>
</list>
</t>
<t>
This type of encoding is a generic solution to manage the
semantic fragmentation and its not strictly related to
optical parameters encoding.
</t>
</section>
<!-- ##################### END OF SECTION ########################### -->
<section anchor="backward_compat" title="Backward Compatibility">
<t>
The TLV usage as defined by <xref target="RFC5420"/> will guarantee the
co-existence of nodes supporting normal RSVP-TE operations and node with optical
impairment signaling capability.
</t>
<t>
A service with the new feature (optical feasibility evaluation) can be setup
only if all the nodes in the path support the extensions.
Optical Path Parameters
are updated hop-by-hop and evaluated at egress node.
If a transit node does
not support the extensions the collected information is unreliable and the
Path request MUST be rejected.
</t>
</section>
<section anchor="error_management" title="Error management">
<t>
No additional error code is introduced to manage requests
failures; the behavior defined in <xref target="RFC5420"/>
applies to the management of the LSP_REQUIRED_ATTRIBUTES
Object.
</t>
</section>
<!-- ############################## -->
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
</t>
</section>
<!-- ############################## -->
<section anchor="Contributors" title="Contributing Authors">
<t> This document was the collective work of several authors. The text
and content of this document was contributed by the editors and the
co-authors listed below (the contact information for the editors
appears in appropriate section and is not repeated below):
</t>
<figure align="left">
<artwork align="left"><![CDATA[
Gabriele Maria Galimberti
Cisco Systems
via Philips 12
Monza 20052, Italy
Email: ggalimbe@cisco.com
Alberto Tanzi
Cisco Systems
via Philips 12
Monza 20052, Italy
Email: atanzi@cisco.com
Domenico La Fauci
Cisco Systems
via Philips 12
Monza 20052, Italy
Email: dlafauci@cisco.com
Elio Salvadori
CREATE-NET
via alla Cascata 56 C, Povo
Trento 38100, Italy
Email: elio.salvadori@create-net.org
Chava Vijaya Saradhi
CREATE-NET
via alla Cascata 56 C, Povo
Trento 38100, Italy
Email: saradhi.chava@create-net.org
]]></artwork>
</figure>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo needs the following request to IANA
<list style="empty">
<t>TLV (see <xref target="tlv_top_level"/> in <xref target="phys_par_classification_sec"/>)</t>
<t>New class type for sender template (see <xref target="message_fragmentation"/>) </t>
</list>
</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="RFC5266">the update of
RFC 2434</xref> for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section will
be removed during conversion into an RFC by the RFC Editor.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This document introduces no new security considerations to <xref target="RFC3473"/>.
GMPLS security is described in section 11 of <xref target="RFC3471"/> and refers to
<xref target="RFC3209"/> for RSVP-TE.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC2205;
&RFC3209;
&RFC3471;
&RFC3473;
&RFC5420;
&RFC4328;
<reference anchor="ITU.G680">
<front>
<title>
Physical transfer functions of optical network
elements
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.680"/>
</reference>
<reference anchor="ITU.G709">
<front>
<title>
Interface for the Optical Transport Network (OTN)
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="March" year="2003"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.709"/>
</reference>
<reference anchor="ITU.G975.1">
<front>
<title>
Forward Error Correction for high bit rate DWDM Submarine Systems
</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="February" year="2004"/>
</front>
<seriesInfo name="ITU-T" value="Recommendation G.975"/>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3945;
&RFC4054;
&I-D.ietf-ccamp-rwa-wson-framework;
&I-D.ietf-ccamp-wson-impairments;
&I-D.bernstein-wson-impairment-info;
&I-D.ietf-ccamp-wson-signaling;
&I-D.ietf-ccamp-gmpls-g-694-lambda-labels;
&RFC5266;
<!-- A reference written by by an organization not a person. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:46 |