| Internet-Draft | Transponder Info in RSVP-TE | October 2022 |
| Meuric, Ed., et al. | Expires 27 April 2023 | [Page] |
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.¶
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].¶
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 27 April 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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]¶
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]).¶
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 a large set of signal parameters a mandatory information to fully configure the egress transceiver in most cases. As a result, the transceiver mode attributes needs to be conveyed up to both devices at the ends of the LSP.¶
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 [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 Section 2.1). Therefore, beyond the usual signaling features, the resulting signaling messages serve 3 additional purposes:¶
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-Mode sub-TLV so as to carry the Transceiver's Type and Mode. It aims at carrying the information associated to "Standard Modes" and "Organizational Modes" defined in section 2.5 of [I-D.ietf-ccamp-optical-impairment-topology-yang]. 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 = 20 | Reserved |AppID Type=TBD6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI (cont'd) | Tsv-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tsv-Mode | Channel Output Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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:¶
Tsv-Type (16 bits): A transponder-specific value allowing to identify a compatible Tsv-Type at the remote end, and supporting a set of optical Tsv-Modes. 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"). The Tsv-Type is an organization-specific information and, as such, must be interpreted in the context of the EUI field.¶
Tsv-Mode (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 Tsv-Mode 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 Tsv-Mode, the Tsv-Mode field SHOULD use a non-zero value and MAY be ignored. A transceiver receiving a Tsv-Mode with the value 0 MAY select a mode based on local policies combined to other signaling information, e.g. channel spectral width.¶
Channel Ouput Power (16 bits): A floating point value specifying the signal power coming out of the transceiver (in dBm). The value FFFFFFFF 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).¶
This specification is consistent [I-D.ietf-ccamp-optical-impairment-topology-yang]: the EUI field maps the the "organization-identifier" transceiver attribute and the combination of the Tsv-Type and the Tsv-Mode perfectly fit into the "operational-mode" attribute.¶
This document introduces the WDM-Transceiver-Param sub-TLV so as to carry the Transceiver Type identifier and a minimum set of attributes from the "Explicit Modes" parameters, as described in section 2.5.3 of [I-D.ietf-ccamp-optical-impairment-topology-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 = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Baud-rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min OSNR | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Carrier Spacing | Roll-off |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx Min Channel Power | Tx Max Channel Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Min Channel Power | Rx Max Channel Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx Max Total Power | Channel Output Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operational Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Baud-rate (32 bits): A nonnegative integer specifying the number of symbols per second.¶
Min OSNR (16 bits): An integer specifying the minimum accepted threshold for the Optical Signal-Noise Ratio in 0.1 nm.¶
Operational Mode (32 bits): A transceiver-related value allowing to identify a compatible mode at the remote end. This field MAY be set to 0, which is a reserved value to disable Mode checking between end transceivers (e.g. pair of identical transponders with fixed mode).¶
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. "Tsv-Mode = 0" in the WDM-Transceiver-Mode sub-TLV), MUST include an empty RRO to request its population by some downstream nodes [RFC3209]. 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 [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:¶
After a transceiver shelf (signaling tail end or regenerator) has received a Path message:¶
In typical deployments of the extensions defined in this document, it is very likely that transceiver-carrying shelves will use an out-of-band control network to exchange RSVP-TE messages which does not necessarily share fate with the data plane. As RSVP-TE is a soft state protocol, the loss a subsequent refreshes messages may reflect the health of the control network rather than the state of the data plane.¶
As a result, in the event of multiple refresh message losses, an implementation MAY keep the data plane state which may be still be up and running, especially if light keeps coming in the receiving direction. As a corollary, an implementation of this document MAY keep data plane states until it receives explicit PathTear or ResvTear messages.¶
The IANA is requested to allocate, from the "Sub-TLV Types for WSON Processing Hop Attribute TLV" section within the "RSVP-TE Parameters" registry:¶
| Value | Meaning | Reference |
|---|---|---|
| TDB1 | WDM-Transceiver-Mode | [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 Code | Sub-code | Meaning | Reference |
|---|---|---|---|
| 24 | TBD3 | Unsupported Tsv-Type | [This I-D] |
| TBD4 | Unsupported Transceiver Mode | [This I-D] | |
| TBD5 | Unable 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 Types" and "WDM FEC Types".¶
For both of them:¶
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 | EUI + Tsv-Type + Tsv-Mode | [This document] |
This specification only adds TLVs to RSVP-TE signaling messages. As a result, it relies on security guidelines documented in [RFC5920].¶
The authors would like to thank Sergio Belotti and Dieter Beller for their suggestions and Ramon Casellas for his valuable feedback on the work related to this document.¶