]> Cisco Systems Inc.

tsaad.net@gmail.com

HPE

vishnupavan.ietf@gmail.com

Huawei Technologies

jie.dong@huawei.com

HPE

joel.halpern@hpe.com

ZTE Corporation

peng.shaofu@zte.com.cn

TEAS Working Group Internet-Draft Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers.

Introduction Network slicing allows a Service Provider to create independent and logical networks on top of a shared physical network infrastructure. Such network slices can be offered to customers or used internally by the Service Provider to enhance the delivery of their service offerings. A Service Provider can also use network slicing to structure and organize the elements of its infrastructure. The solution discussed in this document works with any path control technology (such as RSVP-TE, or SR) that can be used by a Service Provider to realize network slicing in IP/MPLS networks. provides the definition of a network slice for use within the IETF and discusses the general framework for requesting and operating IETF Network Slices, their characteristics, and the necessary system components and interfaces. It also discusses the function of an IETF Network Slice Controller and the requirements on its northbound and southbound interfaces. This document introduces the notion of a Slice-Flow Aggregate which comprises of one or more IETF network slice traffic streams. It also describes the Network Resource Partition (NRP) and the NRP Policy that can be used to instantiate control and data plane behaviors on select topological elements associated with the NRP that supports a Slice-Flow Aggregate - refer for further details. The IETF Network Slice Controller is responsible for the aggregation of multiple IETF network traffic streams into a Slice-Flow Aggregate, and for maintaining the mapping required between them. The mechanisms used by the controller to determine the mapping of one or more IETF network slice to a Slice-Flow Aggregate are outside the scope of this document. The focus of this document is on the mechanisms required at the device level to address the requirements of network slicing in packet networks. In a Diffserv (DS) domain , packets requiring the same forwarding treatment (scheduling and drop policy) are classified and marked with the respective Class Selector (CS) Codepoint (or the Traffic Class (TC) field for MPLS packets ) at the DS domain ingress nodes. Such packets are said to belong to a Behavior Aggregate (BA) that has a common set of behavioral characteristics or a common set of delivery requirements. At transit nodes, the CS is inspected to determine the specific forwarding treatment to be applied before the packet is forwarded. A similar approach is adopted in this document to realize network slicing. The solution proposed in this document does not mandate Diffserv to be enabled in the network to provide a specific forwarding treatment. If Diffserv is enabled within the network, the Slice-Flow Aggregate traffic can further carry a Diffserv CS to enable differentiation of forwarding treatments for packets within a Slice-Flow Aggregate. When logical networks associated with an NRP are realized on top of a shared physical network infrastructure, it is important to steer traffic on the specific network resources partition that is allocated for a given Slice-Flow Aggregate. In packet networks, the packets of a specific Slice-Flow Aggregate may be identified by one or more specific fields carried within the packet. An NRP ingress boundary node (where Slice-Flow Aggregate traffic enters the NRP) populates the respective field(s) in packets that are mapped to a Slice-Flow Aggregate in order to allow interior NRP nodes to identify and apply the specific Per NRP Hop Behavior (NRP-PHB) associated with the Slice-Flow Aggregate. The NRP-PHB defines the scheduling treatment and, in some cases, the packet drop probability. This document covers different modes of NRPs and discusses how each mode can ensure proper placement of Slice-Flow Aggregate paths and respective treatment of Slice-Flow Aggregate traffic.

Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The reader is expected to be familiar with the terminology specified in . The following terminology is used in the document:

IETF Network Slice:

refer to the definition of 'IETF network slice' in .

IETF Network Slice Controller (NSC):

refer to the definition in .

Network Resource Partition:

refer to the definition in .

Slice-Flow Aggregate:

a collection of packets that are mapped to an NRP and are given the same forwarding treatment; a Slice-Flow Aggregate comprises one or more IETF network slice traffic streams from one or more connectivity constructs (belonging to one or more IETF network slices); the mapping of one or more IETF network slice streams to a Slice-Flow Aggregate is maintained by the IETF Network Slice Controller. The boundary nodes MAY also maintain a mapping of specific IETF network slice service(s) to a Slice-Flow Aggregate.

Network Resource Partition Policy (NRP):

a policy construct that enables instantiation of mechanisms in support of IETF network slice specific control and data plane behaviors on select topological elements; the enforcement of an NRP Policy results in the creation of an NRP.

NRP Domain:

a network region under common administrative control within which NRP Identifiers (NRP-IDs) are uniquely allocated and managed, and within which NRP Policies are instantiated on network elements to govern the partitioning of network resources. An NRP domain has boundary nodes that are responsible for NRP Selector handling (e.g., addition, removal, stacking, or remapping) at the edges of the domain. A network slice may span one or more NRP domains, each of which independently manages its own NRP-ID space and resource allocations.

NRP Identifier (NRP-ID):

an identifier that is globally unique within an NRP domain and that can be used in the control or management plane to identify the resources associated with the NRP. The NRP-ID is represented as a 32-bit unsigned integer, with a value of 0 reserved for future use.

NRP Selector:

one or more fields (markings) in a packet's network layer header that are used to map the packet to an NRP.

NRP Selector Identifier (NRP Selector ID):

a dedicated identifier that acts as an NRP Selector.

NRP Capable Node:

a node that supports one of the NRP modes described in this document.

NRP Incapable Node:

a node that does not support any of the NRP modes described in this document.

Slice-Flow Aggregate Path:

a path that is set up over the NRP that is associated with a specific Slice-Flow Aggregate.

Slice-Flow Aggregate Packet:

a packet that traverses over the NRP that is associated with a specific Slice-Flow Aggregate.

Filtered Topology:

a topology derived from the physical network by applying topology filtering policies that select specific nodes and links based on their capabilities and attributes (e.g., Resource Affinities or Flexible Algorithm membership). The same Filtered Topology may be shared by multiple NRPs.

NRP Topology:

the topology resulting from instantiating an NRP on a Filtered Topology by associating NRP-specific resource reservations and Per Hop Behavior (NRP-PHB) with the topological elements of the Filtered Topology. Two NRPs may share the same Filtered Topology while having different resource reservations and forwarding treatments.

NRP state aware TE (NRP-TE):

a mechanism for TE path selection that takes into account the available network resources associated with a specific NRP.

Acronyms and Abbreviations

• BA: Behavior Aggregate

• CS: Class Selector

• NRP-PHB: NRP Per Hop Behavior as described in

