Conveying Transceiver-Related
Information within RSVP-TE SignalingOrange2 avenue Pierre MarzinLannion22300Francejulien.meuric@orange.comOrange2 avenue Pierre MarzinLannion22300Franceesther.lerouzic@orange.comIndividualLannion22300Franceluayahdab@gmail.comCiscoVia S. Maria Molgora, 48 cVimercate20871Italyggalimbe@cisco.comThe ReSource Reservation Protocol with Traffic Engineering extensions
(RSVP-TE) allows to carry optical information so as to set up channels
over Wavelength Division Multiplexing (WDM) networks between a pair of
transceivers. Nowadays, there are many transceivers that not only
support tunable lasers, but also multiple modulation formats. This memo
leverages the Generalized Multiprotocol Label Switching protocol
extensions to support the signaling of the associated information as a
"mode" parameter within a "transceiver type" context.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.The ITU-T's recommendation [G.694.1] defines the flexi-grid
technology as the latest evolution of the WDM data plane. defines the extensions to the RSVP-TE signaling
() to provision lightpaths in WDM networks, from
transceiver to transceiver, including transit Reconfigurable Optical
Add-Drop Multiplexers (ROADMs). specifies the
encoding of the flex-grid label to be carried within RSVP-TE signaling
messages, leveraging the reconfiguration capability of optical switches
and the wavelength tunability of the transceivers at both ends of the
optical signal.To address the various requirements of optical networks, some
transceivers are supporting multiple modulation formats, baudrates,
FECs, etc. This capability enables to select at setup time the right
trade-off between bitrate, baudrate, reach, spectral width, etc. This
memo defines the required fields to explicitly addresses this case of
"elastic" transceivers. Two options are proposed to address this issue.
The first extension relies on a two-stage identifier: a Transceiver
Type, allowing to summarize the set of capabilities and consistently
correlate both ends of a given optical channel, and a Transceiver
ModeID, i.e. a hardware-related identifier to be interpreted within the
Type context. The second extension replaces the aforementioned ModeID by
a set of optical parameters. In the latter, the exact list of fields
will follow In the following section, it is assumed that, to be able to meet
optical performance requirements, the Routing and Wavelength Assignment
(RWA) tasks are performed before the signaling messages leave the
ingress ROADM. This could happen in various ways, provided the network
topology is available, including optical parameters (e.g., advertised
using ). This includes
ROADM-local computation process, passive PCE responding to the ingress
ROADM's request ), as well
centralized controllers relying on PCEP to trigger the RSVP-TE signaling
in the ingress node ().We consider that transceivers are in the same control domain as the
optical switches. In many deployments, transceivers are embedded in
the edge ROADM shelves, where both the transceiver and the optical
switching are configured by the same set of local control processes.
In this case, carrying the Mode parameter in RSVP-TE signaling is
required to configure the egress side of the signaling session. Even
though some receiver implementations may be able to detect the
modulation format without configuration, most operational deployments
rely on bidirectional signals, thus making the modulation information
a mandatory parameter to fully configure the egress transceiver in
most cases.The specification below allows to address this use case.We now consider that transceivers are installed in shelves
independent from the ROADMs. The set of ROADMs is referred to as the
"optical line", the shelves carrying the transceivers are named
"client devices". This use case is aligned with the problem statement
specified in and
is consistent with .T is a transceiver shelf.R is a ROADM. Only edge ROADMs are depicted here but le line system
is typically a mesh of multiple ROADMs and amplifiers.From the signaling perspective, T and R are refered to as Ti/Ri
(Te/Re) to identify the ingress end (egress end, respectively).The network topology and the associated optical parameters are only
advertised among the ROADMs, part of the line system, i.e. the
topology information does not leak up to the transceiver shelves
(otherwise, that is a specific case of Section 2.1).
Therefore, beyond the usual signaling features, the resulting
signaling messages serve 3 additional purposes:advertise the ingress Transceiver Type to the optical line, in
charge of the decision related to the optical path across the
network,convey the Transceiver Type up to the egress Transceiver,
allowing to check correct match between both ends (as in
Section 2.1),inform transceivers at both ends about the Transceiver Mode
allocated by the optical line.The specification below allows to address this use case.The following sections specify the fields used in the RSVP-TE Path
and Resv messages to address the requirements above.This documents specifies two sub-TLVs. Both serve the same purpose,
with a different level of details: the transceiver mode is described
either using an identifier or a detailed set of parameters. As a
result, an RSVP-TE message SHOULD only carry one of the sub-TLV for a
given hop. In case several of the sub-TLVs below are included, the
first one takes precedence and the following ones are ignored.This document introduces the WDM-Transceiver-ModeID sub-TLV so as
to carry the Transceiver Type and ModeID. It aims at carrying the
information associated to "Standard Modes" and "Organizational
Modes" defined in section 2.5 of .It has the
following format:Application ID Type (8 bits): As per section 5 of , this field allows to
distinguish between the possible encodings of the trailing
"Application ID" field. This specification defines a new Application
ID Type (value TBD6) that extends the "Proprietary" type and
specifies specific fields within the "value" bytes:the first 6 bytes of the Application Identifier must contain
the hexadecimal representation of an Organizationally Unique
Identifier (OUI);the following 2 bytes encode a ModeID;the last 4 bytes carry a Tsv-Type.Tsv-Type (32 bits): A transponder-specific value allowing to
identify a compatible Tsv-Type at the remote end, and supporting a
set of optical ModeIDs. This value MUST be included by the ingress
transceiver, i.e. from the signaling first hop. 0 is a Reserved
value that MUST trigger a PathErr message in response, with Error
Code 24 (Routing Problem) and Error Sub-code TBD3 ("Unsupported
Tsv-Type").ModeID (16 bits): Within a given Tsv-Type, this ID allows to
specify how the transceiver should be configured among the set of
options supported by Tsv-Type; e.g. optical modulation format or
baudrate. The value 0 means that the sending device has not chosen a
particular ModeID and expects this information to be determined by a
downstream node (e.g., the ingress ROADM of the optical line). If
the Tsv-Type resolves into a single ModeID, the ModeID field SHOULD
use a non-zero value and MAY be ignored. A transceiver receiving a
ModeID with the value 0 MAY select a mode based on local policies
combined to other signaling information, e.g. channel spectral
width.This document introduces the WDM-Transceiver-Param sub-TLV so as
to carry the Transceiver Type identifier and the "Explicit Modes"
parameters, as described in section 2.5.3 of . It is
aligned on figure 3 in and has the
following format:Modulation Format: A codepoint identifying the modulation format
of the transceiver signal. Knowing this parameter is not mandatory
to perform an optical path computation, thus the value 0 is
acceptable within a successful signaling session.Bits per Symbol (16 bits): A nonnegative integer specifying the
number of bits encoded per symbol value in case of hybrid modulation
format. It is an off-set with values from 0 to 127 to be applied to
the specified Modulation Format and indicates the mix between the
selected Modulation Format and its upper adjacent (e.g. QPSK + 63
bits per symbol indicates that there is a 50% MIX between QPSK and
8-QAM = 2.5 bits per symbol). If value = 0 the standard Modulation
Format is applied.FEC-ID (16 bits): A codepoint identifying the Forward Error
Correction of the transceiver.Min OSNR Threshold (16 bits): An integer specifying the minimum
accepted threshold for the Optical Signal-Noise Ratio in 0.1 nm.Baud-rate (32 bits): A nonnegative integer specifying the number
of symbols per second.Channel Ouput Power (16 bits): An integer specifying the signal
power coming out of the transceiver (in dB or W?). The value 0 means
"unspecified". If a transceiver receives an unspecified value, its
data plane SHOULD be configured according to its local policy (e.g.
fixed or default value).Tsv-Type (16 bits): A transponder-specific value allowing to
identify a compatible Tsv-Type at the remote end. This field MAY be
set to 0, which is a reserved value to disable Tsv-Type checking
between end transceivers (e.g. because it is useless).The parameters to be used by the egress transceivers are carried
in Path messages. In RSVP-TE signaling, hop-specific information is
encoded within the ERO as hop attributes and WDM parameters are to
be carried as sub-TLVs within the Type 4 TLV of the Hop Attribute
subobject .When sending a Path message, if a signaling head end node
includes one of the WDM-Transceiver sub-TLVs specified in this
document, the entity in charge of the path computation (e.g. the
ingress ROADM) MUST include (unless an error is raised), as part of
the ERO population step, the same sub-TLV to specify the Hop
Attibutes of the tail end transceiver, allowing this information to
be propagated along the RSVP-TE Path messages.A signaling head end node sending a Path message including one of
the WDM-Transceiver sub-TLVs specified in the previous section with
unallocated values, i.e. Mode-defining fields set to 0 (e.g. "ModeID
= 0" in the WDM-Transceiver-ModeID sub-TLV), MUST include an empty
RRO to request its population by some downstream nodes . In case the Mode specification is fully defined
before the first signaling hop (e.g. operator-specified), the use of
the RRO remains OPTIONAL.When the mode selection happens after the signaling has left the
signaling head node, which carries the ingress transceiver, the
selected value needs to be sent back to the head node. As specified
in , it can be included in the Record Route
Object (RRO) within RSVP-TE Resv messages. Starting from the fact
that both end transceivers share a common mode to properly set up a
channel, this leads to the following processing:After a transceiver shelf (signaling tail end or regenerator)
has received a Path message:If both an RRO and a WDM-Transceiver sub-TLV (defined
above) are included, the node MUST populate, in the
responding Resv message, the RRO with its own hop
attributes, using the corresponding sub-TLV. At this stage,
the values of the Mode-defining fields MUST be allocated,
wherever the selection has happened (e.g., ingress ROADM,
local decision).If the Mode description is not supported, the node MUST
respond using a PathErr with Error Code 24 (Routing Problem)
and Error Sub-code TBD4 ("Unsupported Transceiver
Mode").If the values within the WDM-Transceiver sub-TLV are not
allocated and the node is unable to make a local allocation,
it MUST respond using a PathErr with Error Code 24 (Routing
Problem) and Error Sub-code TBD5 ("Unable to Select
Transceiver Mode")When a signaling head end node pending a mode information
receives a Resv message, it MUST look into the RRO and configure
itself consistently with the hop attribute information
associated to the remote transceiver. A signaling head node
receiving an inconsistent Mode (unupported or not matching the
corresponding Path state) MUST respond using a ResvErr with
Error Code 24 (Routing Problem) and Error Sub-code TBD4
("Unsupported Transceiver Mode").The IANA is requested to allocate, from the "Sub-TLV Types for WSON
Processing Hop Attribute TLV" section within the "RSVP-TE Parameters"
registry:ValueMeaningReferenceTDB1WDM-Transceiver-ModeID[This I-D]TDB2WDM-Transceiver-Param[This I-D]The IANA is requested to allocate, from the "Error Codes and
Globally-Defined Error Value Sub-Codes" section within the "RSVP
Parameters" registry:Error CodeSub-codeMeaningReference24TBD3Unsupported Tsv-Type[This I-D]TBD4Unsupported Transceiver Mode[This I-D]TBD5Unable to Select Transceiver Mode[This I-D]The IANA is requested to create, within the "GMPLS Signaling
Parameters" registry, two new sub-registries named "WDM Modulation
Formats" and "WDM FEC Types".For both of them:the value 0 means "Pending selection",the range 1-65503 follows the Expert Review policy for
registration,the range 65504-65535 is for experimental use.The "WDM Modulation Format" sub-registry is initialized as
follows:ValueModulation Format0Pending selection1QPSK28-QAM316-QAM432-QAM564-QAM6-63999Unallocated64000-65535Vendor-specific useThe "WDM FEC Types" sub-registry is initialized as follows:ValueFEC Types0Pending selection1Reed Solomon FEC2Staircase FEC3O-FEC4-63999Unallocated64000-65535Vendor-specific useThe IANA is requested to allocate, from the "Application ID Type"
section within the "LMP" registry:TypeMeaningReferenceTBAG.698.2[I-D.ietf-ccamp-dwdm-if-lmp]TBAOUI + proprietary value[I-D.ietf-ccamp-dwdm-if-lmp]TBD6OUI + Tsv-Type + ModeID[This document]This specification only adds TLVs to RSVP-TE signaling messages. As a
result, it relies on security guidelines documented in .The authors would like to thank Ramon Casellas for his valuable
feedback on the work related to this document.