]> YANG Data Models for fine grain Optical Transport Network China Unicom
Beijing China tanyx11@chinaunicom.cn
China Unicom
Beijing China zhengyanlei@chinaunicom.cn
Huawei Technologies
italo.busi@huawei.com
Huawei Technologies
China yuchaode@huawei.com
CAICT
China zhaoxing@caict.ac.cn
Routing CCAMP Working Group next generation unicorn sparkling distributed ledger Fine grain Optical Transport Network (fgOTN) is a data plane technology, specified in ITU-T Recommendation G.709/Y.1331 (2020) Amd. 3, which complements existing OTN by providing bandwidth efficient support for sub-1Gbit/s services. This document defines YANG data models to describe the topology and tunnel information of an fgOTN network. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the CCAMP Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction Optical Transport Networks (OTN) is a mainstream layer 1 technology for the transport network. Over the years, it has continued to evolve, to improve its transport functions for the emerging requirements. The topology and tunnel information in the OTN has already been defined by generic traffic-engineering models and technology-specific models, including and . In the latest version of OTN, ITU-T G.709/Y.1331 Edition 6.5 , the fine grain OTN (fgOTN) is introduced for the efficient transmission of low rate client signals (e.g., sub-1G). This document presents the control interface requirements of fgOTN, and defines three YANG data models for fgOTN topology, fgOTN tunnel, and fgOTN types. The topology model can capture topological and resource-related information pertaining to fgOTN. The fgOTN tunnel YANG data model defined in this document is used for the provisioning and management of fgOTN Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs). The fgOTN types model contains a collection of YANG data types considered generally useful for fgOTN networks. Furthermore, this document also imports the generic Layer 1 types defined in . The YANG data models defined in this document conform to the Network Management Datastore Architecture (NMDA) defined in .
Terminology and Notations The following terms are defined in and in and are not redefined here:
  • fgTS: fine grain Tributary Slot.
  • fgODUflex: fine grain Optical channel Data Unit flex.
The following terms are defined in and are not redefined here:
  • client
  • server
  • augment
  • data model
  • data node
The following terms are defined in and are not redefined here:
  • configuration data
  • state data
