Network Working Group J. Meuric, Ed.
Internet-Draft E. Le Rouzic
Updates: RFC7689 (if approved) Orange
Intended status: Standards Track L. Alahdab
Expires: January 27, 2021 Individual
G. Galimberti
Cisco
July 26, 2020
Conveying Transceiver-Related Information within RSVP-TE Signaling
draft-meuric-ccamp-tsvmode-signaling-01
Abstract
The 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.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2021.
Meuric, Ed., et al. Expires January 27, 2021 [Page 1]
Internet-Draft Transponder Info in RSVP-TE July 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Main Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Single Control Domain . . . . . . . . . . . . . . . . . . 3
2.2. Open Line Systems . . . . . . . . . . . . . . . . . . . . 4
3. Signaling Messages . . . . . . . . . . . . . . . . . . . . . 5
3.1. Encodings . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. WDM-Transceiver-ModeID Sub-TLV . . . . . . . . . . . 5
3.1.2. WDM-Tranceiver-Param Sub-TLV . . . . . . . . . . . . 6
3.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Downstream Direction . . . . . . . . . . . . . . . . 7
3.2.2. Upstream Direction . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The ITU-T's recommendation [G.694.1] defines the flexi-grid
technology as the latest evolution of the WDM data plane. [RFC7689]
defines the extensions to the RSVP-TE signaling ([RFC3473]) to
provision lightpaths in WDM networks, from transceiver to
transceiver, including transit Reconfigurable Optical Add-Drop
Multiplexers (ROADMs). [RFC7792] 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.
Meuric, Ed., et al. Expires January 27, 2021 [Page 2]
Internet-Draft Transponder Info in RSVP-TE July 2020
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
[I-D.ietf-ccamp-dwdm-if-param-yang]
2. Main Use Cases
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 [I-D.ietf-ccamp-wson-iv-encode]). This
includes ROADM-local computation process, passive PCE responding to
the ingress ROADM's request [I-D.ietf-pce-wson-rwa-ext]), as well
centralized controllers relying on PCEP to trigger the RSVP-TE
signaling in the ingress node ([RFC8281]).
2.1. Single Control Domain
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.
Meuric, Ed., et al. Expires January 27, 2021 [Page 3]
Internet-Draft Transponder Info in RSVP-TE July 2020
2.2. Open Line Systems
We now consider that transceivers are installed in shelves
independant 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 [I-D.ietf-ccamp-dwdm-if-mng-ctrl-fwk] and is
consistent with [RFC7698].
--Path--> --Path--> --Path-->
___ _ _ _ _ _ _ ___
___ | |/ _ _ _ ___ \| | ___
| |____| |_ _ _ \| | | |____| |
|___| | | | | | | |___|
Ti |___|\_ _ _ | |_____/|___| Te
Ri _ _ _/|___| Re
<--Resv-- <--Resv-- R <--Resv--
Figure 1: Transceivers (Ti, Te) Connected to an Open Line System
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 [[CREF1: Section 2.1]]).
Therefore, beyond the usual signaling features, the resulting
signaling messages serve 3 additional purposes:
o advertise the ingress Transceiver Type to the optical line, in
charge of the decision related to the optical path across the
network,
o convey the Transceiver Type up to the egress Transceiver, allowing
to check correct match between both ends (as in [[CREF2:
Section 2.1]]),
o inform transceivers at both ends about the Transceiver Mode
allocated by the optical line.
The specification below allows to address this use case.
Meuric, Ed., et al. Expires January 27, 2021 [Page 4]
Internet-Draft Transponder Info in RSVP-TE July 2020
3. Signaling Messages
The following sections specify the fields used in the RSVP-TE Path
and Resv messages to address the requirements above.
3.1. Encodings
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.
3.1.1. WDM-Transceiver-ModeID Sub-TLV
This document introduces the WDM-Transceiver-ModeID sub-TLV so as to
carry the Transceiver Type and ModeID. It has the following format:
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 = TBD1 | Length = 16 | Reserved |AppID Type=TBD6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI (cont'd) | ModeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tsv-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application ID Type (8 bits): As per section 5 of
[I-D.ietf-ccamp-dwdm-if-lmp], 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:
o the first 6 bytes of the Application Identifier must contain the
hexadecimal representation of an Organizationally Unique
Identifier (OUI);
o the following 2 bytes encode a ModeID;
o 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
Meuric, Ed., et al. Expires January 27, 2021 [Page 5]
Internet-Draft Transponder Info in RSVP-TE July 2020
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.
3.1.2. WDM-Tranceiver-Param Sub-TLV
This document introduces the WDM-Transceiver-Param sub-TLV so as to
carry the Transceiver Type identifier and the "detailed mode"
description, which is a subset of the ones specified in
[I-D.ietf-ccamp-dwdm-if-param-yang]. It is aligned on figure 3 in
[I-D.ggalimbe-ccamp-flexigrid-carrier-label] and has the following
format:
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 = TBD | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modulation Format | Bits per Symbol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC-ID | Min OSNR Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Baud-rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel output power | Tsv-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Meuric, Ed., et al. Expires January 27, 2021 [Page 6]
Internet-Draft Transponder Info in RSVP-TE July 2020
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).
3.2. Processing
3.2.1. Downstream Direction
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 [RFC7689].
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 [RFC3209]. In
Meuric, Ed., et al. Expires January 27, 2021 [Page 7]
Internet-Draft Transponder Info in RSVP-TE July 2020
case the Mode specification is fully defined before the first
signaling hop (e.g. operator-specified), the use of the RRO remains
OPTIONAL.
3.2.2. Upstream Direction
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 [RFC7570], 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:
o 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")
o 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").
4. IANA Considerations
The IANA is requested to allocate, from the "Sub-TLV Types for WSON
Processing Hop Attribute TLV" section within the "RSVP-TE Parameters"
registry:
Meuric, Ed., et al. Expires January 27, 2021 [Page 8]
Internet-Draft Transponder Info in RSVP-TE July 2020
+-------+------------------------+------------+
| Value | Meaning | Reference |
+-------+------------------------+------------+
| TDB1 | WDM-Transceiver-ModeID | [This I-D] |
| TDB2 | WDM-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 | Sub-code | Meaning | Reference |
| Code | | | |
+-----------+----------+-------------------------------+------------+
| 24 | TBD3 | Unsupported Tsv-Type | [This I-D] |
| | TBD4 | Unsupported Transceiver Mode | [This I-D] |
| | TBD5 | Unable to Select Transceiver | [This I-D] |
| | | Mode | |
+-----------+----------+-------------------------------+------------+
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:
o the value 0 means "Pending selection",
o the range 1-65503 follows the Expert Review policy for
registration,
o the range 65504-65535 is for experimental use.
The "WDM Modulation Format" sub-registry is initialized as follows:
+-------------+---------------------+
| Value | Modulation Format |
+-------------+---------------------+
| 0 | Pending selection |
| 1 | QPSK |
| 2 | 8-QAM |
| 3 | 16-QAM |
| 4 | 32-QAM |
| 5 | 64-QAM |
| 6-63999 | Unallocated |
| 64000-65535 | Vendor-specific use |
+-------------+---------------------+
Meuric, Ed., et al. Expires January 27, 2021 [Page 9]
Internet-Draft Transponder Info in RSVP-TE July 2020
The "WDM FEC Types" sub-registry is initialized as follows:
+-------------+---------------------+
| Value | FEC Types |
+-------------+---------------------+
| 0 | Pending selection |
| 1 | Reed Solomon FEC |
| 2 | Staircase FEC |
| 3 | O-FEC |
| 4-63999 | Unallocated |
| 64000-65535 | Vendor-specific use |
+-------------+---------------------+
The IANA is requested to allocate, from the "Application ID Type"
section within the "LMP" registry:
+------+-------------------------+------------------------------+
| Type | Meaning | Reference |
+------+-------------------------+------------------------------+
| TBA | G.698.2 | [I-D.ietf-ccamp-dwdm-if-lmp] |
| TBA | OUI + proprietary value | [I-D.ietf-ccamp-dwdm-if-lmp] |
| TBD6 | OUI + Tsv-Type + ModeID | [This document] |
+------+-------------------------+------------------------------+
5. Security Considerations
This specification only adds TLVs to RSVP-TE signaling messages. As
a result, it relies on security guidelines documented in [RFC5920].
6. Acknowledgements
The authors would like to thank Ramon Casellas for his valuable
feedback on the work related to this document.
7. References
7.1. Normative References
[I-D.ggalimbe-ccamp-flexigrid-carrier-label]
Galimberti, G., Fauci, D., Zanardi, A., Galvagni, L., and
J. Meuric, "Signaling extensions for Media Channel sub-
carriers configuration in Spectrum Switched Optical
Networks (SSON) in Lambda Switch Capable (LSC) Optical
Line Systems.", draft-ggalimbe-ccamp-flexigrid-carrier-
label-09 (work in progress), March 2020.
Meuric, Ed., et al. Expires January 27, 2021 [Page 10]
Internet-Draft Transponder Info in RSVP-TE July 2020
[I-D.ietf-ccamp-dwdm-if-lmp]
Hiremagalur, D., Grammel, G., Galimberti, G., Kunze, R.,
and D. Beller, "Extension to the Link Management Protocol
(LMP/DWDM -rfc4209) for Dense Wavelength Division
Multiplexing (DWDM) Optical Line Systems to manage the
application code of optical interface parameters in DWDM
application", draft-ietf-ccamp-dwdm-if-lmp-02 (work in
progress), May 2020.
[I-D.ietf-pce-wson-rwa-ext]
Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-17
(work in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B.
Wright, "Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)", RFC 7570,
DOI 10.17487/RFC7570, July 2015,
<https://www.rfc-editor.org/info/rfc7570>.
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
and H. Harai, "Signaling Extensions for Wavelength
Switched Optical Networks", RFC 7689,
DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>.
Meuric, Ed., et al. Expires January 27, 2021 [Page 11]
Internet-Draft Transponder Info in RSVP-TE July 2020
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
7.2. Informative References
[I-D.ietf-ccamp-dwdm-if-mng-ctrl-fwk]
Kunze, R., Grammel, G., Beller, D., Galimberti, G., and J.
Meuric, "A framework for Management and Control of DWDM
optical interface parameters", draft-ietf-ccamp-dwdm-if-
mng-ctrl-fwk-13 (work in progress), July 2019.
[I-D.ietf-ccamp-dwdm-if-param-yang]
Galimberti, G., Kunze, R., Burk, A., Hiremagalur, D., and
G. Grammel, "A YANG model to manage the optical interface
parameters for an external transponder in a WDM network",
draft-ietf-ccamp-dwdm-if-param-yang-04 (work in progress),
May 2020.
[I-D.ietf-ccamp-wson-iv-encode]
Martinelli, G., Lee, Y., Galimberti, G., and F. Zhang,
"Information Encoding for WSON with Impairments
Validation", draft-ietf-ccamp-wson-iv-encode-02 (work in
progress), January 2019.
[RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F.,
Fu, X., Ceccarelli, D., and I. Hussain, "Framework and
Requirements for GMPLS-Based Control of Flexi-Grid Dense
Wavelength Division Multiplexing (DWDM) Networks",
RFC 7698, DOI 10.17487/RFC7698, November 2015,
<https://www.rfc-editor.org/info/rfc7698>.
Authors' Addresses
Meuric, Ed., et al. Expires January 27, 2021 [Page 12]
Internet-Draft Transponder Info in RSVP-TE July 2020
Julien Meuric (editor)
Orange
2 avenue Pierre Marzin
Lannion 22300
France
Email: julien.meuric@orange.com
Esther Le Rouzic
Orange
2 avenue Pierre Marzin
Lannion 22300
France
Email: esther.lerouzic@orange.com
Luay Alahdab
Individual
Lannion 22300
France
Email: luayahdab@gmail.com
Gabriele Galimberti
Cisco
Via S. Maria Molgora, 48 c
Vimercate 20871
Italy
Email: ggalimbe@cisco.com
Meuric, Ed., et al. Expires January 27, 2021 [Page 13]