• SLA: Service Level Agreements

• SLO: Service Level Objectives

• SLE: Service Level Expectations

• Diffserv: Differentiated Services

• MPLS: Multiprotocol Label Switching

• LSP: Label Switched Path

• RSVP: Resource Reservation Protocol

• TE: Traffic Engineering

• SR: Segment Routing

• VRF: VPN Routing and Forwarding

• AC: Attachment Circuit

• CE: Customer Edge

• PE: Provider Edge

• PCEP: Path Computation Element (PCE) Communication Protocol (PCEP)

Network Resource Slicing Membership An NRP that supports a Slice-Flow Aggregate can be instantiated over parts of an IP/MPLS network (e.g., all or specific network resources in the access, aggregation, or core network), and can stretch across multiple domains administered by a provider. The NRP topology may be comprised of dedicated and/or shared network resources (e.g., in terms of processing power, storage, and bandwidth). The physical network resources may be fully dedicated to a specific Slice-Flow Aggregate. For example, traffic belonging to a Slice-Flow Aggregate can traverse dedicated network resources without being subjected to contention from traffic of other Slice-Flow Aggregates. Dedicated physical network resource slicing allows for simple partitioning of the physical network resources amongst Slice-Flow Aggregates without the need to distinguish packets traversing the dedicated network resources since only one Slice-Flow Aggregate traffic stream can traverse the dedicated resource at any time. To optimize network utilization, sharing of the physical network resources may be desirable. In such case, the same physical network resource capacity is divided among multiple NRPs that support multiple Slice-Flow Aggregates. The shared physical network resources can be partitioned in the data plane (for example by applying hardware policers and shapers) and/or partitioned in the control plane by providing a logical representation of the physical link that has a subset of the network resources available to it.

IETF Network Slice Realization describes the steps required to realize an IETF network slice service in a provider network using the solution proposed in this document. While Figure 4 of provides an abstract architecture of an IETF Network Slice, this section intends to offer a realization of that architecture specific for IP/MPLS packet networks. Each of the steps is further elaborated on in a subsequent section.

IETF network slice realization steps. >>>>>>>>>>>>>> Slice-Flow \ / View v ^ Aggregate Mapping v v v ^ ----------------------------------------- v ^ ( |PE|.......|PE|........|PE|.......|PE| ) --------- ( --: -- :-- -- ) | | ( :...................: ) | NSC | ( Network Resource Partition ) | | ----------------------------------------- | | ^ | |>>>>> Resource Partitioning | --------- of Filtered Topology| v v | v v ----------------------------- -------- v v (|PE|..-..|PE|... ..|PE|..|PE|) ( ) v v ( :-- |P| -- :-: -- :-- ) ( Filter ) v v ( :.- -:.......|P| :- ) ( Topology ) v v ( |P|...........:-:.......|P| ) ( ) v v ( - Filtered Topology ) -------- v v ----------------------------- ^ v >>>>>>>>>>>> Topology Filter ^ / v ...........................\............../........... v \ / Underlay ---------- \ / (Physical) | | \ / Network | Network | ---------------------------------------------- |Controller| ( |PE|.....-.....|PE|...... |PE|.......|PE| ) | | ( -- |P| -- :-...:-- -..:-- ) ---------- ( : -:.............|P|.........|P| ) v ( -......................:-:..- - ) >>>>>>> ( |P|.........................|P|......: ) Program the ( - - ) Network ---------------------------------------------- (NRP Policies and Paths)* * : NRP Policy installation and path placement can be centralized or distributed. ]]>

Network Topology Filters The Physical Network may be filtered into a number of Filter Topologies. Filter actions may include selection of specific nodes and links according to their capabilities and are based on network- wide policies. The resulting topologies can be used to host IETF Network Slices and provide a useful way for the network operator to know that all of the resources they are using to plan a network slice meet specific SLOs. This step can be done offline during planning activity, or could be performed dynamically as new demands arise. describes how topology filters can be associated with the NRP instantiated by the NRP Policy.

IETF Network Slice Service Request The customer requests an IETF Network Slice Service specifying the CE-AC-PE points of attachment, the connectivity matrix, and the SLOs/SLEs as described in . These capabilities are always provided based on a Service Level Agreement (SLA) between the network slice customer and the provider. This defines the traffic flows that need to be supported when the slice is realized. Depending on the mechanism and encoding of the Attachment Circuit (AC), the IETF Network Slice Service may also include information that will allow the operator's controllers to configure the PEs to determine what customer traffic is intended for this IETF Network Slice. IETF Network Slice Service Requests are likely to arrive at various times in the life of the network, and may also be modified.

Slice-Flow Aggregation A network may be called upon to support very many IETF Network Slices, and this could present scaling challenges in the operation of the network. In order to overcome this, the IETF Network Slice streams may be aggregated into groups according to similar characteristics. A Slice-Flow Aggregate is a construct that comprises the traffic flows of one or more IETF Network Slices. The mapping of IETF Network Slices into a Slice-Flow Aggregate is a matter of local operator policy and is a function executed by the Controller. The Slice-Flow Aggregate may be preconfigured, created on demand, or modified dynamically.

Path Placement over NRP Filtered Topology Depending on the underlying network technology, the paths are selected in the network in order to best deliver the SLOs for the different services carried by the Slice-Flow Aggregate. The path placement function (carried on ingress node or by a controller) is performed on the Filtered Topology that is selected to support the Slice-Flow Aggregate. Note that this step may indicate the need to increase the capacity of the underlying Filtered Topology or to create a new Filtered Topology.

NRP Policy An NRP policy is a policy construct that enables instantiation of mechanisms in support of service specific control and data plane behaviors on select topological elements associated with the NRP. The NRP Policy is a construct that enables the instantiation of control and data plane behaviors on select topological elements in support of the IETF network slice service. The NRP Policy encompasses policy actions (see ) that manage the specific resources in the network associated with the NRP.

NRP Policy Installation A Controller function programs the physical network with the NRP policies to define specific handling for traffic flows belonging to the Slice-Flow Aggregate. These NRP policies may be consumed on select topological elements in the network and as a result define how routers handle traffic for the Slice-Flow Aggregate associated with the NRP. For example, the routers that instantiate the NRP Policy can correlate markers that are present in packets that belong to the Slice-Flow Aggregate and apply specific treatments to them. The way in which the NRP Policy is installed in the routers and the way that the traffic is marked is implementation specific. The NRP Policy instantiation in the network is further described in .