The terminology for describing YANG data models is found in .
Tree Diagram A simplified graphical representation of the data model is used in of this document. The meaning of the symbols in this diagram is defined in .
Requirements Language 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 when, and only when, they appear in all capitals, as shown here.
Prefixes in Model Names In this documents, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in the following table. Prefixes and corresponding YANG modules
Prefix Yang Module Reference
l1-types ietf-layer1-types [RFC YYYY]
otnt ietf-otn-topology [RFC ZZZZ]
te ietf-te [RFC KKKK]
otn-tnl ietf-otn-tunnel [RFC JJJJ]
fgotnt ietf-fgotn-topology RFC XXXX
fgotn-tnl ietf-fgotn-tunnel RFC XXXX
fgotn-types ietf-fgotn-types RFC XXXX
RFC Editor Note: Please replace XXXX with the number assigned to the RFC once this draft becomes an RFC. Please replace YYYY with the RFC numbers assigned to . Please replace ZZZZ with the RFC numbers assigned to . Please replace KKKK with the RFC numbers assigned to . Please replace JJJJ with the RFC numbers assigned to . Please remove this note.
Fine grain Optical Transport Network Scenarios Overview OTN network will cover a larger scope of networks, it may include the backbone network, metro core, metro aggregation, metro access, and even the OTN CPE in the customers' networks . In general, the metro OTN networks support both fgODUflex and ODUk switching. At the boundary nodes (e.g., metro-core nodes) of the metro OTN networks, the fgODUflexes to other metro OTN networks are multiplexed into ODUk of backbone networks. Therefore, the backbone OTN network could only support ODUk switching. The typical scenarios for fgOTN is to provide low bit rate private line or private network services for customers. The interface function requirements of fgOTN mainly include topology resource reporting and service provisioning. Three scenarios that require special consideration are listed based on the characteristics of fgOTN.
Retrieve Server Tunnels Scenario of fgOTN below shows an example of scenario to retrieve server tunnels for multi-domain fgOTN service. In this example, some small bandwidth fgOTN service are aggregated by the access ring (10G), and then aggregated into a bigger bandwidth in metro ring (100G). The allocation of TS to support fgOTN switching maybe different in access ring and metro ring. All link bandwidth information that supports fgOTN should be reported to MDSC by the PNC controller. E.g. there could be three ODU0 allocated in the access ring while there could be two ODU2 are allocated in the metro ring to support fgOTN switching. In this example, the server layer ODUk tunnel for fgOTN tunnel from node A to node E is ODU0, and the server layer tunnel from node E to node G is ODU2. The server layer tunnel for fgOTN tunnel will include one ODU0 tunnel and one ODU2 tunnel.
The Scenario to Retrieve Server Tunnels A Domain 1 Domain 2 10G B E G I 100G 100G C F H J 10G D
Multi-layer Path Splicing Scenario of fgOTN Some operators that would like to provide the paths when there could be different switching capabilities of nodes in their LSP, so that the MDSC coordinator can clearly display multi-layer paths and the relationship between primary-path and secondary-path. In the current network, not all nodes in the operator network support fgOTN, as shown in figure 2, node f1, f2, f3 and f4 support fgOTN, node N-f5 and node N-f6 do not support fgOTN. To present the end-to-end multi-layer primary-path and secondary-path of the services on the client side, it is necessary to complete the end-to-end path splicing based on the the ODU tunnel information associated with the fgotn tunnel. In , assuming that the server layer ODUk tunnel for the fgOTN primary tunnel from node f1 to node f2 is ODU0, the server layer tunnel from node f2 to node f3 is ODU2, and the server layer tunnel from node f3 to node f4 is ODU1. Assuming the server layer ODUk tunnel for the fgOTN secondary tunnel from node f1 to node f2 is ODU2. We need to setup four server layer ODUk tunnels before setting up an fgODUflex tunnel with a primary path and a secondary path to provide protection. To support multi-layer path splicing, we should make some extension on the dependency tunnel structure or on the path element, such as extending the working roles and index of the tunnels.
Multi-layer Path Splicing Scenario of fgOTN f2 f3 primary-path f1 f4 secondary-path N-f5 N-f6
Hitless Bandwidth Adjustment Scenario of fgOTN defines the data plane procedure to support fgODUflex hitless resizing. The support of management of hitless resizing of fgODUflex needs to be carefully considered. The range of fgOTN service's Bandwidth on Demand (BoD) cannot exceed its server layer's bandwidth. The client needs to know how many bandwidth of a link is allocated for fgOTN. When performs hitless resizing, the client sends the fgODUflex identifier and the target bandwidth to the source node controller. After receiving the network management configuration information, the source node triggers the bandwidth adjustment. During the hitless bandwidth adjustment process, it is necessary to reserve or mark the corresponding bandwidth resources first, and then trigger the bandwidth adjustment actions. Another point to note is that when performing bidirectional hitless resizing for fgODUflex service, the adjustment should be initiated by the client side to a single network management system. Specifically, the adjustment is first performed in the Node 1 to Node 6 direction, and then the reverse direction (Node 6 to Node 1) is automatically triggered for adjustment. For bidirectional hitless resizing, the adjustment shall be regarded as successful only when both directions are completed. If only one direction succeeds while the other fails, the controller may issue a command to perform forced bandwidth adjustment to ensure consistent status in both directions (which may be hit-impairing). When 1+1 protection is configured for fgODUflex, if hitless bandwidth adjustment is performed on fgODUflex, both the working path and the protection path shall initiate the adjustment protocol and signaling transmission. Each node shall check the signaling delivered by both the working path and the protection path simultaneously during state processing. Both single domain and multi-domain hitless resizing should be supported. For single domain and multi-domain hitless resizing scenario, the source controller alone report the bandwidth adjustment status to the MDSC coordinator upon completion.
Hitless Resizing Scenario of fgOTN MDSC Controller Controller Controller 1 2 3 End-to-end fgOTN service node node node node node node 1 2 3 4 5 6 source destination Domain 1 Domain 2 Domain 3 +------+ +------+ +------+ +------+ +------+ +------+ | node +----+ node +-----+ node +----+ node +-----+ node +----+ node | | 1 +----+ 2 +-----+ 3 +----+ 4 +-----+ 5 +----+ 6 | +------+ +------+ | +------+ +------+ | +------+ +------+ source | | destination Domain 1 | Domain 2 | Domain 3 | | ]]>
YANG Data Model for fine grain Optical Transport Network Overview In order to provide fgOTN capabilities, this document defines two extension YANG data models augmenting to OTN topology and OTN tunnel YANG model, as defined in and . As defined in Annex M of , fgOTN is defining a new path layer network which complements the existing OTN. Therefore:
  • A single network topology instance is used to report both OTN and fgOTN topology information: fgOTN technology-specific attributes are therefore defined in the fgOTN topology model as augmentations of the OTN topology model, but without defining a new network type for fgOTN.
  • The OTN tunnel model can be used to setup either an OTN or an fgOTN tunnel: fgOTN technology-specific attributes are therefore defined in the fgOTN tunnel model as augmentations of the OTN tunnel model, which are applicable only when the OTN tunnel is an fgOTN tunnel.
