Huawei

jie.dong@huawei.com

University of Surrey

stewart.bryant@gmail.com

China Mobile

lizhenqiang@chinamobile.com

KDDI Corporation

ta-miyasaka@kddi.com

Samsung

younglee.tx@gmail.com

RTG teas network slicing traffic engineering performance guarantee This document describes a framework for Enhanced Virtual Private Networks (VPNs) based on Network Resource Partitions (NRPs) in order 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 add 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 it 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.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 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 () 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

• .  Introduction
• .  Terminology
• .  Overview of the Requirements
  • .  Performance Guarantees
  • .  Interaction Between Enhanced VPN Services
    • .  Requirements on Traffic Isolation
    • .  Limited Interaction with Other Services
    • .  Realization of Limited Interaction with Enhanced VPN Services
  • .  Integration with Network Resources and Service Functions
    • .  Abstraction
  • .  Dynamic Changes
  • .  Customized Control
  • .  Applicability to Overlay Technologies
  • .  Inter-Domain and Inter-Layer Network
• .  The Architecture of NRP-Based Enhanced VPNs
  • .  Layered Architecture
  • .  Connectivity Types
  • .  Application-Specific Data Types
  • .  Scalable Service Mapping
• .  Candidate Technologies
  • .  Underlay Forwarding Resource Partitioning
    • .  Flex Ethernet
    • .  Dedicated Queues
    • .  Time-Sensitive Networking
  • .  Network Layer Encapsulation and Forwarding
    • .  Deterministic Networking (DetNet)
    • .  MPLS Traffic Engineering (MPLS-TE)
    • .  Segment Routing
    • .  New Encapsulation Extensions
  • .  Non-Packet Data Plane
  • .  Control Plane
  • .  Management Plane
  • .  Applicability of Service Data Models to Enhanced VPNs
• .  Applicability in Network Slice Realization
  • .  NRP Planning
  • .  NRP Creation
  • .  Network Slice Service Provisioning
  • .  Network Slice Traffic Steering and Forwarding
• .  Scalability Considerations
  • .  Maximum Stack Depth of SR
  • .  RSVP-TE Scalability
  • .  SDN Scaling
• .  Enhanced Resiliency
• .  Manageability Considerations
  • .  OAM Considerations
  • .  Telemetry Considerations
• . Operational Considerations
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction Virtual Private Networks (VPNs) have served the industry well as a means of providing different groups of users with logically isolated connectivity over a common network. The common (base) network that is used to provide the VPNs is often referred to as the "underlay", and the VPN is often called an "overlay". Customers of a network operator may request connectivity services with advanced characteristics, such as low-latency guarantees, bounded jitter, or isolation from other services or customers, so that changes in other services (e.g., changes in network load, or events such as congestion or outages) have no effect or only acceptable effects on the observed throughput or latency of the services delivered to the customer. These services are referred to as "enhanced VPNs", as they are similar to VPN services, providing the customer with the required connectivity, but they also provide enhanced characteristics. This document describes a framework for delivering VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc. This list is not exhaustive. It is expected that other enhanced features may be added to VPN over time and that this framework will support these additions with necessary changes or enhancements in some network layers and network planes (data plane, control plane, and management plane). The concept of network slicing has gained traction, driven largely by needs surfacing from 5G (see , , and ). According to , a 5G end-to-end network slice consists of three major types of network segments: Radio Access Network (RAN), Transport Network (TN), and mobile Core Network (CN). The transport network provides the connectivity between different entities in RAN and CN segments of a 5G end-to-end network slice, with specific performance commitments. discusses the general framework, components, and interfaces for requesting and operating network slices using IETF technologies. These network slices may be referred to as "RFC 9543 Network Slices", but in this document (which is solely about IETF technologies), we simply use the term "network slice" to refer to this concept. A network slice service enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. A network slice can be realized as a logical network connecting a number of endpoints and is associated with a set of shared or dedicated network resources that are used to satisfy the SLO and SLE requirements. A network slice is considered to be one target use case of enhanced VPNs. also introduces the concept of NRP, which is a subset of the buffer/queuing/scheduling resources and associated policies on each of a connected set of links in the underlay network. An NRP can be associated with a dedicated or shared network topology to select or specify the set of links and nodes involved. The requirements of enhanced VPN services cannot simply be met by overlay networks: enhanced VPN services require tighter coordination and integration between the overlay and the underlay networks. In the overlay network, the VPN has been defined as the network construct to provide the required connectivity for different services or customers. Multiple VPN flavors can be considered to create that construct . In the underlay network, the NRP is used to represent a subset of the network resources and associated policies in the underlay network. An NRP can be associated with a dedicated or shared network topology to select or specify the set of links and nodes involved. An enhanced VPN service can be realized by integrating a VPN in the overlay and an NRP in the underlay. This is called an "NRP-based enhanced VPN". In doing so, an enhanced VPN service can provide enhanced properties, such as guaranteed resources and assured or predictable performance. An enhanced VPN service may also involve a set of service functions (see for the definition of service function). The techniques for delivering an NRP-based enhanced VPN can be used to instantiate a network slice service (as described in ), and they can also be of use in general cases to provide enhanced connectivity services between customer sites or service endpoints. This document describes a framework for using existing, modified, and potential new technologies as components to provide NRP-based enhanced VPN services. Specifically, this document provides:

• The functional requirements and service characteristics of an enhanced VPN service.
• The design of the data plane for NRP-based enhanced VPNs.
• The necessary control and management protocols in both the underlay and the overlay of enhanced VPNs.
• The mechanisms to achieve integration between the overlay network and the underlay network.
• The necessary Operation, Administration, and Maintenance (OAM) methods to instrument an enhanced VPN to make sure that the required Service Level Agreement (SLA) between the customer and the network operator is met and to take any corrective action (such as switching traffic to an alternate path) to avoid SLA violation.

One possible layered network structure to achieve these objectives is shown in . It is not envisaged that enhanced VPN services will replace conventional VPN services. VPN services will continue to be delivered using existing mechanisms and can coexist with enhanced VPN services. Whether enhanced VPN features are added to an active VPN service is deployment specific.

Terminology In this document, the relationship of the four terms "VPN", "enhanced VPN", "NRP", and "Network Slice" are as follows:

• A Virtual Private Network (VPN) refers to the overlay network service that provides connectivity between different customer sites and that maintains traffic separation between different customers. Examples of technologies to provide VPN services are as follows: IP VPN , L2VPN , and EVPN .
• An enhanced VPN service is an evolution of the VPN service that makes additional service-specific commitments. An NRP-based enhanced VPN is made by integrating a VPN with a set of network resources allocated in the underlay network (i.e., an NRP).
• An NRP, as defined in , is a subset of the buffer/queuing/scheduling resources and associated policies on each of a connected set of links in the underlay network. An NRP can be associated with a dedicated or shared network topology to select or specify the set of links and nodes involved. An NRP is designed to meet the network resources and performance characteristics required by the enhanced VPN services.
• A network slice service could be delivered by provisioning one or more NRP-based enhanced VPNs in the network. Other mechanisms for realizing network slices may exist but are not in the scope of this document.