Path Instantiation Depending on the underlying network technology, a Controller function may install the forwarding state specific to the Slice-Flow Aggregate so that traffic is routed along paths derived in the Path Placement step described in . The way in which the paths are instantiated is implementation specific.

Service Mapping The edge points can be configured to support the network slice service by mapping the customer traffic to Slice-Flow Aggregates, possibly using information supplied when the IETF network slice service was requested. The edge points may also be instructed to mark the packets so that the network routers will know which policies and routing instructions to apply. The steering of traffic onto Slice-Flow Aggregate paths is further described in .

Network Resource Partition Modes An NRP Policy can be used to dictate if the network resource partitioning of the shared network resources among multiple Slice-Flow Aggregates can be achieved:

1. in data plane only,
2. in control plane only, or
3. in both control and data planes.

Data plane Network Resource Partition Mode The physical network resources can be partitioned on network devices by applying a Per Hop forwarding Behavior (PHB) onto packets that traverse the network devices. When data plane NRP mode is applied, packets need to be forwarded on the specific NRP that supports the Slice-Flow Aggregate to ensure the proper forwarding treatment dictated in the NRP Policy is applied (refer to below). In this case, an NRP Selector must be carried in each packet to identify the Slice-Flow Aggregate that it belongs to. The ingress node of an NRP domain adds an NRP Selector field (if not already present) in each Slice-Flow Aggregate packet. In the data plane NRP mode, the transit nodes within an NRP domain use the NRP Selector to associate packets with a Slice-Flow Aggregate and to determine the Network Resource Partition Per Hop Behavior (NRP-PHB) that is applied to the packet (refer to for further details). The CS MAY be used to apply a Diffserv PHB on to the packet to allow differentiation of traffic treatment within the same Slice-Flow Aggregate. When data plane only NRP mode is used, routers may rely on a network state independent view of the topology to determine the best paths. In this case, the best path selection dictates the forwarding path of packets to the destination. The NRP Selector field carried in each packet determines the specific NRP-PHB treatment along the selected path. The data plane NRP mode can provide two levels of isolation between NRPs:

• Strict isolation: Each NRP is assigned dedicated hardware resources (e.g., queues, schedulers, and policers) that are not shared with other NRPs. This ensures that traffic of one NRP cannot contend with or impact traffic of another NRP.
• Shared hardware isolation: Multiple NRPs may share the same underlying hardware resources, but are differentiated by the NRP Selector and the NRP-PHB applied to their traffic. In this case, isolation is statistical and depends on the configured scheduling and policing policies.

Control Plane Network Resource Partition Mode Multiple NRPs can be realized over the same set of physical resources. Each NRP is identified by an identifier (NRP-ID) that is globally unique within the NRP domain. The NRP state reservations for each NRP can be maintained on the network element or on a controller. The network reservation states for a specific partition can be represented in a topology that contains all or a subset of the physical network elements (nodes and links) and reflect the network state reservations in that NRP. The logical network resources that appear in the NRP topology can reflect a part, whole, or in-excess of the physical network resource capacity (e.g., when oversubscription is desirable). For example, the physical link bandwidth can be divided into fractions, each dedicated to an NRP that supports a Slice-Flow Aggregate. The topology associated with the NRP supporting a Slice-Flow Aggregate can be used by routing protocols, or by the ingress/PCE when computing NRP state aware TE paths. To perform NRP state aware Traffic Engineering (NRP-TE), the resource reservation on each link needs to be NRP aware. The NRP reservations state can be managed locally on the device or off device (e.g. on a controller). The same physical link may be a member of multiple slice policies that instantiate different NRPs. The NRP reservable or utilized bandwidth on such a link is updated (and may be advertised) whenever new paths are placed in the network. The NRP reservation state, in this case, is maintained on each device or off the device on a resource reservation manager that holds reservation states for those links in the network. Multiple NRPs that support Slice-Flow Aggregates can form a group and share the available network resources allocated to each. In this case, a node can update the reservable bandwidth for each NRP to take into consideration the available bandwidth from other NRPs in the same group. For illustration purposes, describes bandwidth partitioning or sharing amongst a group of NRPs. In Figure 2a, the NRPs identified by the following NRP-IDs: NRP1, NRP2, NRP3 and NRP4 are not sharing any bandwidths between each other. In Figure 2b, the NRPs: NRP1 and NRP2 can share the available bandwidth portion allocated to each amongst them. Similarly, NRP3 and NRP4 can share amongst themselves any available bandwidth allocated to them, but they cannot share available bandwidth allocated to NRP1 or NRP2. In both cases, the Max Reservable Bandwidth may exceed the actual physical link resource capacity to allow for oversubscription.

Bandwidth isolation/sharing among NRPs. I I-----------------I I I---------I I I <-NRP1-> I I I I I I I-------I I I I---------I I I I I I I I I I I-------I I I <-----NRP2------> I I I I I-----------------I I I <-NRP2-> I I I I I I I---------I I I I-----------------I I I I I I I I I I I---------I I I <---NRP3----> I I I I I-------------I I I NRP1 + NRP2 I I I I I I-----------------I I I-------------I I I I I I I I <---NRP4----> I I-----------------I I I-------------I I I <-NRP3-> I I I I I I I-------I I I I-------------I I I I I I I I I I I-------I I I I NRP1+NRP2+NRP3+NRP4 I I I I I I I <-NRP4-> I I I-----------------------------I I I---------I I I <--Max Reservable Bandwidth--> I I I I I I I---------I I I I I I I NRP3 + NRP4 I I I-----------------I I I NRP1+NRP2+NRP3+NRP4 I I I I-----------------------------I <--Max Reservable Bandwidth--> (a) No bandwidth sharing (b) Sharing bandwidth between between NRPs. NRPs of the same group. ]]>

The control plane NRP mode provides isolation at admission time by ensuring that the total bandwidth reserved across NRPs does not exceed the available physical link capacity (subject to any configured oversubscription). However, since no per-packet forwarding enforcement is applied in this mode, traffic from different NRPs may contend for the same physical resources at runtime, and isolation guarantees are soft. To compensate, the control plane MAY monitor link utilization and detect congestion, and react by reoptimizing the placement of affected traffic flows onto less loaded paths within the NRP topology.