In other words, the same switching-capability and encoding types can be used for ODUk and fgODUflex. Accordingly, additional parameters are required to identify fgODUflex tunnels. This document defines a new YANG module ietf-fgotn-types containing fgOTN-specific type definitions. In order to identify the fgODUflex tunnel, a new identity fgODUflex based on the odu-type in is defined in ietf-fgotn-types YANG module.
YANG Data Model for fgOTN Topology
Fine Grain OTN Topology Data Model Overview This document aims to describe the data model for fine grain OTN topology. The YANG module presented in this document augments from OTN topology data model, i.e., the ietf-otn-topology, as specified in . In section 6 of , the guideline for augmenting OTN topology model was provided, and in this draft, we augment the OTN topology model to describe the topology characteristics of fgOTN. Common types, identities and groupings defined in is reused in this document. defines an abstract (generic, or base) YANG data model for network/service topologies and inventories, and provides the fundamental model for . OTN topology module in augments from the TE topology YANG model defined in . shows the augmentation relationship.
Relationship between fgOTN topology and OTN topology model ietf-network ietf-network-topology Augments ietf-te-topology Augments ietf-otn-topology Augments ietf-fgotn-topology
The entities, TE attributes and OTN attributes, such as nodes, termination points and links, are still applicable for describing an fgOTN topology and the model presented in this document only specifies technology-specific attributes/information. The fgOTN-specific attributes including the fgTS, can be used to represent the bandwidth and label information.
Bandwidth Augmentation Building upon the OTN topology model, the odu-list structure within the OTN topology YANG module is leveraged to represent the maximum link bandwidth and unreserved bandwidth for fgOTN. As an illustration, if an OTU2 port supports fgOTN, fgOTN is enabled across the entire port. In this case, the odu-type shall be set to ietf-fgotn-types:fgODUflex, with the associated number equal to 952. When a portion of fgts on the port is occupied, the value of maximum link bandwidth remains unchanged, while the number representing available bandwidth decreases accordingly.
Label Augmentation The model augments the label-restriction list with fgOTN technology-specific label information using the otn-label-range-info grouping defined in . The fgts-range list is used to describe the availability of fgOTN timeslot in the server ODUk, including the fgts-reserved and fgts-unreserved. The odu-ts-number is used to indicate the index of server ODUk channel.
YANG Data Model for fgOTN Tunnel
Fine Grain OTN Tunnel Data Model Overview This document aims to describe the data model for fgOTN tunnel. The fgOTN tunnel model augments to OTN tunnel with fgOTN-specific parameters, including the bandwidth information and label information. shows the augmentation relationship.
Relationship between fgOTN and OTN tunnel model ietf-te Augments ietf-otn-tunnel Augments ietf-fgotn-tunnel
It's also worth noting that the fgOTN tunnel provisioning is usually based on the fgOTN topology. Therefore the fgOTN tunnel model is usually used together with fgOTN topology model specified in this document. The OTN tunnel model also imports a few type modules, including ietf-layer1-types and ietf-te-types. A new identity based on odu-type should be defined in fgotn-types yang module to indicate the fgODUflex tunnel.
Bandwidth Augmentation The model augment TE bandwidth information of fgOTN tunnel. The fgoduflex-bandwidth leaf specifies the bandwidth of an fgOTN tunnel when the ODU type is fgODUflex. The value is expressed as an integer multiplier of 10 Mbit/s, with a valid range of 1 to 119, corresponding to the fine-granularity bandwidth granularities defined in Table M.3 of .
Label Augmentation The module augments TE label-hop for the explicit route objects included or excluded by the path computation of the primary-paths and secondary-paths using the fgts-numbers. The fgts-numbers specifies the fgTS information for the explicit route objects and computed path properties of fgOTN paths, under the corresponding occurrences of the tet:te-label container. We also augment the TE label-hop for the record route of the LSP using the fgts-numbers. When specifying the fgotn time slot in the routing constraint information, the ODU time slot must also be specified. The ts-list (together with the tsg) represents the time slots assigned to the ODUk server-layer tunnel, while the fgts-numbers represents the fgTSs assigned to the fgOTN client-layer tunnel.
YANG Data Model for fgOTN types The "ietf-fgotn-types" module imports the following modules:
  • "ietf-layer1-types" as defined in