The term "tenant" is used in this document to refer to a customer of the enhanced VPN services. The following terms, defined in other documents, are also used in this document.

SLA:

Service Level Agreement (see )

SLO:

Service Level Objective (see )

SLE:

Service Level Expectation (see )

ACTN:

Abstraction and Control of TE Networks (see )

DetNet:

Deterministic Networking (see )

FlexE:

Flex Ethernet (see )

TSN:

Time-Sensitive Networking (see )

VN:

Virtual Network (see )

Overview of the Requirements This section provides an overview of the requirements of an enhanced VPN service.

Performance Guarantees Performance guarantees are committed by network operators to their customers in relation to the services delivered to the customers. They are usually expressed in SLAs as a set of SLOs. There are several kinds of performance guarantees, including guaranteed maximum packet loss, guaranteed maximum delay, and guaranteed delay variation. Note that these guarantees apply to conformance traffic; out-of-profile traffic will be handled according to a separate agreement with the customer (see, for example, ). Guaranteed maximum packet loss is usually addressed by setting packet priorities, queue sizes, and discard policies. However, this becomes more difficult when the requirement is combined with latency requirements. The limiting case is zero congestion loss, and that is the goal of DetNet and Time-Sensitive Networking (TSN) . In modern optical networks, loss due to transmission errors already approaches zero, but there is the possibility of failure of the interface or the fiber itself. This type of fault can be addressed by some form of signal duplication and transmission over diverse paths. Guaranteed maximum latency is required by a number of applications, particularly real-time control applications and some types of augmented reality and virtual reality (AR/VR) applications. DetNet techniques may be considered ; however, additional methods of enhancing the underlay to better support the delay guarantees may be needed. These methods will need to be integrated with the overall service provisioning mechanisms. Guaranteed maximum delay variation is a performance guarantee that may also be needed. calls up a number of cases that need this guarantee, for example, in electrical utilities. Time transfer is an example service that needs this performance guarantee, although it is in the nature of time that the service might be delivered by the underlay as a shared service and not provided through different enhanced VPNs. Alternatively, a dedicated enhanced VPN might be used to provide time transfer as a shared service. This suggests that a spectrum of service guarantees needs to be considered when designing and deploying an enhanced VPN. For illustration purposes and without claiming to be exhaustive, four types of services are considered:

• Best effort
• Assured bandwidth
• Guaranteed latency
• Enhanced delivery

It is noted that some services may have mixed requirements from this list, e.g., both assured bandwidth and guaranteed latency can be required. The best-effort service is the basic connectivity service that can be provided by current VPNs. An assured bandwidth service is a connectivity service in which the bandwidth over some period of time is assured. This could be achieved either simply based on a best-effort service with over-capacity provisioning or based on MPLS TE Label Switching Paths (TE-LSPs) with bandwidth reservations. Depending on the technique used, however, the bandwidth is not necessarily assured at any instant. Providing assured bandwidth to VPNs, for example, by using per-VPN TE-LSPs, is not widely deployed at least partially due to scalability concerns. The more common approach of aggregating multiple VPNs onto common TE-LSPs results in shared bandwidth and so may reduce the assurance of bandwidth to any one service. Enhanced VPNs aim to provide a more scalable approach for such services. A guaranteed latency service has an upper bound to edge-to-edge latency. Assuring the upper bound is sometimes more important than minimizing latency. There are several new technologies that provide some assistance with this performance guarantee:

• the IEEE TSN project introduces the concept of scheduling of delay-sensitive and loss-sensitive packets.
• FlexE is useful to help provide a guaranteed upper bound to latency.
• DetNet is of relevance in assuring an upper bound of end-to-end packet latency in the network layer.

The use of these technologies to deliver enhanced VPN services needs to be considered when a guaranteed latency service is required. An enhanced delivery service is a connectivity service in which the underlay network (at Layer 3) needs to ensure to eliminate or minimize packet loss in the event of equipment or media failures. This may be achieved by delivering a copy of the packet through multiple paths. Such a mechanism may need to be used for enhanced VPN services.

Interaction Between Enhanced VPN Services There is a fine distinction between how a customer requests limits on interaction between an enhanced VPN service and other services (whether they are other enhanced VPN services or any other network service) and how that is delivered by the service provider. This section examines the requirements and realization of limited interaction between an enhanced VPN service and other services.

Requirements on Traffic Isolation "Traffic isolation" is a generic term that can be used to describe the requirements for separating the services of different customers or different service types in the network. In the context of network slicing, traffic isolation is defined as an SLE of the network slice service (), which is one element of the SLA. A customer may care about disruption caused by other services, contamination by other traffic, or delivery of their traffic to the wrong destinations. A customer may want to specify (and thus pay for) the traffic isolation provided by the service provider. Some customers (banking, for example) may have strict requirements on how their flows are handled when delivered over a shared network. Some professional services are used to relying on specific certifications and audits to ensure the compliancy of a network with traffic-isolation requirements and, specifically, to prevent data leaks. With traffic isolation, a customer expects that the service traffic cannot be received by other customers in the same network. In , traffic isolation is mentioned as one of the requirements of VPN customers. Traffic isolation is also described in . There can be different expectations of traffic isolation. For example, a customer may further request the protection of their traffic by requesting specific encryption schemes at the enhanced VPN access and also when transported between Provider Edge (PE) nodes. An enhanced VPN service customer may request traffic isolation together with other operator-defined service characteristics. The exact details about the expected behavior need to be specified in the service request so that meaningful service assurance and fulfillment feedback can be exposed to the customer. It is out of the scope of this document to elaborate the service-modeling considerations.

Limited Interaction with Other Services describes the controlled-load service. In that document, the end-to-end behavior provided to an application by a series of network elements providing controlled-load service is described as closely approximating to the behavior visible to applications receiving best-effort service when those network elements are not carrying substantial traffic from other services. Thus, a consumer of a controlled-load service may assume that:

• A very high percentage of transmitted packets will be successfully delivered by the network to the receiving end nodes.
• The transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transmit delay experienced by any successfully delivered packet.

An enhanced VPN customer may request a controlled-load service in one of two ways:

1. It may configure a set of SLOs (for example, for delay and loss) such that the delivered enhanced VPN meets the behavioral objectives of the customer.
2. As described in , a customer may request the controlled-load service without reference to or specification of specific target values for control parameters such as delay or loss. Instead, acceptance of a request for controlled-load service is defined to imply a commitment by the network element to provide the requestor with service closely equivalent to that provided to uncontrolled (best-effort) traffic under lightly loaded conditions. This way of requesting the service is an SLE.

Limited interaction between enhanced VPN services does not cover service degradation due to non-interaction-related causes, such as link errors.