Data and Control Plane Network Resource Partition Mode In order to support strict guarantees for Slice-Flow Aggregates, the network resources can be partitioned in both the control plane and data plane. The control plane partitioning allows the creation of customized topologies per NRP that each supports a Slice-Flow Aggregate. The ingress routers or a Path Computation Engine (PCE) may use the customized topologies and the NRP state to determine optimal path placement for specific demand flows using NRP-TE. The data plane partitioning provides isolation for Slice-Flow Aggregate traffic, and protection when resource contention occurs due to bursts of traffic from other Slice-Flow Aggregate traffic that traverses the same shared network resource. The combination of control and data plane partitioning provides the strongest form of NRP isolation. The control plane ensures that admitted traffic across NRPs does not exceed the available network resources, while the data plane enforces per-packet forwarding treatment at runtime, preventing traffic bursts from one NRP from impacting the resources available to other NRPs.

Network Resource Partition Instantiation A network slice can span multiple technologies and multiple administrative domains. Depending on the network slice customer requirements, a network slice can be differentiated from other network slices in terms of data, control, and management planes. The customer of a network slice service expresses their intent by specifying requirements rather than mechanisms to realize the slice as described in . The network slice controller is fed with the network slice service intent and realizes it with an appropriate Network Resource Partition Policy (NRP Policy). Multiple IETF network slices are mapped to the same Slice-Flow Aggregate as described in . The network wide consistent NRP Policy definition is distributed to the devices in the network as shown in . The specification of the network slice intent on the northbound interface of the controller and the mechanism used to map the network slice to a Slice-Flow Aggregate are outside the scope of this document and will be addressed in separate documents.

NRP Policy Definition The NRP Policy is a network-wide construct that is supplied to network devices, and may include rules that control the following:

• Data plane specific policies: This includes the NRP Selector, any firewall rules or flow-spec filters, and QoS profiles associated with the NRP Policy and any classes within it.
• Control plane specific policies: This includes bandwidth reservations, any network resource sharing amongst slice policies, and reservation preference to prioritize reservations of a specific NRP over others.
• Topology membership policies: This defines the topology filter policies that dictate node/link/function membership to a specific NRP.

There is a desire for flexibility in realizing network slices to support the services across networks consisting of implementations from multiple vendors. These networks may also be grouped into disparate domains and deploy various path control technologies and tunnel techniques to carry traffic across the network. It is expected that a standardized data model for NRP Policy will facilitate the instantiation and management of the NRP on the topological elements selected by the NRP Policy topology filter. It is also possible to distribute the NRP Policy to network devices using several mechanisms, including protocols such as NETCONF or RESTCONF, or exchanging it using a suitable routing protocol that network devices participate in (such as IGP(s) or BGP). The extensions to enable specific protocols to carry an NRP Policy definition will be described in separate documents.

Network Resource Partition Selector A router needs to be able to identify a packet belonging to a Slice- Flow Aggregate before it can apply the associated data plane forwarding treatment or NRP-PHB. One or more fields within the packet are used as an NRP Selector to do this. There are several possible approaches as follows. The NRP Selector can be defined for and carried in different forwarding data planes. For example:

• In MPLS networks, the NRP Selector may be encoded within the MPLS label stack or post stack.
• In IPv6 networks, the NRP Selector may be carried within fields of the IPv6 header (e.g., source or destination address), or within an IPv6 extension header.
• In SRv6 networks, the NRP Selector may be encoded as a SRv6 SID or carried within the Segment Routing Header (SRH) (e.g., as a TLV).

The specific encoding depends on the data plane technology deployed in the NRP domain and is outside the scope of this document. Overloaded forwarding identifier as NRP Selector:

• It is possible to assign a different forwarding address or MPLS forwarding label for each Slice-Flow Aggregate on a specific node in the network. This allows Slice-Flow Aggregate packets destined to a node to be distinguished by the destination address or the MPLS forwarding label that is carried in the packet. This approach requires maintaining per Slice-Flow Aggregate state for each destination in the network in both the control and data plane and on each router in the network. Hence this approach scales as a multiple of the number of Slice-Flow Aggregates and the number of adjacencies each node has which is a scalability challenge in both the control and data planes.

Overloaded service identifier as NRP Selector:

• VPN identifiers can be carried in the IP/MPLS forwarding plane using a variety of techniques (including MPLS VPN service labels). These identifiers can be overloaded to act as NRP Selectors to allow VPN packets to be mapped to the Slice-Flow Aggregate. In this case, a single VPN identifier acting as an NRP Selector needs to be allocated by all Egress PEs of a VPN.

• In other cases, a range of VPN identifiers can map to a single NRP Selector to map traffic from multiple VPNs to a Slice-Flow Aggregate.

The following figure illustrates this overloading approach using a VPN identifier and an MPLS data plane as an example. Other service identifiers and data plane technologies may be used in a similar manner.

NRP Selector as VPN label at bottom of label stack.

Dedicated identifier as NRP Selector:

• A dedicated identifier may be defined to act as the NRP Selector ID to be carried in packets of Slice-Flow Aggregate, independent of the forwarding address or MPLS forwarding label bound to the destination and independent of any VPN identifiers. Routers within the NRP domain can use the forwarding address or MPLS forwarding label to determine the forwarding next-hops, and use the NRP Selector in the packet to infer the specific forwarding treatment that needs to be applied on the packet.

• The NRP Selector, in this case, can be carried in one of multiple fields in the packet, depending on the data plane in use. All packets that belong to the same Slice-Flow Aggregate may carry the same NRP Selector, but it is also possible to have multiple NRP Selectors map to the same Slice-Flow Aggregate.

Fallback treatment for unclassified packets:

• A packet carrying an NRP Selector may arrive at an NRP-capable node on which no NRP matching that NRP Selector value is instantiated. In such cases, the node is unable to associate the packet with any NRP and therefore cannot apply the corresponding NRP-PHB forwarding treatment. The following fallback treatments MAY be applied in this case:
  • Drop: The packet is discarded. This is the RECOMMENDED default behavior, as it prevents packets with unrecognized NRP Selectors from consuming resources of other NRPs on the node.
  • Best-effort forwarding: The packet is forwarded using the node's default best-effort forwarding treatment, without any NRP-specific resource guarantees.
  • Default NRP forwarding: The packet is mapped to a pre-configured default NRP on the node, which provides a baseline forwarding treatment for unmatched traffic.
  The choice of fallback treatment SHOULD be configurable via local policy. A field in the data plane MAY be used to signal the desired fallback treatment for the NRP, allowing the ingress node to influence the behavior at downstream nodes.

