Traffic Engineering Architecture and Signaling (teas) Internet Drafts

	A YANG Data Model for Resource Reservation Protocol (RSVP)
	draft-ietf-teas-yang-rsvp-19.txt   Date: 28/02/2024   Authors: Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document defines a YANG data model for the configuration and management of the RSVP protocol. The YANG data model covers the building blocks that may be augmented by other RSVP extension data models such as RSVP Traffic-Engineering (RSVP-TE). It is divided into two modules that cover the basic and extended RSVP features.
	A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths and Interfaces
	draft-ietf-teas-yang-te-36.txt   Date: 02/02/2024   Authors: Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin   Working Group: Traffic Engineering Architecture and Signaling (teas)	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 that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications.
	The Use Cases for Path Computation Element (PCE) as a Central Controller (PCECC).
	draft-ietf-teas-pcecc-use-cases-13.txt   Date: 08/01/2023   Authors: Zhenbin Li, Dhruv Dhody, Quintin Zhao, Zekung Ke, Boris Khasanov   Working Group: Traffic Engineering Architecture and Signaling (teas)	The Path Computation Element (PCE) is a core component of a Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and update paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a much broader applicability than signal MPLS traffic- engineered (TE) paths, and the PCE may be used to determine paths in a range of use cases including static LSPs, Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions which required for the PCECC use cases are covered in separate documents.
	A YANG Data Model for requesting path computation
	draft-ietf-teas-yang-path-computation-22.txt   Date: 14/02/2024   Authors: Italo Busi, Sergio Belotti, Oscar de Dios, Anurag Sharma, Yan Shi   Working Group: Traffic Engineering Architecture and Signaling (teas)	There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed.
	YANG Data Model for Layer 3 TE Topologies
	draft-ietf-teas-yang-l3-te-topo-16.txt   Date: 02/03/2024   Authors: Xufeng Liu, Igor Bryskin, Vishnu Beeram, Tarek Saad, Himanshu Shah, Oscar de Dios   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document defines a YANG data model for layer 3 traffic engineering topologies.
	A YANG Data Model for Virtual Network (VN) Operations
	draft-ietf-teas-actn-vn-yang-24.txt   Date: 16/03/2024   Authors: Young Lee, Dhruv Dhody, Daniele Ceccarelli, Igor Bryskin, Bin Yoon   Working Group: Traffic Engineering Architecture and Signaling (teas)	A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per Abstraction and Control of TE Networks (ACTN) framework.
	SF Aware TE Topology YANG Model
	draft-ietf-teas-sf-aware-topo-model-12.txt   Date: 08/11/2023   Authors: Igor Bryskin, Xufeng Liu, Young Lee, Jim Guichard, Luis Contreras, Daniele Ceccarelli, Jeff Tantsura, Dmytro Shytyi   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document describes a YANG data model for TE network topologies that are network service and function aware.
	A Framework for NRP-based Enhanced Virtual Private Network
	draft-ietf-teas-enhanced-vpn-17.txt   Date: 25/12/2023   Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka, Young Lee   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document describes the framework for NRP-based Enhanced Virtual Private Networks (VPNs) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). NRP-based Enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and adds characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers, and identifies some areas for potential new work.
	Traffic Engineering (TE) and Service Mapping YANG Data Model
	draft-ietf-teas-te-service-mapping-yang-15.txt   Date: 16/03/2024   Authors: Young Lee, Dhruv Dhody, Giuseppe Fioccola, Qin WU, Daniele Ceccarelli, Jeff Tantsura   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resource and TE models.
	Interworking of GMPLS Control and Centralized Controller Systems
	draft-ietf-teas-gmpls-controller-inter-work-13.txt   Date: 08/02/2024   Authors: Haomian Zheng, Yi Lin, Yang Zhao, Yunbin Xu, Dieter Beller   Working Group: Traffic Engineering Architecture and Signaling (teas)	Generalized Multi-Protocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing and signaling in a distributed manner. On the other hand, with the development of software-defined transport networking technology, a set of NEs can be controlled via centralized controller hierarchies to address the issues from multi- domain, multi-vendor, and multi-technology. An example of such centralized architecture is Abstraction and Control of Traffic Engineered Networks (ACTN) controller hierarchy described in RFC 8453. Instead of competing with each other, both the distributed and the centralized control plane have their own advantages, and should be complementary in the system. This document describes how the GMPLS distributed control plane can interwork with a centralized controller system in a transport network.
	YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics
	draft-ietf-teas-actn-pm-telemetry-autonomics-12.txt   Date: 16/03/2024   Authors: Young Lee, Dhruv Dhody, Ricard Vilalta, Daniel King, Daniele Ceccarelli   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document provides YANG data models that describe performance monitoring parameters and scaling intent mechanisms for TE-tunnels and Virtual Networks (VNs). There performance monitoring parameters are exposed as the key telemetry data for tunnels and VN. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN.
	Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)
	draft-ietf-teas-actn-poi-applicability-11.txt   Date: 22/02/2024   Authors: Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI)in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture.
	Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing
	draft-ietf-teas-applicability-actn-slicing-06.txt   Date: 17/03/2024   Authors: Daniel King, John Drake, Haomian Zheng, Adrian Farrel   Working Group: Traffic Engineering Architecture and Signaling (teas)	Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN, and indicates where ACTN might be extended.
	A YANG Data Model for the RFC 9543 Network Slice Service
	draft-ietf-teas-ietf-network-slice-nbi-yang-11.txt   Date: 24/04/2024   Authors: Bo Wu, Dhruv Dhody, Reza Rokui, Tarek Saad, John Mullooly   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services.
	Realizing Network Slices in IP/MPLS Networks
	draft-ietf-teas-ns-ip-mpls-03.txt   Date: 26/11/2023   Authors: Tarek Saad, Vishnu Beeram, Jie Dong, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, Luis Contreras, Reza Rokui, Luay Jalil   Working Group: Traffic Engineering Architecture and Signaling (teas)	Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets.
	Common YANG Data Types for Traffic Engineering
	draft-ietf-teas-rfc8776-update-10.txt   Date: 22/02/2024   Authors: Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776.
	Scalability Considerations for Network Resource Partition
	draft-ietf-teas-nrp-scalability-04.txt   Date: 04/03/2024   Authors: Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra   Working Group: Traffic Engineering Architecture and Signaling (teas)	A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC XXXX describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms.
	IETF Network Slice Application in 3GPP 5G End-to-End Network Slice
	draft-ietf-teas-5g-network-slice-application-02.txt   Date: 23/10/2023   Authors: Xuesong Geng, Luis Contreras, Reza Rokui, Jie Dong, Ivan Bykov   Working Group: Traffic Engineering Architecture and Signaling (teas)	Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slices have to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in management plane, control plane and data plane.
	A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies
	draft-ietf-teas-5g-ns-ip-mpls-04.txt   Date: 19/03/2024   Authors: Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, Mohamed Boucadair, Luis Contreras   Working Group: Traffic Engineering Architecture and Signaling (teas)	Slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a Network Slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks.
	IETF Network Slice Controller and its associated data models
	draft-ietf-teas-ns-controller-models-01.txt   Date: 23/10/2023   Authors: Luis Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu, Dhruv Dhody, Sergio Belotti   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document describes a potential division in major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slice services and their realization. This document describes a potential way of structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller.
	YANG Data Models for Network Resource Partitions (NRPs)
	draft-ietf-teas-nrp-yang-01.txt   Date: 16/03/2024   Authors: Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng   Working Group: Traffic Engineering Architecture and Signaling (teas)	RFC 9543 describes a framework for Network Slice in a network built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of network slice service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines YANG data models for Network Resource Partitions (NRPs), applicable to devices and network controllers. The models can be used, in particular, for the realization of the RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR) networks.
	A YANG Data Model for MPLS-TE Topology
	draft-ietf-teas-yang-te-mpls-topology-00.txt   Date: 18/03/2024   Authors: Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Rakesh Gandhi   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies.
	Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases
	draft-ietf-teas-te-topology-profiles-01.txt   Date: 19/04/2024   Authors: Italo Busi, Xufeng Liu, Igor Bryskin, Tarek Saad, Oscar de Dios   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering".