Realization of Limited Interaction with Enhanced VPN Services A service provider may translate the requirements related to limited interaction into distinct engineering rules in its network. Honoring the service requirement may involve tweaking a set of QoS, TE, security, and planning tools, while traffic isolation will involve adequately configuring routing and authorization capabilities. Concretely, there are many existing techniques that can be used to provide traffic isolation, such as IP and MPLS VPNs or other multi-tenant virtual network techniques. Controlled-load services may be realized as described in . Other tools may include various forms of resource management and reservation techniques, such as network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing in using shared network resources, etc., so that a subset of bandwidth, buffers, and queueing resources can be available in the underlay network to support the enhanced VPN services. To provide the required traffic isolation, or to reduce the interaction with other enhanced VPN services, network resources may need to be reserved in the data plane of the underlay network and dedicated to traffic from a specific enhanced VPN service or a specific group of enhanced VPN services. This may introduce scalability concerns in the implementation, as each enhanced VPN may need to be tracked in the network. It may also introduce scalability concerns in deployment, such as how many resources need to be reserved and how the services are mapped to the resources (). Thus, some trade-off needs to be considered to provide the traffic isolation and limited interaction between an enhanced VPN service and other services. A dedicated physical network can be used to meet stricter SLO and SLE requests, at the cost of allocating resources on a long-term and end- to-end basis. On the other hand, where adequate traffic isolation and limited interaction can be achieved at the packet layer, this permits the resources to be shared amongst a group of services and only dedicated to a service on a temporary basis. By combining conventional VPNs with TE, QoS, and security techniques, an enhanced VPN offers a variety of means to honor customer's requirements.

Integration with Network Resources and Service Functions The way to meet the enhanced VPN service's demand for certain characteristics (such as guaranteed or predictable performance) is by integrating the overlay VPN with a particular set of resources in the underlay network that are allocated to meet the service requirements. This needs to be done in a flexible and scalable way so that it can be widely deployed in operators' networks to support a good number of enhanced VPN services. Taking mobile networks and, in particular, 5G into consideration, the integration of the network with service functions is likely a requirement. The IETF's work on Service Function Chaining (SFC) provides a foundation for this. Service functions in the underlay network can be considered to be part of the enhanced VPN services, which means the service functions may need to be an integral part of the corresponding NRP. The details of the integration between service functions and enhanced VPNs are out of the scope of this document.

Abstraction Integration of the overlay VPN and the underlay network resources and service functions does not always need to be a direct mapping. As described in , abstraction is the process of applying policy to a set of information about a traffic-engineered network to produce selective information that represents the potential ability to connect across the network. The process of abstraction presents the connectivity graph in a way that is independent of the underlying network technologies, capabilities, and topology so that the graph can be used to plan and deliver network services in a uniform way. Using the abstraction approach, an enhanced VPN may be built on top of an abstracted topology that represents the connectivity capabilities of the underlay TE-based network as described in the framework for Abstraction and Control of TE Networks (ACTN) as discussed further in .

Dynamic Changes Enhanced VPNs need to be created, modified, and removed from the network according to service demands (including scheduled requests). An enhanced VPN that requires limited interaction with other services () must not be disrupted by the instantiation or modification of another enhanced VPN service. As discussed in , the assessment of traffic isolation is part of the management of a VPN service. Determining whether modification of an enhanced VPN can be disruptive to that enhanced VPN and whether the traffic in flight will be disrupted can be a difficult problem. Dynamic changes both to the enhanced VPN and to the underlay network need to be managed to avoid disruption to services that are sensitive to changes in network performance. In addition to managing the network without disruption during changes such as the inclusion of a new enhanced VPN service endpoint or a change to a link, enhanced VPN traffic might need to be moved because of changes to traffic patterns and volume. This means that during the lifetime of an enhanced VPN service, closed-loop optimization is needed so that the delivered service always matches the ordered SLA. The data plane aspects of this problem are discussed further in Sections , , and . The control plane aspects of this problem are discussed further in . The management plane aspects of this problem are discussed further in .

Customized Control In many cases enhanced VPN services are delivered to customers without information about the underlying NRPs. However, in some cases, depending on the agreement between the operator and the customer, the customer may also be provided with some information about the underlying NRPs. Such information can be filtered or aggregated according to the operator's policy. This allows the customer of an enhanced VPN service to have some visibility and even control over how the underlying topology and resources of the NRP are used. For example, the customer may be able to specify the path or path constraints within the NRP for specific traffic flows of their enhanced VPN service. Depending on the requirements, an enhanced VPN customer may have their own network controller, which may be provided with an interface to the control or management system run by the network operator. Note that such a control is within the scope of the customer's enhanced VPN service; any additional changes beyond this would require some intervention by the network operator. A description of the control plane aspects of this problem are discussed further in . A description of the management plane aspects of this feature can be found in .

Applicability to Overlay Technologies The concept of an enhanced VPN can be applied to any existing and future multi-tenancy overlay technologies including but not limited to:

• Layer 2 point-to-point (P2P) services, such as pseudowires (see )
• Layer 2 VPNs (see )
• Ethernet VPNs (see and )
• Layer 3 VPNs (see and )

Where such VPN service types need enhanced isolation and delivery characteristics, the technologies described in can be used to tweak the underlay to provide the required enhanced performance.

Inter-Domain and Inter-Layer Network In some scenarios, an enhanced VPN service may span multiple network domains. A domain is considered to be any collection of network elements under the responsibility of the same administrative entity, for example, an Autonomous System (AS). In some domains, the network operator may manage a multi-layered network, for example, a packet network over an optical network. When enhanced VPN services are provisioned in such network scenarios, the technologies used in different network planes (the data plane, control plane, and management plane) need to provide mechanisms to support multi-domain and multi-layer coordination and integration; this is to provide the required service characteristics for different enhanced VPN services and improve network efficiency and operational simplicity. The mechanisms for multi-domain VPNs (see ) may be reused, and some enhancement may be needed to meet the additional requirements of enhanced VPN services.

The Architecture of NRP-Based Enhanced VPNs Multiple NRP-based enhanced VPN services can be provided by a common network infrastructure. Each NRP-based enhanced VPN service is provisioned with an overlay VPN and mapped to a corresponding NRP, which has a specific set of network resources and service functions allocated in the underlay to satisfy the needs of the customer. One NRP may support one or more NRP-based enhanced VPN services. The integration between the overlay connectivity and the underlay resources ensures the required isolation between different enhanced VPN services and achieves the guaranteed performance for different customers. The NRP-based enhanced VPN architecture needs to be designed with consideration given to:

• An enhanced data plane.
• A control plane to create enhanced VPNs and NRPs, making use of the data plane isolation and performance guarantee techniques.
• A management plane to manage enhanced VPN service life cycles.
• The OAM mechanisms for enhanced VPNs and the underlying NRPs.
• Telemetry mechanisms for enhanced VPNs and the underlying NRPs.

These topics are expanded below.

• The enhanced data plane provides:
  • The required packet-latency and jitter characteristics.
  • The required packet-loss characteristics.
  • The required resource-isolation capability, e.g., bandwidth guarantee.
  • The mechanism to associate a packet with the set of resources allocated to an NRP to which the enhanced VPN service packet is mapped.