In addition to importing , this module references the following documents in defining its types: .
fgOTN types YANG module
YANG Tree for fgOTN topology below shows the tree diagram of the YANG data model defined in module "ietf-fgotn-topology" ().
YANG Data Model for fgOTN topology The "ietf-fgotn-topology" module imports the following modules:
  • "ietf-network" as defined in
  • "ietf-network-topology" as defined in
  • "ietf-te-topology" as defined in
  • "ietf-layer1-types" as defined in
  • "ietf-otn-topology" as defined in
  • "ietf-fgotn-types" as defined in of this document
fgOTN topology YANG module
YANG Tree for fgOTN tunnel below shows the tree diagram of the YANG data model defined in module "ietf-fgotn-tunnel" ().
YANG Data Model for fgOTN tunnel The "ietf-fgotn-tunnel" module imports the following modules:
  • "ietf-te" as defined in
  • "ietf-otn-tunnel" as defined in
  • "ietf-fgotn-types" as defined in of this document
In addition to importing and , this module references the following documents: .
fgOTN tunnel YANG module
Manageability Considerations <Add any manageability considerations>
Security Considerations This section is modeled after the template described in Section 3.7.1 of . The "ietf-fgotn-topology", "ietf-fgotn-tunnel" and "ietf-fgotn-types" YANG modules define data models that are designed to be accessed via YANG-based management protocols, such as Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication (e.g., for SSH, the SSH Authentication Protocol ). The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:
  • "/nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes/tet:label-restrictions/tet:label-restriction/fgotnt:fgts-range"
  • This subtree specifies the configurations of fgOTN technology-specific label range information for the fgOTN links. By configuring, removing or modifying the fgOTN label attributes, a malicious attacker may cause fgOTN traffic to be disabled or misrouted. Such traffic changes may also affect the traffic on the surrounding fgOTN nodes and fgOTN links in this fgOTN topology and the connected fgOTN topologies.
  • "/te:te/te:tunnels/te:tunnel/te:te-bandwidth/te:technology/otn-tnl:otn/otn-tnl:otn-bandwidth/fgotn-tnl:fgoduflex-bandwidth"
  • This data node represents the bandwidth of the fgOTN tunnel, as described in . By configuring the fgOTN bandwidth attributes, an attacker may create an unauthorized fgOTN traffic path. By removing or modifying it, a malicious attacker may cause fgOTN traffic to be disabled or misrouted.
  • "fgotn-tnl:fgts-numbers"
  • This data node specifies the fgTS information for the explicit route objects and computed path properties of fgOTN paths, under the corresponding occurrences of the tet:te-label container, as defined in (e.g., "/te:te/te:tunnels/te:tunnel/te:primary-paths/te:primary-path/te:explicit-route-objects/te:route-object-include-exclude/te:type/te:label/te:label-hop/te:te-label/te:technology/otnt:otn/otnt:otn-label/fgotn-tnl:fgts-numbers"). By configuring, removing or modifying the fgTS attributes, a malicious attacker may cause fgOTN traffic to be disabled or misrouted.