data-group-menu-data-url="/group/groupmenu.json"> Skip to main content

    a) Traffic-engineering architectures for generic
       applicability across packet and non-packet
       networks. This includes, for example, networks that
       perform centralized computation and control, distributed
       computation and control, or even a hybrid approach.

    b) Definition of protocol-independent metrics and
       parameters (measurement and/or service attributes) for
       describing links and tunnels/paths required for traffic
       engineering (and related routing, signaling and path
       computation). These will be developed in conjunction
       with requests and requirements from other WGs to ensure
       overall usefulness.

    c) Functional specification of extensions for routing
       (OSPF, ISIS) and for path computation (PCEP), including
       those that provide general enablers of
       traffic-engineering systems that may also use
       RSVP-TE. Protocol formats and procedures that embody
       these extensions will be done in coordination with the
       WGs supervising those protocols.

    d) Functional specification of generic (i.e., not data
       plane technology-specific) extensions for RSVP-TE, and
       the associated protocol formats and procedures that
       embody these extensions.

    e) Definition of control plane mechanisms and extensions to
       allow the setup and maintenance of TE paths and TE
       tunnels that span multiple domains and/or switching
       technologies, where a domain may be an IGP area, an
       Autonomous System, or any other region of topological
       visibility.

    f) Definition and extension of management and security
       techniques for TE path and tunnel control. This
       includes configuring and monitoring RSVP-TE as well as
       mechanisms used to configure, control, and report OAM
       within TE networks. YANG and MIB modules may be
       considered.

    1. Definition of additional abstract service, link, and
       path properties such as jitter, delay, and
       diversity. Extensions to IGPs to advertise these
       properties, and extensions to RSVP-TE to request and to
       accumulate these properties. Work with PCE WG to include
       these properties in computation requests.

    2. Specification of terminology, architecture, and protocol
       requirements for abstraction and distribution of TE
       information between interconnected TE domains/layers.

    3. Specification and protocol extensions for a GMPLS
       External Network-to-Network Interface (E-NNI), i.e.,
       multi-domain GMPLS support.

    4. Protocol mechanisms to signal associated LSPs in
       particular with different source nodes.

    5. Requirements and protocol extensions for additional
       protection mechanisms including, for example, end-point
       protection, protection of P2MP LSPs, and inter-domain
       protection.

    6. YANG models in support of Traffic Engineering, in
       coordination with working groups working on YANG models
       for network topology and for technology-specific network
       attributes.

    - With the MPLS WG to maintain and extend MPLS-TE protocol
      mechanisms and to determine whether they should be
      generalized.

    - With the CCAMP WG to maintain and extend non-packet, data
      plane technology-specific TE protocol mechanisms and to
      determine whether they should be generalized.

    - With the LSR (OSPF and ISIS) WG to maintain or extend TE
      routing mechanisms.

    - With the PCE WG on uses of a PCE in the
      traffic-engineering architecture, on PCE extensions per
      the above, and on RSVP-TE extensions to support PCE WG
      identified requirements.

    - With the IDR WG on the use of BGP-LS in TE environments.

    - With the DetNet WG on mechanisms (YANG models and
      protocols) to support DetNets.

    - With the SPRING WG on TE architecture and, where
      appropriate, TE-related protocol extensions.

    - With the SFC WG on mechanisms (YANG models and protocols) to
      support SFCs