Network Resource Partition Resource Reservation Bandwidth and network resource allocation strategies for slice policies are essential to achieve optimal placement of paths within the network while still meeting the target SLOs. Resource reservation allows for the management of available bandwidth and the prioritization of existing allocations to enable preference-based preemption when contention on a specific network resource arises. Sharing of a network resource's available bandwidth amongst a group of NRPs may also be desirable. For example, a Slice-Flow Aggregate may not be using all of the NRP reservable bandwidth; this allows other NRPs in the same group to use the available bandwidth resources for other Slice-Flow Aggregates. Congestion on shared network resources may result from sub-optimal placement of paths in different slice policies. When this occurs, preemption of some Slice-Flow Aggregate paths may be desirable to alleviate congestion. A preference-based allocation scheme enables prioritization of Slice-Flow Aggregate paths that can be preempted. Since network characteristics and its state can change over time, the NRP topology and its network state need to be propagated in the network to enable ingress TE routers or Path Computation Engine (PCEs) to perform accurate path placement based on the current state of the NRP network resources.

Network Resource Partition Per Hop Behavior The NRP Per Hop Behavior (NRP-PHB) is the externally observable forwarding behavior applied to a specific packet belonging to a Slice-Flow Aggregate. The goal of an NRP-PHB is to provide a specified amount of network resources for traffic belonging to a specific Slice-Flow Aggregate. A single NRP may also support multiple forwarding treatments or services that can be carried over the same logical network. The Slice-Flow Aggregate traffic may be identified at NRP ingress boundary nodes by carrying a NRP Selector to allow routers to apply a specific forwarding treatment that guarantees the SLA(s). To support multiple forwarding treatments over the same Slice-Flow Aggregate, a Slice-Flow Aggregate packet may also carry a Diffserv CS to identify the specific Diffserv forwarding treatment to be applied on the traffic belonging to the same NRP. At transit nodes, the CS field carried inside the packets are used to determine the specific PHB that determines the forwarding and scheduling treatment before packets are forwarded, and in some cases, drop probability for each packet.

Network Resource Partition Topology The relationship between the physical network, the Filtered Topology, and the NRP topology can be described as follows:

1. The Physical Network comprises the underlying nodes and links with their actual hardware resources (e.g., bandwidth, processing capacity).
2. A Filtered Topology is derived from the Physical Network by applying topology filtering policies that select specific nodes and links based on their capabilities and attributes (as described in ). The same Filtered Topology may be shared by multiple NRPs.
3. An NRP is instantiated on a Filtered Topology by associating NRP-specific resource reservations () and Per Hop Behavior () with the topological elements of the Filtered Topology. The resulting topology, comprising the filtered nodes and links together with their NRP-specific resource attributes, is referred to as the NRP Topology.

