Internet DRAFT - draft-meuric-ccamp-tsvmode-signaling

draft-meuric-ccamp-tsvmode-signaling







Network Working Group                                     J. Meuric, Ed.
Internet-Draft                                              E. Le Rouzic
Updates: RFC7689 (if approved)                                    Orange
Intended status: Standards Track                           G. Galimberti
Expires: 25 April 2024                                        Individual
                                                         23 October 2023


   Conveying Transceiver-Related Information within RSVP-TE Signaling
                draft-meuric-ccamp-tsvmode-signaling-04

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 25 April 2024.






Meuric, Ed., et al.       Expires 25 April 2024                 [Page 1]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


Copyright Notice

   Copyright (c) 2023 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.

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-Mode Sub-TLV  . . . . . . . . . . . .   5
       3.1.2.  WDM-Transceiver-Param Sub-TLV . . . . . . . . . . . .   6
     3.2.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  Downstream Direction  . . . . . . . . . . . . . . . .   8
       3.2.2.  Upstream Direction  . . . . . . . . . . . . . . . . .   8
     3.3.  Firm State Behavior . . . . . . . . . . . . . . . . . . .   9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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



Meuric, Ed., et al.       Expires 25 April 2024                 [Page 2]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


   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]

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 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.




Meuric, Ed., et al.       Expires 25 April 2024                 [Page 3]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


2.2.  Open Line Systems

   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:

   *  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,
      either allocated by the optical line or forced from the signaling
      head end.

   The specification below allows to address this use case.



Meuric, Ed., et al.       Expires 25 April 2024                 [Page 4]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


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-Mode Sub-TLV

   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:

   *  the first 6 bytes of the Application Identifier must contain the
      hexadecimal representation of an Extended Unique Identifier (EUI),
      knowing that the first 3 bytes map to the Organizationally Unique
      Identifier (OUI) and the 3 remaining ones are allocated by the
      OUI-owner;




Meuric, Ed., et al.       Expires 25 April 2024                 [Page 5]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


   *  the following 2 bytes encode a Tsv-Mode;

   *  the following 4 bytes encode a Tsv-Type;

   *  the last 4 bytes carry the Channel Output Power.

   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.

3.1.2.  WDM-Transceiver-Param Sub-TLV

   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:




Meuric, Ed., et al.       Expires 25 April 2024                 [Page 6]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           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                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                       Optional sub-TLVs                     //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length (16 bits): default is 32, i.e. without sub-TLVs, otherwise to
   be adjusted accordingly.

   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.

   Min Carrier Spacing (16 bits): A half-precision floating point number
   describing the required spectrum width to carry the emitted signal.

   Roll-off (16 bits): A half-precision floating point number refering
   to the edges of the signal spectral shape.

   Tx/Rx Min/Max Channel Power (16 bits x 4): A half-precision floating
   point number describing the range of supported power values on
   emitter (Tx) and receiver (Rx) in dBm.

   Rx Max Total Power (16 bits): A half-precision floating point number
   describing the maximum received power threshold in dBm.

   Channel Output Power (16 bits): cf. Section 3.1.1.




Meuric, Ed., et al.       Expires 25 April 2024                 [Page 7]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


   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).

   Other parameters listed in
   [I-D.ietf-ccamp-optical-impairment-topology-yang] can be included
   using optional sub-TLVs (TBD).

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.  "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.

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:

   *  After a transceiver shelf (signaling tail end or regenerator) has
      received a Path message:



Meuric, Ed., et al.       Expires 25 April 2024                 [Page 8]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


      -  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").

3.3.  Firm State Behavior

   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.

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 25 April 2024                 [Page 9]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


              +=======+=======================+============+
              | Value | Meaning               | Reference  |
              +=======+=======================+============+
              | TDB1  | WDM-Transceiver-Mode  | [This I-D] |
              +-------+-----------------------+------------+
              | TDB2  | WDM-Transceiver-Param | [This I-D] |
              +-------+-----------------------+------------+

                                 Table 1


   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                  | [This I-D] |
   |            |          | Transceiver Mode             |            |
   +------------+----------+------------------------------+------------+
   |            | TBD5     | Unable to Select             | [This I-D] |
   |            |          | Transceiver Mode             |            |
   +------------+----------+------------------------------+------------+

                                  Table 2

   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 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 IANA is requested to allocate, from the "Application ID Type"
   section within the "LMP" registry:






Meuric, Ed., et al.       Expires 25 April 2024                [Page 10]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


    +======+===========================+==============================+
    | 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]              |
    +------+---------------------------+------------------------------+

                                  Table 3


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 Sergio Belotti and Dieter Beller for
   their suggestions and Ramon Casellas for his valuable feedback on the
   work related to this document.

7.  Contributors

   Luay Alahdab, individual

   luayahdab@gmail.com

8.  References

8.1.  Normative References

   [I-D.ggalimbe-ccamp-flexigrid-carrier-label]
              Galimberti, G., Fauci, D. L., 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.", Work in Progress, Internet-Draft, draft-
              ggalimbe-ccamp-flexigrid-carrier-label-15, 25 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ggalimbe-
              ccamp-flexigrid-carrier-label-15>.

   [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



Meuric, Ed., et al.       Expires 25 April 2024                [Page 11]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


              Multiplexing (DWDM) Optical Line Systems to manage the
              application code of optical interface parameters in DWDM
              application", Work in Progress, Internet-Draft, draft-
              ietf-ccamp-dwdm-if-lmp-08, 25 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              dwdm-if-lmp-08>.

   [I-D.ietf-pce-wson-rwa-ext]
              Lee, Y. and R. Casellas, "The Path Computation Element
              Communication Protocol (PCEP) Extension for Wavelength
              Switched Optical Network (WSON) Routing and Wavelength
              Assignment (RWA)", Work in Progress, Internet-Draft,
              draft-ietf-pce-wson-rwa-ext-17, 1 March 2019,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              wson-rwa-ext-17>.

   [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 25 April 2024                [Page 12]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


   [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>.

8.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", Work in Progress, Internet-
              Draft, draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13, 24 July
              2019, <https://datatracker.ietf.org/doc/html/draft-ietf-
              ccamp-dwdm-if-mng-ctrl-fwk-13>.

   [I-D.ietf-ccamp-dwdm-if-param-yang]
              Galimberti, G., Kunze, R., Hiremagalur, D., and G.
              Grammel, "A YANG model to manage the optical interface
              parameters for an external transponder in a WDM network",
              Work in Progress, Internet-Draft, draft-ietf-ccamp-dwdm-
              if-param-yang-09, 13 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              dwdm-if-param-yang-09>.

   [I-D.ietf-ccamp-optical-impairment-topology-yang]
              Beller, D., Le Rouzic, E., Belotti, S., Galimberti, G.,
              and I. Busi, "A YANG Data Model for Optical Impairment-
              aware Topology", Work in Progress, Internet-Draft, draft-
              ietf-ccamp-optical-impairment-topology-yang-13, 10 July
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              ccamp-optical-impairment-topology-yang-13>.

   [I-D.ietf-ccamp-wson-iv-encode]
              Martinelli, G., Lee, Y., Galimberti, G., and F. Zhang,
              "Information Encoding for WSON with Impairments
              Validation", Work in Progress, Internet-Draft, draft-ietf-
              ccamp-wson-iv-encode-02, 4 January 2019,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
              wson-iv-encode-02>.




Meuric, Ed., et al.       Expires 25 April 2024                [Page 13]

Internet-Draft         Transponder Info in RSVP-TE          October 2023


   [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

   Julien Meuric (editor)
   Orange
   2 avenue Pierre Marzin
   22300 Lannion
   France
   Email: julien.meuric@orange.com


   Esther Le Rouzic
   Orange
   2 avenue Pierre Marzin
   22300 Lannion
   France
   Email: esther.lerouzic@orange.com


   Gabriele Galimberti
   Individual
   Email: ggalimbe56@gmail.com























Meuric, Ed., et al.       Expires 25 April 2024                [Page 14]