Internet-Draft | WDM Tunnel YANG Model | October 2024 |
Guo, et al. | Expires 21 April 2025 | [Page] |
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks).¶
The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA).¶
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 21 April 2025.¶
Copyright (c) 2024 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.¶
Transport networks have evolved from traditional fixed-grid Wavelength Switched Optical Networks (WSON) [RFC6163] to more scalable and flexible elastic optical networks. These utilize flexi-grid Dense Wavelength Division Multiplexing (DWDM) technologies [RFC7698] to optimize bandwidth usage. Current DWDM Optical Network deployments may include fixed-grid WSON, flexi-grid DWDM, or a combination of both.¶
In the optical domain, a WDM tunnel typically originates and concludes at a pair of transponders using one or more transceivers dependent upon the data rate and encoding type of the transceivers. These transponders are then connected to an intermediate line system composed of optical switches and multiplexers, including Reconfigurable Optical Add-Drop Multiplexers (ROADMs) and add-drop multiplexers, complemented by optical amplifiers to boost the transmission distance. The optical wavelength can be routed from the transponder or an incoming fiber, through multiplexing, to various outgoing fibers in the DWDM network. At optical nodes, wavelengths may undergo conversion via optical-electrical-optical (OEO) regenerators, depending on the switching setup and fiber configuration.¶
Optical services, transmitted via analog signals, require careful provisioning across the network to maintain signal quality and prevent interference between different wavelength channels. The technology within optical nodes, like tunable transceivers or Colorless, Directionless and Contentionless Flexi-grid (CDC-F) ROADMs, introduces specific constraints that can limit WDM tunnel path options. These constraints must be factored into WDM tunnel provisioning and pre-computation. Additionally, assessing the end-to-end optical performance metrics like Generalized Signal-to-noise Ratio (G-SNR), Bit Error Rate (BER), and Q-factor is crucial to ensure transmission quality and receiver signal integrity.¶
This draft introduces a YANG [RFC7950] data model for setting up and managing TE tunnels and LSPs in DWDM Optical Networks. It aims to provide an intent-based interface used by a control entity such as a Software-defined Network (SDN) controller at its northbound to establish services between endpoints, typically optical transponders. Clients can utilize this model to either partially or fully delegate service provisioning to the SDN controller, while still capable to express additional constraints to guide its operation. Service provisioning can be as simple as identifying the source and destination transponders and delegate the rest of determination to the SDN controller, or as explicit as specifying a complete detailed path complete with tuned wavelengths and transceiver details.¶
This document identifies the WDM tunnel components, parameters and their values, and characterizes the features and the performances of the WDM elements. An application example is provided towards the end of the document to understand their utility better.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The terminology for describing YANG data models is found in [RFC7950].¶
Refer to [RFC7446] and [RFC7699] for the key terms used in this document.¶
The following terms are defined in [RFC7950] and are not redefined here: - client¶
The following terms are defined in [RFC6241] and are not redefined here: - configuration data¶
state data¶
The YANG data model in this draft builds upon the generic TE tunnel model from [I-D.ietf-teas-yang-te]. This base model is suitable for all TE-enabled networks and includes universal TE tunnel elements like node addresses, tunnel termination points (TTPs), and path-level constraints such as explicit path hops, label restrictions, and path diversity. The current model enhances [I-D.ietf-teas-yang-te] by incorporating WDM-specific attributes and constraints relevant to WDM tunnels, including definitions for:¶
Network-scope optical transceiver configuration constraints, e.g., operational modes, transceiver tuning constraints¶
Network-scope WDM path routing policies for influencing WDM TE path selection. For exmaple, whether or not using regenerator or wavelength conversion is allowed, whether or not wavelength retuing is allowed for tunable transceivers, etc.¶
Network-scope optical performance constraints, e.g. the generalized Signal-to-noise (G-SNR) margin and delta power of a feasible optical path¶
Path-scope WDM layer constraints and transceiver configurations for working and protection path within a WDM tunnel¶
List of WDM nodes, links, and optical wavelength that constitute an end-to-end WDM path¶
Other relevant optical attributes which characterize the optical signal¶
The attributes described above are optional, allowing the model to support both simplified and fully-explicit WDM tunnel provisioning to meet diverse client requirements.¶
Additionally, the YANG model provides the status of a WDM tunnel, which includes:¶
Computed paths for various roles such as working, protection, and restoration, indicating potential optical paths confirmed by the SDN controller via pre-computation.¶
Actual LSPs for each tunnel path, representing the optical paths currently established in the network.¶
In optical networks built with traditional chassis-based DWDM optical equipment, optical transponder (OTs) are typically inserted into the chassis installed as cards. WDM tunnels are established between pairs of OTs, with the SDN controller serving as the central entity for provisioning and managing these tunnels.¶
In scenarios like data center interconnects (DCI), optical transponders may be externally mounted on a 'pizza box' and linked via dedicated fiber or wavelength multiplexer/demultiplexer to the optical line system. These external OTs could be managed by the same SDN controller or a different entity, such as an orchestrator. Consequently, a WDM tunnel might be composed of several segments joined to create a continuous end-to-end tunnel.¶
The YANG data model offers a cohesive interface for managing WDM tunnels and tunnel segments, irrespective of transponder location.¶
To illustrate the model's application, consider an optical network with various transponders, switches, and links. A depicted topology outlines two WDM tunnel scenarios. In the first, an end-to-end WDM tunnel (WDM Tunnel 1) comprises two physical paths (WDM Primary Path 1 and 2) linking two integrated optical transponders, Transponder A and E, through WSON and Flexi-grid nodes. The second scenario describes three WDM tunnel segments (WDM Tunnel Segment 2a to 2c) connecting two external OTs, External OT node X and Y, via the same nodes and links.¶
To configure an end-to-end WDM tunnel to interconnect transponders A and E, first of all we have to populate the flexi-grid topology YANG model with all elements in the network:¶
We define the transponders within nodes A and E as tunnel termination points (TTPs) and provide their internal local link connectivity towards the node interfaces. We also provide nodes A and E identifiers, addresses and interfaces.¶
We do the same for the nodes B, C and D, providing their identifiers, addresses and interfaces, as well as the internal connectivity matrix between interfaces.¶
Then, we also define the links 1 to 5 that interconnect nodes, indicating which WSON or flexi-grid labels are available.¶
Other information, such as the slot frequency and granularity are also provided.¶
After the nodes, links and transponders have been defined using [I-D.ietf-ccamp-flexigrid-yang] and [RFC9094] we can configure the tunnel from the information we have stored in the flexi-grid topology, by querying which elements are available, and planning the resources that have to be provided on each situation, taking into account the global and path-specific WDM tunnel constraints. Note that every element in the flexi-grid topology has a reference, and this is the way in which they are called in the tunnel.¶
Depending on the case, it is possible to define either the source and destination node ports, or the source and destination node and transponder. In our case, we would define a network tunnel, with source transponder A and source node B, and destination transponder E and destination node C. Thus, we are going to follow path x.¶
Then, for each link in the path x, we indicate which channel we are going to use, providing information about the slots, and what nodes are connected.¶
Finally, the flexi-grid topology has to be updated with each element usage status each time a tunnel is created or torn down.¶
The configuration, state, and action data defined in this document are designed to be accessed via a management protocol with a secure transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF users to a preconfigured subset of all available NETCONF protocol operations and content.¶
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
/te:te/te:tunnels/te:tunnel¶
/te:te/.../te:te-bandwidth/te:technology¶
/te:te/.../te:type/te:label/te:label-hop/te:te-label/te:technology¶
/te:te/.../te:label-restrictions/te:label-restriction/te:label- start/te:te-label/te:technology¶
/te:te/.../te:label-restrictions/te:label-restriction/te:label- end/te:te-label/te:technology¶
/te:te/.../te:label-restrictions/te:label-restriction/¶
Editors note: we are using simplified description by folding similar branches to avoid repetition.¶
This document requests IANA to register the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registrations are requested.¶
URI: urn:ietf:params:xml:ns:yang:ietf-wdm-tunnel Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace.¶
This document requests IANA to register the following YANG modules in the "IANA Module Names" [RFC6020]. Following the format in [RFC6020], the following registrations are requested:¶
name: ietf-wdm-tunnel namespace: urn:ietf:params:xml:ns:yang:ietf-wdm-tunnel prefix: wdm-tnl reference: RFC XXXX¶
RFC Editor: Please replace XXXX with the RFC number assigned to this document.¶
This work is also partially funded by the Spanish State Research Agency under the project AgileMon (AEI PID2019-104451RB-C21) and by the Spanish Ministry of Science, Innovation and Universities under the program for the training of university lecturers (Grant number: FPU19/05678).¶