Some of the readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities:
  • "/nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes/tet:label-restrictions/tet:label-restriction/fgotnt:fgts-range"
  • This subtree specifies the configurations of fgOTN technology-specific label range information for the fgOTN links. Unauthorized access to this subtree can disclose the state information of fgOTN links.
  • "/te:te/te:tunnels/te:tunnel/te:te-bandwidth/te:technology/otn-tnl:otn/otn-tnl:otn-bandwidth/fgotn-tnl:fgoduflex"
  • This data node represents the bandwidth of the fgOTN tunnel, as described in . Unauthorized access to this data node can disclose the fgOTN bandwidth information of fgOTN tunnels and LSPs.
  • "fgotn-tnl:fgts-numbers"
  • This data node specifies the fgTS information for the explicit route objects and computed path properties of fgOTN paths, under the corresponding occurrences of the tet:te-label container, as defined in (e.g., "/te:te/te:tunnels/te:tunnel/te:primary-paths/te:primary-path/te:explicit-route-objects/te:route-object-include-exclude/te:type/te:label/te:label-hop/te:te-label/te:technology/otnt:otn/otnt:otn-label/fgotn-tnl:fgts-numbers"). Unauthorized access to this data node can disclose the state information of fgOTN tunnels and LSPs.
These YANG modules do not define RPC operations. Finally, the YANG modules described in this document augments the "ietf-otn-topology" YANG module and the "ietf-otn-tunnel" YANG module by adding data nodes. The security considerations for the subtrees described in those drafts apply equally to the new data nodes that these modules add.
IANA Considerations IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group : IANA is requested to register the following YANG module in the "YANG Module Names" registry within the "YANG Parameters" registry group.
References Normative References Interfaces for the optical transport network International Telecommunication Union Overview of fine grain OTN International Telecommunication Union A YANG Data Model for Optical Transport Network Topology Huawei Technologies Huawei Technologies Individual Nokia Telefonica This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths Huawei Technologies Huawei Technologies Nokia Nokia CAICT This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. Common YANG Data Types for Layer 1 Networks Huawei Technologies Huawei Technologies This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. Network Management Datastore Architecture (NMDA) Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. The YANG 1.1 Data Modeling Language YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). Network Configuration Protocol (NETCONF) The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG Tree Diagrams This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and Interfaces Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data pertinent to TE tunnels, TE LSPs, and TE interfaces that are independent of any technology or dataplane encapsulation. The model is divided into two YANG modules that address both device-specific and device-independent data, supporting configuration, operational state, Remote Procedure Calls (RPCs), and event notifications. A YANG Data Model for Network Topologies This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. YANG Data Model for Traffic Engineering (TE) Topologies This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility. This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. Network Configuration Access Control Model The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. The IETF XML Registry This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References Guidelines for Authors and Reviewers of Documents Containing YANG Data Models This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. RESTCONF Protocol This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The Secure Shell (SSH) Transport Layer Protocol The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. The Secure Shell (SSH) Authentication Protocol The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] JSON Encoding of Data Modeled with YANG This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.
Multi-domain fgOTN Hitless Resizing Process The process of multi-domain fgOTN hitless resizing include five steps. The source controller alone report the hitless bandwidth adjustment status to the MDSC coordinator. To be noted that, the resizing process is divided into two directions, and the resizing is considered successful when both directions have been adjusted. Step 1: The MDSC coordinator sends an resizing command to the source node (Node1) via Controller 1. Step 2: Controller 1 will report a bandwidth adjustment starting status notification, e.g. ietf-te-types:lsp-bandwidth-modifying, to the MDSC. Step 3: Node 1 to node 6 will modify their configuration in the forward direction through data plane node by node. The detail of this process can reference to Annex O.2 of . Step 4: At the same time, the reverse direction bandwidth resizing will be triggered auotmatically by the data plane in node 6. Controller 3 needs to report an bandwidth adjustment starting status notification, ietf-te-types:lsp-bandwidth-modifying, to the MDSC. Step 5: After the reverse direction (Node 6 to Node 1) resizing is completed, Controller 1 will report an ending status notification, ietf-te-types:lsp-bandwidth-modified-ok, to the MDSC. If the hitless resizing fails, the source controller (i.e., Controller 1) needs to report an bandwidth adjustment failure status notification, ietf-te-types:lsp-bandwidth-modify-failed, to the MDSC coordinator. During the whole process, all domain controllers, including the intermediate domain Controller 2, need to report the notifications of topology and tunnel resource changes to the MDSC.
JSON Examples This appendix contains an example of an instance data tree in JSON encoding . The example instantiates the "ietf-fgotn-topology" model for the OTN topology depicted in below.
Example of fgOTN topology (1) (2) NE2 (2) (2) (1) (1) NE1 NE4 (3) (3) NE3 (1) (2)
In this network example:
  • nodes NE1, NE2, and NE4 support fgOTN switching, while node NE3 does not support fgOTN;
  • all the links are OTU2 links