• The control plane:
  • Collects information about the underlying network topology and network resources and exports this to network nodes and/or a centralized controller as required.
  • Creates NRPs with the network resource and topology properties needed by the enhanced VPN services.
  • Distributes the attributes of NRPs to network nodes that participate in the NRPs and/or a centralized controller.
  • Computes and sets up network paths in each NRP.
  • Maps enhanced VPN services to an appropriate NRP.
  • Determines the risk of SLA violation and takes appropriate avoidance/correction actions.
  • Considers the right balance of per-packet and per-node state according to the needs of the enhanced VPN services to scale to the required size.
• The management plane includes management interfaces, the OAM and telemetry mechanisms. More specifically, it provides:
  • An interface between the enhanced VPN service provider (e.g., the operator's network management system) and the enhanced VPN customer (e.g., an organization or service with an enhanced VPN requirement) such that the requests for specific operations and the related parameters can be exchanged without the awareness of other enhanced VPN customers.
  • An interface between the enhanced VPN service provider and the enhanced VPN customers to expose the network capability information toward the customer.
  • The service life-cycle management and operation of enhanced VPN services (e.g., creation, modification, assurance/monitoring, and decommissioning).
  • The OAM tools to verify whether the underlay network resources (i.e., NRPs) are correctly allocated and operating properly.
  • The OAM tools to verify the connectivity and monitor the performance of the enhanced VPN service.
  • Telemetry of information in the underlay network for overall performance evaluation and the planning of the enhanced VPN services.
  • Telemetry of information of enhanced VPN services for monitoring and analytics of the characteristics and SLA fulfillment of the enhanced VPN services.

Layered Architecture The layered architecture of NRP-based enhanced VPNs is shown in . Underpinning everything is the physical network infrastructure layer, which provides the underlying resources used to provision the separate NRPs. This layer is responsible for the partitioning of link and/or node resources for different NRPs. Each subset of a link or node resource can be considered to be a virtual link or virtual node used to build the NRPs.

The Layered Architecture of Enhanced VPNs /\ || +-------------------+ Centralized | Network Controller| Control & Management +-------------------+ || \/ o---------------------------o Enhanced VPN #1 /-------------o o____________/______________o Enhanced VPN #2 _________________o _____/ o___/ \_________________o Enhanced VPN #3 \_______________________o ...... ... o-----------\ /-------------o o____________X______________o Enhanced VPN #n __________________________ / o----o-----o / / / / / NRP-1 / o-----o-----o----o----o / /_________________________/ __________________________ / o----o / / / / \ / NRP-2 / o-----o----o---o------o / /_________________________/ ...... ... ___________________________ / o----o / / / / / NRP-m / o-----o----o----o-----o / /__________________________/ ++++ ++++ ++++ +--+===+--+===+--+ +--+===+--+===+--+ ++++ +++\\ ++++ || || \\ || Physical || || \\ || Network ++++ ++++ ++++ \\+++ ++++ Infrastructure +--+===+--+===+--+===+--+===+--+ +--+===+--+===+--+===+--+===+--+ ++++ ++++ ++++ ++++ ++++ o Virtual Node ++++ +--+ Physical Node with resource partition -- Virtual Link +--+ ++++ == Physical Link with resource partition

Various components and techniques discussed in can be used to enable resource partitioning of the physical network infrastructure, such as FlexE, TSN, dedicated queues, etc. These partitions may be physical or virtual so long as the SLA required by the higher layers is met. Based on the set of NRPs provided by the physical network infrastructure, multiple NRPs can be created. Each of these NRPs:

• has a set of dedicated or shared network resources allocated from the physical underlay network,
• can be associated with a customized logical network topology, and
• meets the requirements of a specific enhanced VPN service or a specific group of enhanced VPN services.

According to the associated logical network topology, each NRP needs to be instantiated on a set of network nodes and links that are involved in the logical topology. On each node or link, each NRP is associated with a set of local resources that are allocated for the processing of traffic in the NRP. The NRP provides the integration between the logical network topology and the required underlying network resources. According to the service requirements of connectivity, performance, isolation, etc., enhanced VPN services can be mapped to the appropriate NRPs in the network. Different enhanced VPN services can be mapped to different NRPs; it is also possible that multiple enhanced VPN services are mapped to the same NRP. Thus, the NRP is an essential scaling technique as it has the potential of eliminating per-service per-path state from the network. In addition, when a group of enhanced VPN services is mapped to a single NRP, only the network state of the single NRP needs to be maintained in the network (see for more information). The network controller is responsible for creating an NRP, instructing the involved network nodes to allocate network resources to the NRP, and provisioning the enhanced VPN services on the NRP. A distributed control plane may be used for distributing the NRP resource and topology attributes among nodes in the NRP. Extensions to distributed control protocols (if any) are out of the scope of this document. The process used to create NRPs and to allocate network resources for use by the NRPs needs to take a holistic view of the needs of all of the service provider's customers and to partition the resources accordingly. However, within an NRP, these resources can be managed via a dynamic control plane if required. This provides the required scalability and isolation with some flexibility.

Connectivity Types At the VPN service level, the required connectivity for a Multipoint-to-Multipoint (MP2MP) VPN service is usually full or partial mesh. To support such VPN services, the corresponding NRP also needs to provide MP2MP connectivity among the endpoints. Other service requirements may be expressed at different granularities, some of which can be applicable to the whole service while others may only be applicable to some pairs of endpoints. For example, when a particular level of performance guarantee is required, the point-to-point path through the underlying NRP of the enhanced VPN service may need to be specifically engineered to meet the required performance guarantee.

Application-Specific Data Types Although a lot of the traffic that will be carried over enhanced VPN will likely be IP based, the design must be capable of carrying other traffic types, in particular Ethernet traffic. This is easily accomplished through various pseudowire (PW) techniques . Where the underlay is MPLS, Ethernet traffic can be carried over an enhanced VPN encapsulated according to the method specified in . Where the underlay is IP, L2 Tunneling Protocol - Version 3 (L2TPv3) can be used with Ethernet traffic carried according to . Encapsulations have been defined for most of the common L2 types for both PW over MPLS and for L2TPv3.

Scalable Service Mapping VPNs are instantiated as overlays on top of an operator's network and offered as services to the operator's customers. An important feature of overlays is that they can deliver services without placing per-service state in the core of the underlay network. An enhanced VPN may need to install some additional state within the network to achieve the features that they require. Solutions need to take the scale of such state into consideration, and deployment architectures should constrain the number of enhanced VPN services so that the additional state introduced to the network is acceptable and under control. It is expected that the number of enhanced VPN services will be small at the beginning: even in the future, the number of enhanced VPN services will be fewer than conventional VPNs because existing VPN techniques are good enough to meet the needs of most existing VPN-type services. In general, it is not required that the state in the network be maintained in a 1:1 relationship with the enhanced VPN services. It will usually be possible to aggregate a set or group of enhanced VPN services so that they share the same NRP and the same set of network resources (much in the same way that current VPNs are aggregated over transport tunnels) so that collections of enhanced VPN services that require the same behavior from the network in terms of resource reservation, latency bounds, resiliency, etc. can be grouped together. This is an important feature to assist with the scaling characteristics of NRP-based enhanced VPN deployments. provides more details of scalability considerations for the NRPs used to instantiate NRPs, and includes a greater discussion of scalability considerations.

Candidate Technologies A VPN is created by applying a demultiplexing technique to the underlying network (the underlay) to distinguish the traffic of one VPN from that of another. The connections of a VPN are supported by a set of underlay paths. Any path other than the shortest path through the underlay normally requires state to specify that path. The state of the paths could be applied to the underlay through the use of the RSVP-TE signaling protocol or directly through the use of a Software-Defined Networking (SDN) controller. Based on Segment Routing (SR), state could be maintained at the ingress node of the path and carried in the data packet. Other techniques may emerge as this problem is studied. This state gets harder to manage as the number of paths increases. Furthermore, as we increase the coupling between the underlay and the overlay to support the enhanced VPN service, this state is likely to increase further. Through the use of NRP, a subset of underlay network resources can be either dedicated for a particular enhanced VPN service or shared among a group of enhanced VPN services. A group of underlay paths can be established using the common set of network resources of the NRP. This section describes the candidate technologies and examines them in the context of the different network planes that may be used together to build NRPs. discusses the L2 packet-based or frame-based forwarding-plane mechanisms for resource partitioning. discusses the corresponding encapsulation and forwarding mechanisms in the network layer. Non-packet data plane mechanisms are briefly discussed in . The control plane and management plane mechanisms are discussed in Sections and , respectively.

Underlay Forwarding Resource Partitioning Several candidate L2 packet-based or frame-based forwarding-plane mechanisms that can provide the required traffic isolation and performance guarantees are described in the following sections.

Flex Ethernet FlexE provides the ability to multiplex channels over an Ethernet link to create point-to-point fixed-bandwidth connections in a way that provides separation between enhanced VPN services. FlexE also supports bonding multiple low-capacity links to create larger links. However, FlexE is only a link-level technology. When packets are received by the downstream node, they need to be processed in a way that preserves traffic isolation. In turn, this requires a queuing and forwarding implementation that preserves the end-to-end separation of enhanced VPNs. If different FlexE channels are used for different services, then no sharing is possible between the FlexE channels. Thus, it may be difficult to dynamically redistribute unused bandwidth to lower priority services in another FlexE channel. If one FlexE channel is used by one customer, the customer can use some methods to manage the relative priority of their own traffic in the FlexE channel.

Dedicated Queues Diffserv-based queuing systems are described in and . This approach is not sufficient to provide separation of enhanced VPN services because Diffserv does not provide enough markers to differentiate between traffic of a large number of enhanced VPN services. Additionally, Diffserv does not offer the range of service classes that each enhanced VPN service needs to provide to its tenants. This problem is particularly acute with an MPLS underlay because MPLS only provides eight traffic classes. In addition, Diffserv, as currently implemented, mainly provides per- hop priority-based scheduling, and it is difficult to use it to achieve quantitative resource reservation for different enhanced VPN services. To address these problems and to reduce the potential interactions between enhanced VPN services, it would be necessary to steer traffic to dedicated input and output queues per enhanced VPN service or per group of enhanced VPN services: some routers have a large number of queues and sophisticated queuing systems that could support this while some routers may struggle to provide the granularity and level of separation required by the applications of an enhanced VPN.

Time-Sensitive Networking is an IEEE project to provide a method of carrying time-sensitive information over Ethernet. It introduces the concept of packet scheduling where a packet stream may be given a time slot guaranteeing that it will experience no queuing delay or increase in latency beyond a very small scheduling delay. The mechanisms defined in TSN can be used to meet the requirements of time-sensitive traffic flows of enhanced VPN service. Ethernet can be emulated over a L3 network using an IP or MPLS pseudowire. However, a TSN Ethernet payload would be opaque to the underlay; thus, it would not be treated specifically as time-sensitive data. The preferred method of carrying TSN over a L3 network is through the use of DetNet as explained in .

Network Layer Encapsulation and Forwarding This section considers the problem of enhanced VPN service differentiation and the representation of underlying network resources in the network layer. More specifically, it describes the possible data plane mechanisms to determine the network resources and the logical network topology or paths associated with an NRP.

Deterministic Networking (DetNet) DetNet is a technique being developed in the IETF to enhance the ability of L3 networks to deliver packets more reliably and with greater control over the delay. The design cannot use retransmission techniques such as TCP because that can exceed the delay tolerated by the applications. DetNet preemptively sends copies of the packet over various paths to minimize the chance of all copies of a packet being lost. It also seeks to set an upper bound on latency, but the goal is not to minimize latency. DetNet can be realized over the IP data plane or the MPLS data plane , and it may be used to provide deterministic paths for enhanced VPN services.

MPLS Traffic Engineering (MPLS-TE) MPLS-TE (see and ) introduces the concept of reserving end-to-end bandwidth for a TE-LSP, which can be used to provide a set of point-to-point resource-reserved paths across the underlay network to support VPN services. VPN traffic can be carried over dedicated TE-LSPs to provide guaranteed bandwidth for each specific connection in a VPN, and VPNs with similar behavior requirements may be multiplexed onto the same TE-LSPs. Some network operators have concerns about the scalability and management overhead of MPLS-TE system, especially with regard to those systems that use an active control plane, and this has lead them to consider other solutions for TE in their networks.

Segment Routing SR is a method that prepends instructions to packets at the headend of a path. These instructions are used to specify the nodes and links to be traversed, and they allow the packets to be routed on paths other than the shortest path. By encoding the state in the packet, per-path state is transitioned out of the network. SR can be instantiated using the MPLS data plane (SR-MPLS) (see ) or the IPv6 data plane (SRv6) (see ). An SR traffic-engineered path operates with the granularity of a link. Hints about priority are provided using the Traffic Class (TC) field in the packet header. However, to achieve the performance and isolation characteristics that are sought by enhanced VPN customers, it will be necessary to steer packets through specific virtual links and/or queues on the same link and direct them to use specific resources. With SR, it is possible to introduce such fine-grained packet steering by specifying the queues and the associated resources through an SR instruction list. One approach to do this is described in . Note that the concept of a queue is a useful abstraction for different types of underlay mechanisms that may be used to provide enhanced isolation and performance support. How the queue satisfies the requirement is implementation specific and is transparent to the L3 data plane and control plane mechanisms used. With SR, the SR instruction list could be used to build a P2P SR path. In addition, a group of SR Segment Identifiers (SIDs) could also be used to represent an MP2MP network. Thus, the SR-based mechanism could be used to provide both resource-reserved paths and NRPs for enhanced VPN services.

New Encapsulation Extensions In contrast to reusing an existing data plane for enhanced VPN, another possible approach is to introduce new encapsulations or extensions to an existing data plane to allow dedicated identifiers for the underlay network resources of an enhanced VPN and the logical network topology or paths associated with an enhanced VPN. This may require more protocol work; however, the potential benefits are that it can reduce the impact to existing network operation and improve the scalability of enhanced VPN. More details about the encapsulation extensions and the scalability concerns are described in .

Non-Packet Data Plane Non-packet underlay data plane technologies, such as optical-based data planes, often have TE properties and behaviors. They meet many of the key requirements, particularly those for:

• bandwidth guarantees,
• traffic isolation (with physical isolation often being an integral part of the technology),
• highly predictable latency and jitter characteristics,
• measurable loss characteristics, and
• ease of identification of flows.

The cost is that the resources are allocated on a long-term and end-to-end basis. Such an arrangement means that the full cost of the resources has to be borne by the client to which the resources are allocated. When an NRP built with this data plane is used to support multiple enhanced VPN services, the cost could be distributed among such a group of services.

Control Plane The control plane of NRP-based enhanced VPNs is likely be based on a hybrid control mechanism that takes advantage of a logically centralized controller for on-demand provisioning and global optimization while still relying on a distributed control plane to provide scalability, high reliability, fast reaction, automatic failure recovery, etc. Extension to and optimization of the centralized and distributed control plane is needed to support the enhanced properties of an NRP-based enhanced VPN. As described in , the enhanced VPN control plane needs to provide the following functions:

• Collection of information about the underlying network topology and network resources and exportation of this to network nodes and/or a centralized controller as required.
• Creation of NRPs with the network resource and topology properties needed by NRP-based enhanced VPN services.
• Distribution of the attributes of NRPs to network nodes that participate in the NRPs and/or the centralized controller.
• Mapping of enhanced VPN services to an appropriate NRP.
• Computation and set up of service paths in each NRP to meet enhanced VPN service requirements.

Underlying network topology and resource information can be collected using mechanisms based on the existing IGP and Border Gateway Protocol - Link State (BGP-LS) . The creation of NRPs and the distribution of NRP attributes may need further control protocol extensions. The computation of service paths based on the attributes and constraints of the NRP can be performed either by the headend node of the path or by a centralized Path Computation Element (PCE) . Two candidate control plane mechanisms for path setup in the NRP are RSVP-TE and SR.

• RSVP-TE, as described in , provides the signaling mechanism for establishing a TE-LSP in an MPLS network with end-to-end resource reservation. This can be seen as an approach of providing resource-reserved paths that could be used to bind the VPN to a specific set of network resources allocated within the underlay; however, there remain scalability concerns, as mentioned in .
• The SR control plane, as described in , , and , does not have the capability of signaling resource reservations along the path. On the other hand, the SR approach provides a potential way of binding the underlay network resource and the NRPs without requiring per-path state to be maintained in the network. A centralized controller can perform resource planning and reservation for NRPs, and it needs to instruct the network nodes to ensure that resources are correctly allocated for the NRP. The controller could provision the SR paths based on the mechanism in to the headend nodes of the paths.

According to the service requirements for connectivity, performance, and isolation, one enhanced VPN service may be mapped to a dedicated NRP or a group of enhanced VPN services may be mapped to the same NRP. The mapping of enhanced VPN services to an NRP can be achieved using existing control mechanisms with possible extensions; it can be based on either the characteristics of the data packet or the attributes of the VPN service routes.

Management Plane The management plane provides the interface between the enhanced VPN service provider and the customers for life-cycle management of the enhanced VPN service (i.e., creation, modification, assurance/monitoring, and decommissioning). It relies on a set of service data models for the description of the information and operations needed on the interface. As an example, in the context of 5G end-to-end network slicing , the management of the transport network segment of the 5G end-to-end network slice can be realized with the management plane of the enhanced VPN. The 3GPP management system may provide the connectivity and performance-related parameters as requirements to the management plane of the transport network. It may also require the transport network to expose the capabilities and status of the network slice. Thus, the coordination of 5G end-to-end network slice management requires an interface between the enhanced VPN management plane and the 5G network slice management system, and relevant service data models. The management plane interface and data models for enhanced VPN services can be based on the service models described in . It is important that the life-cycle management support in-place modification of enhanced VPN services. That is, it should be possible to add and remove endpoints, as well as to change the requested characteristics of the service that is delivered. The management system needs to be able to assess the revised enhanced VPN requests and determine whether they can be provided by the existing NRPs or whether changes must be made. It will also need to determine whether those changes to the NRP are possible. If not, then the customer's modification request may be rejected. When the modification of an enhanced VPN service is possible, the management system must make every effort to make the changes in a non-disruptive way. That is, the modification of the enhanced VPN service or the underlying NRP must not perturb traffic on the enhanced VPN service in a way that causes the service level to drop below the agreed levels. Furthermore, changes to one enhanced VPN service should not cause disruption to other enhanced VPN services. The network operator for the underlay network (i.e., the provider of the enhanced VPN service) may delegate some operational aspects of the overlay VPN and the underlying NRP to the customer. In this way, the enhanced VPN is presented to the customer as a virtual network, and the customer can choose how to use that network. Some mechanisms in the operator's network are needed so that:

• a customer cannot exceed the capabilities of the virtual links and nodes, but
• it can decide how to load traffic onto the network, for example, by assigning different metrics to the virtual links so that the customer can control how traffic is routed through the virtual network.

This approach requires a management system for the virtual network but does not necessarily require any coordination between the management systems of the virtual network and the physical network, except that the virtual network management system might notice when the NRP is close to capacity or considerably under-used and automatically request changes in the service provided by the underlay network.

Applicability of Service Data Models to Enhanced VPNs This section describes the applicability of the existing and in-progress service data models to enhanced VPNs. describes the scope and purpose of service models and shows where a service model might fit into an SDN-based network management architecture. New service models may also be introduced for some of the required management functions. Service data models are used to represent, monitor, and manage the virtual networks and services enabled by enhanced VPNs. The VPN customer service models (e.g., the L3VPN Service Model (L3SM) in , the L2VPN Service Model (L2SM) in ), or the ACTN VN model in ) are service models that can provide the customer's view of the enhanced VPN service. The L3VPN Network Model (L3NM) from and the L2VPN Network Model (L2NM) from provide the operator's view of the managed infrastructure as a set of virtual networks and the associated resources. The Service Attachment Points (SAPs) model in provides an abstract view of the SAPs to various network services in the provider network, where enhanced VPN could be one of the service types. provides the data model for performance monitoring of network and VPN services. Augmentation to these service models may be needed to provide the enhanced VPN services. The NRP model in further provides the management of the NRP topology and resources both in the controller and in the network devices to instantiate the NRPs needed for the enhanced VPN services.

