|
|
| |
| 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. |
| Use Cases for PCE as a Central Controller (PCECC). |
|
| draft-ietf-teas-pcecc-use-cases-14.txt |
| Date: |
04/05/2024 |
| Authors: |
Zhenbin Li, Dhruv Dhody, Quintin Zhao, Zekung Ke, Boris Khasanov |
| Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. PCE was developed to derive traffic-engineered paths in MPLS networks, which are supplied to the head end of the paths 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 Label Switched Paths (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 are required for the PCECC use cases are covered in separate documents. |
| A YANG Data Model for requesting path computation |
|
|
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-25.txt |
| Date: |
16/05/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. |
| A Framework for NRP-based Enhanced Virtual Private Network |
|
| draft-ietf-teas-enhanced-vpn-18.txt |
| Date: |
10/05/2024 |
| 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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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. |
| A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies |
|
| draft-ietf-teas-5g-ns-ip-mpls-07.txt |
| Date: |
16/05/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. |
| 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 |
|
|
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 |
|
|
This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". |