The topology examples, show how the topology changes in three different steps:
  1. No OTN or fgOTN tunnels are setup in the network;
  2. The following ODUk tunnels are setup as server layer tunnels to support fgOTN tunnels:
    • an ODU1 server layer tunnel between NE1 and NE2;
    • two ODU0 server layer tunnels between NE2 and NE4;
    • one ODU1 server layer tunnel between NE1 and NE4 (through the NE1-NE3-NE4 path)
  3. The following fgOTN tunnels are setup in the network:
    • a 20M protected fgOTN tunnel between NE1 and NE4 with:
      • a working path setup through the NE1-NE2 ODU1 tunnel and the NE2-NE4 ODU0 tunnel;
      • a protectin path setup through the NE1-NE3-NE4 ODU1 tunnel;
    • a 20M unprotected fgOTN tunnel through the same NE2-NE4 ODU0 server layer tunnel used by the other fgOTN tunnel above.
The example also instantiates the "ietf-fgotn-tunnel" model to setup two fgOTN tunnel within the fgOTN topology shown in . -an 20M protected fgOTN tunnel between NE1 and NE4. The protected fgODUflex tunnel has a primary LSP, instatiating the NE1-NE2-NE4 primary TE and a secondary LSP, instantiating the NE1-NE3-NE4 secondary TE path. -an 20M unprotected fgOTN tunnel between NE2-NE4. The unprotected fgODUflex tunnel has a primary LSP, instatiating the NE2-NE4 primary TE path.
Acknowledgments The authors would like to thank Adrian Farrel and Daniel King for their valuable comments and suggestions on this document.
Contributors China Unicom
Beijing China wangzl172@chinaunicom.cn
Huawei Technologiesicom
aihuaguo.ietf@gmail.com
Fiberhome Telecommunication Technologies Co.,LTD
lich@fiberhome.com