Applicability in Network Slice Realization This section describes the applicability of NRP-based enhanced VPN for network slice realization. In order to provide network slice services to customers, a technology-agnostic network slice service model is needed for the customers to communicate the requirements of network slices (SDPs, connectivity, SLOs, and SLEs). These requirements may be realized using technology specified in this document to instruct the network to deliver an enhanced VPN service so as to meet the requirements of the network slice customers. According to the location of SDPs used for the network slice service (see ), an SDP can be mapped to a Customer Edge (CE), a PE, a port on a CE, or a customer-facing port on a PE, any of which can be correlated to the endpoint of the enhanced VPN service. The detailed approach for SDP mapping is described in .

NRP Planning An NRP is used to support the SLOs and SLEs required by the network slice services. According to the network operators' network resource planning policy, or based on the requirements of one or a group of customers or services, an NRP may need to be created to meet the requirements of network slice services. One of the basic requirements for the NRP is to provide a set of dedicated network resources to avoid unexpected interference from other services in the same network. Other possible requirements may include the required topology and connectivity, bandwidth, latency, reliability, etc. A centralized network controller can be responsible for calculating a subset of the underlay network topology (which is called a logical topology) to support the NRP requirement. On the network nodes and links within the logical topology, the set of network resources to be allocated to the NRP can also be determined by the controller. Normally, such calculation needs to take the underlay network connectivity information and the available network resource information of the underlay network into consideration. The network controller may also take the status of the existing NRPs into consideration in the planning and calculation of a new NRP.