Since the same Filtered Topology may underlie multiple NRPs, two NRPs may share the same set of nodes and links while having different resource reservations and forwarding treatments applied to them. A key element of the NRP Policy is a customized topology that may include the full or a subset of the physical network topology. The NRP topology could also span multiple administrative domains and/or multiple dataplane technologies. An NRP topology can overlap or share a subset of links with another NRP topology. A number of topology filtering policies can be defined as part of the NRP Policy to limit the specific topology elements that belong to the NRP. For example, a topology filtering policy can leverage Resource Affinities as defined in to include or exclude certain links that the NRP is instantiated on in support of the Slice-Flow Aggregate. The NRP Policy may also include a reference to a predefined topology (e.g., derived from a Flexible Algorithm Definition (FAD) as defined in , or Multi-Topology ID as defined in .

Network Resource Partition Boundary A network slice originates at the edge nodes of a network slice provider. Traffic that is steered over the corresponding NRP supporting a Slice-Flow Aggregate may traverse NRP capable as well as NRP incapable interior nodes. The network slice may encompass one or more domains administered by a provider. For example, an organization's intranet or an ISP. The network provider is responsible for ensuring that adequate network resources are provisioned and/or reserved to support the SLAs offered by the network end-to-end.

Network Resource Partition Edge Nodes NRP edge nodes sit at the boundary of a network slice provider network and receive traffic that requires steering over network resources specific to a NRP that supports a Slice-Flow Aggregate. These edge nodes are responsible for identifying Slice-Flow Aggregate specific traffic flows by possibly inspecting multiple fields from inbound packets (e.g., implementations may inspect IP traffic's network 5-tuple in the IP and transport protocol headers) to decide on which NRP it can be steered. Network slice ingress nodes may condition the inbound traffic at network boundaries in accordance with the requirements or rules of each service's SLAs. The requirements and rules for network slice services are set using mechanisms which are outside the scope of this document. When data plane NRP mode is employed, the NRP ingress nodes are responsible for setting a suitable NRP Selector on packets that belong to the Slice-Flow Aggregate, and optionally the desired Diffserv CS. describes different IETF Network Slice Service Demarcation Point (SDP) locations that determine where the NRP edge function is performed. The following describes how the solution described in this document caters to each SDP location:

SDP within the CE:

When the CE is operated by the IETF Network Slice Service provider, the CE itself acts as the NRP ingress node. The CE may classify inbound traffic, set the NRP Selector, and enforce the NRP-PHB on the outgoing interface. In this case, slicing resources may include buffers and queues on the CE outgoing interfaces.

SDP at the CE/AC boundary:

When the IETF Network Slice extends to include the Attachment Circuit (AC), traffic conditioning and policing are applied at the AC ends. The CE or PE may use traffic tagging (e.g., Ethernet VLAN tags) to identify the IETF Network Slice. The NRP Selector may be set by the CE or by the PE upon receiving the tagged traffic from the AC.

SDP at the PE customer-facing port:

The PE's customer-facing port acts as the NRP ingress node. In this case, the port or VLAN tag on the incoming traffic identifies the IETF Network Slice and the corresponding Slice-Flow Aggregate. The PE sets the NRP Selector on the inbound packets before forwarding them into the NRP domain.

SDP within the PE:

The PE classifies inbound traffic from the AC by inspecting multiple packet fields (e.g., the IP 5-tuple) to identify the IETF Network Slice and the corresponding Slice-Flow Aggregate. The PE then sets the NRP Selector on the classified packets before forwarding them into the NRP domain.

Network Resource Partition Interior Nodes An NRP interior node receives slice traffic and may be able to identify the packets belonging to a specific Slice-Flow Aggregate by inspecting the NRP Selector field carried inside each packet, or by inspecting other fields within the packet that may identify the traffic streams that belong to a specific Slice-Flow Aggregate. For example, when data plane NRP mode is applied, interior nodes can use the NRP Selector carried within the packet to apply the corresponding NRP-PHB forwarding behavior.

Network Resource Partition Incapable Nodes Packets that belong to a Slice-Flow Aggregate may need to traverse nodes that are NRP incapable. In this case, several options are possible to allow the slice traffic to continue to be forwarded over such devices and be able to resume the NRP forwarding treatment once the traffic reaches devices that are NRP-capable. When data plane NRP mode is employed, packets carry a NRP Selector to allow slice interior nodes to identify them. To support end-to-end network slicing, the NRP Selector is maintained in the packets as they traverse devices within the network -- including NRP capable and incapable devices. For example, when the NRP Selector is an MPLS label at the bottom of the MPLS label stack, packets can traverse over devices that are NRP incapable without any further considerations. On the other hand, when the NRP Selector label is at the top of the MPLS label stack, packets can be bypassed (or tunneled) over the NRP incapable devices towards the next device that supports NRP as shown in .

Extending network slice over NRP incapable device(s).

An NRP-capable node needs to identify which of its downstream neighbors are NRP incapable in order to apply the appropriate bypass or tunnel treatment described above. The following mechanisms MAY be used for this purpose:

Controller-based discovery:

In controller-based deployments, NRP node capabilities MAY be distributed to a controller using mechanisms such as NETCONF , BGP-LS , or PCEP . The controller or PCE can then use this information when computing paths to steer traffic around NRP incapable nodes or to select appropriate bypass tunnels.

Static configuration:

As a fallback, operators MAY statically configure on each node which of its downstream neighbors are NRP incapable. This approach is simple but does not adapt automatically to topology or capability changes.

Combining Network Resource Partition Modes It is possible to employ a combination of the NRP modes that were discussed in to realize a network slice. For example, data and control plane NRP modes can be employed in parts of a network, while control plane NRP mode can be employed in the other parts of the network. The path selection, in such case, can take into account the NRP available network resources. The NRP Selector carried within packets allow transit nodes to enforce the corresponding NRP-PHB on the parts of the network that apply the data plane NRP mode. The NRP Selector can be maintained while traffic traverses nodes that do not enforce data plane NRP mode, and so slice PHB enforcement can resume once traffic traverses capable nodes.

Multi-domain Network Resource Partition Considerations A network slice may span multiple NRP domains, each administered by the same or different providers. In such deployments, the NRP boundary nodes at the edges of each domain are responsible for ensuring that the appropriate NRP treatment is applied within their domain and that end-to-end SLAs are maintained across domain boundaries. When a network slice traverses multiple NRP domains, the NRP Selector carried in packets may be handled at domain boundaries in one of the following ways:

NRP Selector Stacking:

The original NRP Selector (e.g., for NRP1) is preserved in the packet end-to-end. When entering an intermediate NRP domain (e.g., NRP2), the ingress boundary node of that domain adds the intermediate domain's NRP Selector to the packet. Interior nodes within the intermediate domain use the added NRP Selector to apply the corresponding NRP-PHB treatment. Upon exiting the intermediate domain, the egress boundary node removes the intermediate domain's NRP Selector, re-exposing the original NRP Selector. The original NRP treatment resumes in the next NRP domain. The specific mechanism for adding and removing the NRP Selector is data-plane dependent (e.g., pushing and popping a label in MPLS, or encoding in a packet header field in other data planes). This approach does not require NRP-ID coordination across domain boundaries.

NRP Selector Remapping:

At the boundary between two NRP domains, the boundary node replaces the incoming NRP Selector with the appropriate NRP Selector for the downstream domain. This requires coordination of NRP-ID mappings at inter-domain boundaries, which may be achieved via static configuration or via a controller (e.g., using NETCONF , BGP-LS , or PCEP ). The boundary node is also responsible for conditioning traffic to conform to the downstream domain's SLA allocation before forwarding.

In both approaches, each NRP domain is responsible for provisioning sufficient resources within its domain to meet its portion of the end-to-end SLA. The overall end-to-end SLA is satisfied when the combined resource allocations across all NRP domains collectively meet the SLOs and SLEs agreed upon in the IETF Network Slice Service request. Inter-domain path computation for network slices spanning multiple NRP domains may be performed using a hierarchical PCE (H-PCE) architecture, per-domain PCEs coordinating via PCEP , or a centralized controller with visibility across all domains.

Mapping Traffic on Slice-Flow Aggregates The usual techniques to steer traffic onto paths can be applicable when steering traffic over paths established for a specific Slice-Flow Aggregate. For example, one or more (layer-2 or layer-3) VPN services can be directly mapped to paths established for a Slice-Flow Aggregate. In this case, the per Virtual Routing and Forwarding (VRF) instance traffic that arrives on the Provider Edge (PE) router over external interfaces can be directly mapped to a specific Slice-Flow Aggregate path. External interfaces can be further partitioned (e.g., using VLANs) to allow mapping one or more VLANs to specific Slice-Flow Aggregate paths. Another option is steer traffic to specific destinations directly over multiple slice policies. This allows traffic arriving on any external interface and targeted to such destinations to be directly steered over the slice paths. A third option that can also be used is to utilize a data plane firewall filter or classifier to enable matching of several fields in the incoming packets to decide whether the packet belongs to a specific Slice-Flow Aggregate. This option allows for applying a rich set of rules to identify specific packets to be mapped to a Slice-Flow Aggregate. However, it requires data plane network resources to be able to perform the additional checks in hardware.

Network Slice-Flow Aggregate Relationships The following describes the generalization relationships between the IETF network slice and different parts of the solution as described in . o A customer may request one or more IETF Network Slices. o Any given Attachment Circuit (AC) may support the traffic for one or more IETF Network Slices. If there is more than one IETF Network Slice using a single AC, the IETF Network Slice Service request must include enough information to allow the edge nodes to demultiplex the traffic for the different IETF Network Slices. o By definition, multiple IETF Network Slices may be mapped to a single Slice-Flow Aggregate. However, it is possible for an Slice-Flow Aggregate to contain just a single IETF Network Slice. o The physical network may be filtered to multiple Filter Topologies. Each such Filtered Topology facilitates planning the placement of paths for the Slice-Flow Aggregate by presenting only the subset of links and nodes that meet specific criteria. Note, however, in absence of any Filtered Topology, Slice-Flow Aggregate are free to operate over the full physical network. o It is anticipated that there may be very many IETF Network Slices supported by a network operator over a single physical network. A network may support a limited number of Slice-Flow Aggregates, with each of the Slice-Flow Aggregates grouping any number of the IETF Network Slices streams.

Path Selection and Instantiation

Applicability of Path Selection to Slice-Flow Aggregates In State-dependent TE , the path selection adapts based on the current state of the network. The state of the network can be based on parameters flooded by the routers as described in . The link state is advertised with current reservations, thereby reflecting the available bandwidth on each link. Such link reservations may be maintained centrally on a network wide network resource manager, or distributed on devices (as usually done with RSVP-TE). TE extensions exist today to allow IGPs (e.g., and ), and BGP-LS to advertise such link state reservations. When the network resource reservations are maintained for NRPs, the link state can carry per NRP state (e.g., reservable bandwidth). This allows path computation to take into account the specific network resources available for an NRP. In this case, we refer to the process of path placement and path provisioning as NRP aware TE (NRP-TE).

Applicability of Path Control Technologies to Slice-Flow Aggregates The NRP modes described in this document are agnostic to the technology used to set up paths that carry Slice-Flow Aggregate traffic. One or more paths connecting the endpoints of the mapped IETF network slices may be selected to steer the corresponding traffic streams over the resources allocated for the NRP that supports a Slice-Flow Aggregate. The feasible paths can be computed using the NRP topology and network state subject the optimization metrics and constraints.

RSVP-TE Based Slice-Flow Aggregate Paths RSVP-TE can be used to signal LSPs over the computed feasible paths in order to carry the Slice-Flow Aggregate traffic. The specific extensions to the RSVP-TE protocol required to enable signaling of NRP aware RSVP-TE LSPs are outside the scope of this document.

SR Based Slice-Flow Aggregate Paths Segment Routing (SR) can be used to set up and steer traffic over the computed Slice-Flow Aggregate feasible paths. The SR architecture defines a number of building blocks that can be leveraged to support the realization of NRPs that support Slice-Flow Aggregates in an SR network. Such building blocks include:

• SR Policy with or without Flexible Algorithm.
• Steering of services (e.g. VPN) traffic over SR paths
• SR Operation, Administration and Management (OAM) and Performance Management (PM)

SR allows a headend node to steer packets onto specific SR paths using a Segment Routing Policy (SR Policy). The SR policy supports various optimization objectives and constraints and can be used to steer Slice-Flow Aggregate traffic in the SR network. The SR policy can be instantiated with or without the IGP Flexible Algorithm (Flex-Algorithm) feature. It may be possible to dedicate a single SR Flex-Algorithm to compute and instantiate SR paths for one Slice-Flow Aggregate traffic. In this case, the SR Flex-Algorithm computed paths and Flex-Algorithm SR SIDs are not shared by other Slice-Flow Aggregates traffic. However, to allow for better scale, it may be desirable for multiple Slice-Flow Aggregates traffic to share the same SR Flex-Algorithm computed paths and SIDs.

Network Resource Partition Protocol Extensions Some protocols may need to be extended to carry additional NRP state. It is essential, however, that routing protocols, like IGPs or BGP, remain uninvolved in these areas to ensure they are isolated and maintain their scalability and stability. Furthermore, the complexity of routing protocols path selection should not be impacted by the increasing number of network slices and/or NRPs. The instantiation of an NRP Policy may need to be automated. Multiple options are possible to facilitate automation of distribution of an NRP Policy to capable devices. For example, a YANG data model for the NRP Policy may be supported on network devices and controllers. A suitable transport (e.g., NETCONF , RESTCONF , or gRPC) may be used to enable configuration and retrieval of state information for slice policies on network devices. The NRP Policy YANG data model is outside the scope of this document.

Outstanding Issues Note to RFC Editor: Please remove this section prior to publication. This section records non-blocking issues that were raised during the Working Group Adoption Poll for the document. The below list of issues needs to be fully addressed before progressing the document to publication in IESG.

1. [DONE] Add new Appendix section with examples for the NRP modes described in . Addressed by adding Appendix A with three sub-sections (A.1, A.2, A.3) providing concrete examples for the data plane, control plane, and combined NRP modes respectively, using a common 4-node topology.
2. [DONE] Elaborate on the Slice-Flow Aggregate packet treatment when no rules to associate the packet to an NRP are defined in the NRP Policy. Addressed in by adding fallback treatment options for packets carrying an NRP Selector that does not match any NRP instantiated on the node.
3. [DONE] Clarify how the solution caters to the different IETF Network Slice Service Demarcation Point locations described in Section 4.2 of . Addressed by adding explicit descriptions of how the NRP ingress classification and NRP Selector setting applies to each of the four SDP location options: SDP within the CE, SDP at the CE/AC boundary, SDP at the PE customer-facing port, and SDP within the PE.
4. [DONE] Clarify the relationship the underlay physical network, the Filtered Topology and the NRP resources. Addressed in by adding a three-step description of the layering: Physical Network -> Filtered Topology -> NRP Topology, and clarifying that the same Filtered Topology may be shared by multiple NRPs, each with its own resource reservations and forwarding treatments.
5. [DONE] Expand on how isolation between NRPs can be realized depending on the deployed NRP mode. Addressed in , , and by adding explicit isolation characterization for each mode.
6. [DONE] Revise to describe how nodes can discover NRP incapable downstream neighbors. Addressed by adding three discovery mechanisms: IGP-based capability advertisement (IS-IS/OSPF extensions), controller-based discovery (NETCONF , BGP-LS , or PCEP ), and static configuration as a fallback. Also clarified that dynamic NRP state SHOULD NOT be advertised via routing protocols to avoid convergence impact.
7. [DONE] Expand on additional security threats introduced with the solution. Added four new threat descriptions: NRP Policy Manipulation, NRP State Disclosure, Fallback NRP Abuse, and Inter-domain NRP Selector Spoofing, with corresponding mitigation guidance for each.
8. [DONE] Expand on NRP domain boundary and multi-domain aspects. Addressed by adding describing two approaches for handling NRP Selectors at inter-domain boundaries: NRP Selector Stacking (original NRP Selector preserved end-to-end, intermediate domain adds/removes its own NRP Selector) and NRP Selector Remapping (boundary node replaces NRP Selector with downstream domain equivalent). Also covers end-to-end SLA stitching and inter-domain path computation options.

IANA Considerations This document has no IANA actions.

Security Considerations The main goal of network slicing is to allow for varying treatment of traffic from multiple different network slices that are utilizing a common network infrastructure and to allow for different levels of services to be provided for traffic traversing a given network resource. A variety of techniques may be used to achieve this, but the end result will be that some packets may be mapped to specific resources and may receive different (e.g., better) service treatment than others. The mapping of network traffic to a specific NRP is indicated primarily by the NRP Selector, and hence an adversary may be able to utilize resources allocated to a specific NRP by injecting packets carrying the same NRP Selector field in their packets. Such theft-of-service may become a denial-of-service attack when the modified or injected traffic depletes the resources available to forward legitimate traffic belonging to a specific NRP. The defense against this type of theft and denial-of-service attacks consists of a combination of traffic conditioning at NRP domain boundaries with security and integrity of the network infrastructure within an NRP domain.

NRP Policy Manipulation:

The NRP Policy controls resource allocation, topology membership, and forwarding treatment for each NRP. An adversary that gains access to the management plane (e.g., via a compromised controller or network device) may modify NRP Policies to reroute traffic, alter resource reservations, or deprive legitimate NRPs of network resources. Securing the management plane through authentication, authorization, and integrity protection of NRP Policy distribution mechanisms (e.g., NETCONF/RESTCONF) is therefore essential.

NRP State Disclosure:

Extensions that advertise NRP topology and resource reservation states may expose sensitive information about the network's internal resource allocations to any adversary participating in the routing protocol. Operators SHOULD apply appropriate route filtering and authentication mechanisms on routing protocol sessions to limit the propagation of NRP state information to trusted participants only.

Fallback NRP Abuse:

When a fallback NRP or best-effort treatment is configured for packets carrying unrecognized NRP Selectors, an adversary may deliberately inject packets with invalid or unrecognized NRP Selector values to consume the resources of the fallback NRP. Operators SHOULD apply traffic conditioning and rate limiting at NRP domain boundaries to mitigate this threat.

Inter-domain NRP Selector Spoofing:

In deployments where NRP Selectors traverse administrative domain boundaries, an adversary at a peering point may inject or modify NRP Selector values to gain access to resources of a specific NRP in the downstream domain. Operators SHOULD validate and condition NRP Selector values at inter-domain boundaries, and SHOULD NOT trust NRP Selectors received from untrusted domains without appropriate verification.

Acknowledgement The authors would like to thank Krzysztof Szarkowicz, Swamy SRK, Navaneetha Krishnan, Prabhu Raj Villadathu Karunakaran, and Mohamed Boucadair for their review of this document and for providing valuable feedback on it. The authors would also like to thank Adrian Farrel for detailed discussions that resulted in .

Contributors The following individuals contributed to this document:

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In a number of environments, a component external to a network is called upon to perform computations based on the network topology and 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 new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual 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 describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] 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] Informative 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. This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK] 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. Cisco Systems, Inc. Juniper Networks, Inc. Cisco Systems, Inc. Cisco Systems, Inc Edward Jones IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology. An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] Old Dog Consulting This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. 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 an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).