NRP Creation According to the result of the NRP planning, the network nodes and links involved in the logical topology of the NRP are instructed to allocate the required set of network resources for the NRP. One or multiple mechanisms as specified in can be used to partition the forwarding-plane network resources and allocate different subsets of resources to different NRPs. In addition, the data plane identifiers that are used to identify the set of network resources allocated to the NRP are also provisioned on the network nodes. Depending on the data plane technologies used, the set of network resources of an NRP can be identified using, e.g., resource-aware SR segments as specified in and or a dedicated Resource ID as specified in can be introduced. The network nodes involved in an NRP may distribute the logical topology information, the NRP-specific network resource information, and the Resource ID of the NRP using the control plane. Such information could be used by the controller and the network nodes to compute the TE or shortest paths within the NRP and to install the NRP-specific forwarding entries to network nodes.

Network Slice Service Provisioning According to the connectivity requirements of a network slice service, an overlay VPN can be created using the existing or future multi-tenancy overlay technologies as described in . Then, according to the SLO and SLE requirements of a network slice service, the network slice service is mapped to an appropriate NRP as the virtual underlay. The integration of the overlay VPN and the underlay NRP provides a network slice service.

Network Slice Traffic Steering and Forwarding At the edge of the operator's network, network slice traffic can be classified based on the rules defined by the operator's policy; this is so that the traffic that matches the rules for specific network slice services can be mapped to the corresponding NRP. Thus, packets belonging to a specific network slice service will be processed and forwarded by network nodes based on either:

• the traffic-engineered paths or
• the shortest paths in the associated network topology

using the set of network resources of the corresponding NRP.

Scalability Considerations NRP-based enhanced VPNs provide performance guaranteed services in packet networks; however, this comes with the potential cost of introducing additional state into the network. There are at least three ways that this additional state might be added:

• by introducing the complete state into the packet, as is done in SR. This allows the controller to specify the detailed series of forwarding and processing instructions for the packet as it transits the network. The cost of this is an increase in the packet header size. A further cost is that systems will have to provide NRP-specific segments in case they are called upon by a service. This is a type of latent state, and it increases as the segments and resources that need to be exclusively available to enhanced VPN service are specified more precisely.
• by introducing the state to the network. This is normally done by creating a path using signaling such as RSVP-TE. This could be extended to include any element that needs to be specified along the path, for example, explicitly specifying queuing policy. It is also possible to use other methods to introduce path state, such as via an SDN controller or possibly by modifying a routing protocol. With this approach, there is state per path: a per-path characteristic that needs to be maintained over the life of the path. This is more network state than is needed using SR, but the packets are usually shorter.
• by providing a hybrid approach. One example is based on using binding SIDs (see ) to represent path fragments and binding them together with SR. Dynamic creation of a VPN service path using SR requires less state maintenance in the network core at the expense of larger packet headers. The packet size can be lower if a form of loose source routing is used (using a few nodal SIDs), and it will be lower if no specific functions or resources on the routers are specified. For Segment Routing over IPv6 (SRv6), the packet size may also be reduced by utilizing the compression techniques specified in .

Reducing the state in the network is important to the deployment of enhanced VPNs, as they require the overlay to be more closely integrated with the underlay than with conventional VPNs. This tighter coupling would normally mean that more state needs to be created and maintained in the network, as state about fine-granularity processing would need to be loaded and maintained in the routers. Aggregation is a well-established approach to reduce the amount of state and improve scaling, and NRP is considered to be the network construct to aggregate the states of enhanced VPN services. In addition, an SR approach allows much of the state to be spread amongst the network ingress nodes and transiently carried in the packets as SIDs. The following subsections describe some of the scalability concerns that need to be considered. Further discussion of the scalability considerations of the underlaying network constructs of NRP-based enhanced VPNs can be found in .

Maximum Stack Depth of SR One of the challenges with SR is the stack depth that nodes are able to impose on packets . This leads to a difficult balance between:

• adding state to the network and minimizing stack depth and
• minimizing state and increasing the stack depth.

RSVP-TE Scalability The established method of creating a resource-reserved path through an MPLS network is to use the RSVP-TE protocol. However, there have been concerns that this requires significant continuous state maintenance in the network. Work to improve the scalability of RSVP-TE LSPs in the control plane can be found in . There is also concern at the scalability of the forwarder footprint of RSVP-TE as the number of paths through a Label Switching Router (LSR) grows. addresses this by employing SR within a tunnel established by RSVP-TE.

SDN Scaling The centralized SDN-based approach requires control plane state to be stored in the network, but can reduce the overhead of control channels to be maintained. Each individual network node may need to maintain a control channel with an SDN controller, which is considered more scalable compared to the need of maintaining control channels with a set of neighbor nodes. However, SDN may transfer some of the scalability concerns from the network to a centralized controller. In particular, there may be a heavy processing burden at the controller and a heavy load in the network surrounding the controller. A centralized controller may also present a single point of failure within the network.

Enhanced Resiliency Each enhanced VPN service has a life cycle and may need modification during deployment as the needs of its tenant change (see ). Additionally, as the network evolves, garbage collection may need to be performed to consolidate resources into usable quanta. Systems in which the path is imposed, such as SR or some form of explicit routing, tend to do well in these applications because it is possible to perform an atomic transition from one path to another. That is, a single action by the headend that changes the path without the need for coordinated action by the routers along the path. However, implementations and the monitoring protocols need to make sure that the new path is operational and meets the required SLA before traffic is transitioned to it. It is possible for deadlocks to arise as a result of the network becoming fragmented over time, such that it is impossible to create a new path or to modify an existing path without impacting the SLA of other paths. The global concurrent optimization mechanisms as described in and discussed in may be helpful, while complete resolution of this situation is as much a commercial issue as it is a technical issue. However, there are two manifestations of the latency problem that are for further study in any of these approaches:

• Packets overtaking one another if path latency reduces during a transition.
• Transient variation in latency in either direction as a path migrates.