NRP Mode Examples This appendix provides examples to illustrate the NRP modes described in . All examples use the following common network topology:

Common topology for NRP mode examples.

Two NRPs are instantiated over this network:

• NRP1: supports low-latency Slice-Flow Aggregate (SFA1), with a minimum bandwidth guarantee of 4 Gbps per link.
• NRP2: supports best-effort Slice-Flow Aggregate (SFA2), with up to 6 Gbps per link.

Data Plane NRP Mode Example In this example, network resource partitioning is performed in the data plane only. PE1 acts as the NRP ingress node and classifies inbound CE1 traffic into two Slice-Flow Aggregates based on the IP 5-tuple, and pushes a dedicated NRP Selector label onto each packet:

• SFA1 (NRP1): NRP Selector label = 1001
• SFA2 (NRP2): NRP Selector label = 1002

Transit nodes P1 and P2 use the NRP Selector label to apply the corresponding NRP-PHB. PE2 pops the NRP Selector label before forwarding traffic to CE2. The packet label stack at each node for an SFA1 (NRP1) packet: Since data plane only NRP mode is used, P1 and P2 do not maintain per-NRP routing state. The forwarding path is determined by standard best-path selection; the NRP Selector solely determines the NRP-PHB applied at each hop.

Control Plane NRP Mode Example In this example, network resource partitioning is performed in the control plane only. No NRP Selector is carried in packets. Instead, per-NRP bandwidth is reserved on each link, and NRP-aware TE paths are computed using these reservations. The 10 Gbps physical link bandwidth is divided between the two NRPs:

• NRP1: 4 Gbps reserved bandwidth per link
• NRP2: 6 Gbps reserved bandwidth per link

The per-NRP reservations are maintained on each network element (or on a controller) and may be advertised via a routing protocol for NRP-state-aware path computation. The ingress node PE1 (or a PCE) uses the NRP-specific topology and available bandwidth to compute TE paths for each SFA:

• SFA1 path: PE1->P1->P2->PE2 (using NRP1's 4 Gbps pool)
• SFA2 path: PE1->P1->P2->PE2 (using NRP2's 6 Gbps pool)

Since no NRP Selector is carried in packets, transit nodes P1 and P2 apply no per-packet NRP-specific forwarding treatment. Isolation between NRP1 and NRP2 is enforced at admission time only; traffic from both NRPs shares the same physical queues at runtime, and isolation guarantees are soft.

Data and Control Plane NRP Mode Example In this example, network resource partitioning is performed in both the control plane and the data plane, combining the mechanisms of and . As in A.2, per-NRP bandwidth is reserved per link (NRP1: 4 Gbps, NRP2: 6 Gbps), and NRP-aware TE paths are computed for each SFA. Additionally, as in A.1, PE1 pushes an NRP Selector label onto each packet, and P1/P2 apply dedicated per-NRP queues based on the NRP Selector. The combined mode provides the strongest isolation:

• The control plane ensures the total admitted traffic across NRP1 and NRP2 does not exceed the physical link capacity.
• The data plane enforces per-packet forwarding treatment at runtime, preventing traffic bursts from NRP2 from consuming resources reserved for NRP1.