There is also the matter of what happens during failure in the underlay infrastructure. Fast reroute is one approach, but that still produces a transient loss with a normal goal of rectifying this within 50 ms . An alternative is some form of N+1 delivery such as has been used for many years to support protection from service disruption. This may be taken to a different level using the techniques of DetNet with multiple in-network replications and the culling of later packets . In addition to the approach used to protect high-priority packets, consideration should be given to the impact of best-effort traffic on the high-priority packets during a transition. Specifically, if a conventional re-convergence process is used, there will inevitably be micro-loops and, while some form of explicit routing will protect the high-priority traffic, lower-priority traffic on best-effort shortest paths will micro-loop without the use of a loop-prevention technology. To provide the highest quality of service to high-priority traffic, either this traffic must be shielded from the micro-loops or micro-loops must be prevented completely.

Manageability Considerations This section describes the considerations about the OAM and telemetry mechanisms used to support the verification, monitoring, and optimization of the characteristics and SLA fulfillment of NRP-based enhanced VPN services. It should be read along with , which gives consideration to the management plane techniques that can be used to build NRPs.

OAM Considerations The following requirements need to be considered in the design of OAM for enhanced VPN services:

• Instrumentation of the NRP (the virtual underlay) so that the network operator can be sure that the resources committed to a customer are operating correctly and delivering the required performance. It is important that the OAM packets follow the same path and set of resources as the service packets mapped to the NRP.
• Instrumentation of the overlay by the customer. This is likely to be transparent to the network operator and to use existing methods. Particular consideration needs to be given to the need to verify the various committed performance characteristics.
• Instrumentation of the overlay by the service provider to proactively demonstrate that the committed performance is being delivered. This needs to be done in a non-intrusive manner, particularly when the tenant is deploying a performance-sensitive application.

A study of OAM in SR networks is documented in .

Telemetry Considerations Network visibility is essential for network operation. Network telemetry has been considered to be an ideal means to gain sufficient network visibility with better flexibility, scalability, accuracy, coverage, and performance than conventional OAM technologies. As defined in , the objective of network telemetry is to acquire network data remotely for network monitoring and operation. It is a general term for a large set of network visibility techniques and protocols. Network telemetry addresses the current network operation issues and enables smooth evolution toward intent-driven autonomous networks. Telemetry can be applied on the forwarding plane, the control plane, and the management plane in a network. The following requirements need to be considered for telemetry for enhanced VPN service:

• Collecting data of NRPs for overall performance evaluation and the planning of the enhanced VPN services.
• Collecting data of each enhanced VPN service for monitoring and analytics of the service characteristics and SLA fulfillment.

How the telemetry mechanisms could be used or extended for enhanced VPN services is out of the scope of this document.

Operational Considerations It is expected that NRP-based enhanced VPN services will be introduced in networks that already have conventional VPN services deployed. Depending on service requirements, the tenants or the operator may choose to use a VPN or an enhanced VPN to fulfill a service requirement. The information and parameters to assist such a decision needs to be supplied on the management interface between the tenant and the operator. The management interface and data models (as described in ) can be used for the life-cycle management of enhanced VPN services, such as service creation, modification, performance monitoring, and decommissioning.

Security Considerations All types of virtual networks require special consideration to be given to the isolation of traffic belonging to different tenants. That is, traffic belonging to one VPN must not be delivered to endpoints outside that VPN. In this regard, the enhanced VPN neither introduces nor experiences greater security risks than other VPNs. However, in an enhanced VPN service, the additional service requirements need to be considered. For example, if a service requires a specific upper bound to latency, then it can be damaged by simply delaying the packets through the activities of another tenant, i.e., by introducing bursts of traffic for other services. In some respects, this makes the enhanced VPN more susceptible to attacks since the SLA may be broken. Another view is that the operator must, in any case, preform monitoring of the enhanced VPN to ensure that the SLA is met; thus, the operator may be more likely to spot the early onset of a security attack and be able to take preemptive protective action. The measures to address these dynamic security risks must be specified as part of the specific solution to the isolation requirements of an enhanced VPN service. While an enhanced VPN service may be sold as offering encryption and other security features as part of the service, customers would be well advised to take responsibility for their security requirements themselves, possibly by encrypting traffic before handing it off to the service provider. The privacy of enhanced VPN service customers must be preserved. It should not be possible for one customer to discover the existence of another customer nor should the sites that are members of an enhanced VPN be externally visible. An enhanced VPN service (even one with traffic isolation requirements or with limited interaction with other enhanced VPNs) does not provide any additional guarantees of privacy for customer traffic compared to regular VPNs: the traffic within the network may be intercepted and errors may lead to mis-delivery. Users who wish to ensure the privacy of their traffic must take their own precautions including end-to-end encryption.

IANA Considerations This document has no IANA actions.

References Normative References This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Informative References Optical Internetworking Forum IA # OIF-FLEXE-01.0 Huawei Technologies Huawei Technologies China Telecom China Telecom Verizon Inc. Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet are used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along a path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry network resource related information (e.g., identifier) in data packets. The NR Option can also be generalized for other network resource semantics and functions. Work in Progress Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc 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. Work in Progress NGMN Alliance Version 1.0.8 (draft) Huawei Technologies Huawei Technologies China Mobile China Telecom Verizon Inc. 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 9543 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. Work in Progress Huawei Technologies Huawei Technologies Juniper Networks Cisco Systems ZTE Corporation RFC 9543 describes a framework for Network Slices in networks 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. Work in Progress Huawei Technologies KDDI Corporation China Telecom China Mobile China Mobile This document describes the mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. A list of resource-aware SIDs can be used to allow an SR Policy to use a specific set of network resources, and a group of resource-aware SIDs can be used to represent a virtual network with a specific set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). Work in Progress This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK] This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community. This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community. This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK] This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community. The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community. This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community. This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK] This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community. This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK] The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK] This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T). This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T. The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK] The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues. This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs. The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability. This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text. The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed. This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features. Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled. As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information. However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane. This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane. This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable. This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1. Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the OSPFv2 extensions required for Segment Routing. Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938). This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies. This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP. As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model. In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. Samsung Electronics Huawei Cisco Individual ETRI Huawei Technologies KDDI Corporation China Telecom China Mobile China Mobile Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent topological or service based instructions. A segment can further be associated with a set of network resources used for executing the instruction. Such a segment is called resource-aware segment. Resource-aware Segment Identifiers (SIDs) may be used to build SR paths with a set of reserved network resources. In addition, a group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. Work in Progress China Mobile Cisco Systems, Inc. Huawei Technologies Orange Cisco Systems, Inc. Work in Progress 3GPP 3GPP IEEE 802.1 Working Group

Acknowledgements The authors would like to thank , , , , , and for their review and valuable comments. This work was supported in part by the European Commission funded H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727).

Contributors

daniel@olddog.co.uk

adrian@olddog.co.uk

jefftant.ietf@gmail.com

lizhenbin@huawei.com

bill.wu@huawei.com

lana.wubo@huawei.com

daniele.ietf@gmail.com

mohamed.boucadair@orange.com

sergio.belotti@nokia.com

zhenghaomian@huawei.com

Authors' Addresses Huawei

jie.dong@huawei.com

University of Surrey

stewart.bryant@gmail.com

China Mobile

lizhenqiang@chinamobile.com

KDDI Corporation

ta-miyasaka@kddi.com

Samsung

younglee.tx@gmail.com