RFC 9543
A Framework for Network Slices in Networks Built from IETF Technologies
RFC 9543: A Framework for Network Slices in Networks Built from IETF Technologies 🎀✨
okay so bestie, this RFC is all about network slices, and it's giving "VPN but make it extra committed" 💅. It's Informational, so it's not a Standards Track spec, just a framework to help everyone talk about the same thing 🦋. Published March 2024 by the IETF, it's ISSN 2070-1721, and nothing in the title block says it obsoletes or updates another RFC 🌸.
The editors are A. Farrel (Old Dog Consulting) and J. Drake (Individual), with co-authors R. Rokui (Ciena), S. Homma (NTT), K. Makhijani (Futurewei), L. Contreras (Telefonica), and J. Tantsura (Nvidia). Iconic team 👑🫶.
Abstract 📝
okay so the abstract is literally the whole pitch 💖. It describes network slicing for networks built from IETF technologies, and it defines the term "IETF Network Slice" to name this specific type of slice 🧚. It also sets out the general principles of slicing in the IETF context.
The doc walks through the framework for requesting and running IETF Network Slices, what makes one tick, the system parts and interfaces needed, and how abstract requests get mapped down to specific technologies 🔥. There's also stuff on monitoring and security 🙈, plus definitions of related terms so other IETF docs can use the same vocab without confusion 💜.
Status of This Memo 🌈
so this one is NOT a Standards Track spec. It's published purely for information 💅. It's still a product of the IETF, it reflects IETF community consensus, got public review, and was approved by the IESG ✨. Not everything the IESG approves ends up as an Internet Standard, so check Section 2 of RFC 7841 if you're curious about that 🌸.
For current status, errata, or feedback, head to https://www.rfc-editor.org/info/rfc9543 🦋.
Copyright Notice 💜
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read them carefully, bestie, because they spell out your rights and restrictions 🫶. Any Code Components pulled from this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in that license 😭.
Table of Contents 🧚
Here's the full map, verbatim so you can navigate like a pro:
1. Introduction
2. Background
3. Terms and Abbreviations
3.1. Abbreviations
3.2. Core Terminology
4. IETF Network Slice
4.1. Definition and Scope of IETF Network Slice
4.2. IETF Network Slice Service
4.2.1. Connectivity Constructs
4.2.2. Mapping Traffic Flows to Network Realizations
4.2.3. Ancillary CEs
5. IETF Network Slice System Characteristics
5.1. Objectives for IETF Network Slices
5.1.1. Service Level Objectives
5.1.2. Service Level Expectations
5.2. IETF Network Slice Service Demarcation Points
5.3. IETF Network Slice Composition
6. Framework
6.1. IETF Network Slice Stakeholders
6.2. Expressing Connectivity Intents
6.3. IETF Network Slice Controller (NSC)
6.3.1. IETF Network Slice Controller Interfaces
6.3.2. Management Architecture
7. Realizing IETF Network Slices
7.1. An Architecture to Realize IETF Network Slices
7.2. Procedures to Realize IETF Network Slices
7.3. Applicability of ACTN to IETF Network Slices
7.4. Applicability of Enhanced VPNs to IETF Network Slices
7.5. Network Slicing and Aggregation in IP/MPLS Networks
7.6. Network Slicing and Service Function Chaining (SFC)
8. Isolation in IETF Network Slices
8.1. Isolation as a Service Requirement
8.2. Isolation in IETF Network Slice Realization
9. Management Considerations
10. Security Considerations
11. Privacy Considerations
12. IANA Considerations
13. Informative References
Appendix A. Examples
A.1. Multi-Point to Point Service
A.2. Service Function Chaining and Ancillary CEs
A.3. Hub and Spoke
A.4. Layer 3 VPN
A.5. Hierarchical Composition of Network Slices
A.6. Horizontal Composition of Network Slices
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🦋
okay so lots of use cases want more than plain connectivity. Think VPN-style private connectivity, but with a guarantee that a set of specific network performance objectives will be met 💖. That combo of connectivity and committed resources is what this doc calls a "network slice" 🌸. It's expressed through connectivity constructs (see Section 4) and service objectives (see Section 5) ✨.
"Network slice" is a pretty generic term, and other standards bodies use it with wider or different meanings 🙈. So this doc adds the qualifier "IETF" to limit the scope to network technologies the IETF defines and standardizes 💜. The result is the concept of "IETF Network Slices": connectivity plus specific resource commitments between a number of endpoints (called Service Demarcation Points, or SDPs; see Sections 3.2 and 5.2), running over a shared underlay network that uses IETF technology 🔥. The term "IETF Network Slice Service" describes the service requested by and delivered to the service provider's customer 👑.
Here's the naming rule, bestie: the terms "IETF Network Slice" and "IETF Network Slice Service" are meant to be used only in this document 🧚. Other docs that need to point at this type of slice or service can say "RFC 9543 Network Slice" and "RFC 9543 Network Slice Service" instead 🎀.
This doc also gives a general framework for requesting and operating IETF Network Slices 🌈. The framework is a structure for discussing interfaces and technologies, not a rulebook 🫶.
Services that might benefit from IETF Network Slices include, but are not limited to:
- 5G services (e.g., enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC) -- see [TS23.501]) 📱
- Network wholesale services 🛒
- Network infrastructure sharing among operators 🤝
- Network Function Virtualization (NFV) [NFVArch] connectivity and Data Center Interconnect 🏢
More analysis of what IETF Network Slice Service customers need is in [USE-CASES] 💅.
IETF Network Slices are created and managed within one or more network technologies (e.g., IP, MPLS, and optical) that use an IETF-specified data plane and/or management/control plane ✨. They're meant to let a diverse set of applications with different requirements coexist over one shared underlay network 💜. A request for an IETF Network Slice Service doesn't care which underlay technology is used, so customers can describe their connectivity objectives in a common format, no matter what's underneath 🦋.
Lots of existing service delivery and traffic engineering approaches already use mechanisms that count as network slicing 🌸. For example, Virtual Private Networks (VPNs) have served the industry well by giving different groups of users logically isolated access to a common network 🎀. The shared base network that supports the VPNs is often called an "underlay network", and the VPN itself is often called an "overlay network" 🧚. An overlay network can, in turn, act as an underlay for another overlay network 🌈.
It's conceivable that extensions to IETF technologies are needed to fully support everything network slices can do 🙈. Evaluating existing technologies, proposing extensions to existing protocols and interfaces, and creating new protocols or interfaces are all outside the scope of this document 💀.
That's Part 1 of 12, bestie! 💖 More parts are coming, so stay tuned for Section 2 and beyond 🫶✨
2. Background ✨
okay so the whole idea of network slicing has gotten SO popular, and honestly it's mostly because of 5G 📱 (see [NGMN-NS-Concept], [TS23.501], and [TS28.530]). In [TS23.501], a Network Slice is defined as a "logical network that provides specific network capabilities and network characteristics", and a Network Slice Instance is a "set of Network Function instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice" 🫶. According to [TS28.530], an end-to-end (E2E) network slice has three big types of network segments: Radio Access Network (RAN), Transport Network (TN), and Core Network (CN) 🌈. An IETF Network Slice gives you the connectivity between different entities in the RAN and CN segments of an end-to-end network slice, with a specific performance commitment (for example, acting as a TN slice) 💜. And bestie, for each end-to-end network slice, the topology and performance needs of a customer's use of an IETF Network Slice can be wildly different, so the underlay network needs to be able to support lots of different IETF Network Slices at once 😭.
While everyone talks about network slices in the context of 5G, IETF Network Slices are actually a narrower concept with a much broader usage profile, and they focus mainly on particular network connectivity aspects 🦋. Other systems, 5G deployments included, can use IETF Network Slices as one piece to build entire systems and concatenated constructs that match what they need, including end-to-end connectivity 🧚.
An IETF Network Slice could span multiple technologies and multiple administrative domains 🍓. Depending on what the IETF Network Slice Service customer needs, an IETF Network Slice could be isolated from other IETF Network Slices (often running at the same time) in terms of data, control, and management planes 🔥.
Here's the lowkey important part: the customer says what they need from a particular IETF Network Slice Service, not how that need should get met 💅. So the IETF Network Slice Service customer's view of the service is an abstract one ✨.
So yes, there's a real need to create logical network structures with the characteristics people require 🎀. The customer of such a logical network can ask for a level of isolation and performance that overlay VPNs might not have been able to satisfy before 👑. The IETF Network Slice Service customer might also want some level of control, for example to customize the service paths in a network slice 🌸.
This document defines the terms and a framework for providing an IETF Network Slice Service 💖. Section 7 briefly points out some candidate technologies for realizing IETF Network Slices 🧚♀️.
3. Terms and Abbreviations 🎀
3.1. Abbreviations
Here are the abbreviations used in this document 📝:
NSC: Network Slice ControllerSDP: Service Demarcation PointSLA: Service Level AgreementSLE: Service Level ExpectationSLI: Service Level IndicatorSLO: Service Level Objective
The meanings of these abbreviations get explained in more detail in the rest of this document 🦋.
3.2. Core Terminology
These terms are here to give you context 💜. Other terminology gets defined later on in the document 🌈.
- Customer: The requester of an IETF Network Slice Service 💁♀️. Customers may request monitoring of SLOs. A customer can be an entity like an enterprise network or a network operator, an individual working at one of those, a private individual signing up for a service, or an application or software component 🫶. A customer might be an external party (classically, a paying customer) or a division of a network operator that uses a service provided by another division of that same operator 🍓. People have also used "client" and "consumer" for the customer role 💅.
- Provider: The organization that delivers an IETF Network Slice Service 🔥. The provider is the network operator that controls the network resources used to build the network slice (in other words, the network that's being sliced) 👑. The provider's network might be a physical network, or a virtual network created inside the operator's network or supplied by another service provider 🌸.
- Customer Edge (CE): The customer device that gives connectivity to a service provider 🏠. Examples include routers, Ethernet switches, firewalls, 4G/5G RAN or Core nodes, application accelerators, server load balancers, HTTP header enrichment functions (such as proxy components adding the Forwarded HTTP Extension Header [RFC7239]), and Performance Enhancing Proxies (PEPs) ✨. In some situations, CEs are provided to the customer and managed by the provider 🎀.
- Provider Edge (PE): The device inside the provider network that a CE is attached to 🧚. A CE may be attached to multiple PEs, and multiple CEs may be attached to a given PE 💜.
- Attachment Circuit (AC): A channel connecting a CE and a PE over which packets belonging to an IETF Network Slice Service get exchanged 🦋. An AC is, by definition, technology specific: the AC defines how customer traffic gets presented to the provider network 🌈. The customer and provider agree (for example, through configuration) on which values in which combination of Layer 2 (L2) and Layer 3 (L3) header and payload fields within a packet identify which {IETF Network Slice Service, connectivity construct, and SLOs/SLEs} that packet is assigned to 🫶. The customer and provider may agree to police or shape traffic, based on the specific IETF Network Slice Service (including connectivity construct and SLOs/SLEs), on the AC in both the ingress (CE to PE) direction and the egress (PE to CE) direction 💅. This makes sure the traffic stays within the capacity profile agreed upon in an IETF Network Slice Service 🔒. Excess traffic is dropped by default, unless specific out-of-profile policies have been agreed upon between the customer and the provider 🚫. As described in Section 5.2, the AC may be part of the IETF Network Slice Service or may be external to it ✨. Because SLOs and SLEs characterize the performance of the underlay network between a sending SDP and a set of receiving SDPs, the traffic policers and traffic shapers apply to a specific connectivity construct on an AC 🍓.
- Service Demarcation Point (SDP): The point where an IETF Network Slice Service is delivered by a service provider to a customer 🎀. Depending on the service delivery model (see Section 5.2), this may be a CE or a PE, and it could be a device, a software component, or an abstract virtual function supported within the provider's network 👑. Each SDP must have a unique identifier (e.g., an IP address or Media Access Control (MAC) address) within a given IETF Network Slice Service, and it may use the same identifier in multiple IETF Network Slice Services 💖.
An SDP may be abstracted as a Service Attachment Point (SAP) [RFC9408] so the concept can be generalized across multiple service types and represented in management and configuration systems 🌸.
- Connectivity Construct: A set of SDPs together with a communication type that defines how traffic flows between the SDPs 🌊. An IETF Network Slice Service is specified in terms of a set of SDPs, the associated connectivity constructs, and the service objectives the customer wants to see fulfilled 🎯. Connectivity constructs may be grouped together for administrative purposes 🗂️.
4. IETF Network Slice 🦋
IETF Network Slices are created to meet specific requirements, typically expressed as bandwidth, latency, latency variation, and other desired or required characteristics 💜. Creating an IETF Network Slice gets kicked off by a management system or other application that specifies network-related conditions for particular traffic flows, in response to an actual or logical IETF Network Slice Service request 🔥.
Once they exist, these slices can be monitored, modified, deleted, and otherwise managed 🧚.
Applications and components will be able to use these IETF Network Slices to move packets between the specified endpoints of the service, following the specified characteristics 🌈.
A clear distinction should be made between the "IETF Network Slice Service" and the IETF Network Slice 👀:
- IETF Network Slice Service: The function delivered to the customer (see Section 4.2) 💁♀️. It doesn't care which technologies and mechanisms the service provider uses 🫶.
- IETF Network Slice: The realization of the service in the provider's network, achieved by partitioning network resources and by applying certain tools and techniques within the network (see Sections 4.1 and 7) 🎀.
4.1. Definition and Scope of IETF Network Slice
The term "Slice" refers to a set of characteristics and behaviors that tell one type of user traffic apart from another within a network 🍰. An IETF Network Slice is a logical partition of a network that uses IETF technology 💖. An IETF Network Slice assumes that an underlay network can change the configurations of its network devices on demand, through in-band signaling, or via controllers 🌸.
An IETF Network Slice enables connectivity between a set of SDPs with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) (see Section 5) over a common underlay network 🛤️. The SLOs and SLEs characterize the performance of the underlay network between a sending SDP and a set of receiving SDPs 📊. So an IETF Network Slice delivers a service to a customer by meeting connectivity resource requirements and associated network capabilities, such as bandwidth, latency, jitter, and network functions, along with other resource behaviors such as compute and storage availability 🦄.
IETF Network Slices may be combined hierarchically, so a network slice may itself be sliced 🪆. They may also be combined sequentially, so various different networks can each be sliced and the network slices placed into a sequence to provide an end-to-end service 🔗. This sequential form of combination is used in some services, such as in 3GPP's 5G network [TS23.501] 📱.
The term "IETF Network Slice" is meant to be used only in this document 🙈. Other documents that need to indicate the type of network slice described here can use the term "RFC 9543 Network Slice" 💅✨
4.2. IETF Network Slice Service 💖
okay bestie, so a service provider delivers an IETF Network Slice Service to a customer by realizing an IETF Network Slice in the underlay network 🦋 The service doesn't care what technology the underlay uses! The provider can pick the realization based on lots of things, including the service requirements and what the underlay can actually do ✨ This means the customer can describe their connectivity and goals in one common format, no matter which underlay tech is running underneath 💅
The service is specified using a set of SDPs, a set of one or more connectivity constructs between subsets of those SDPs, and a set of SLOs and SLEs (see Section 5) for each SDP sending to each connectivity construct 🎀 Every connectivity construct also gets a communication type: Point-to-Point (P2P), Point-to-Multipoint (P2MP), or Any-to-Any (A2A) 🌈 So in a given IETF Network Slice Service:
- there may be one or more connectivity constructs, of the same or different types 🌸
- each connectivity construct may be between a different subset of SDPs 💜
- each sending SDP has its own set of SLOs and SLEs for a given connectivity construct, and the SLOs and SLEs in each set may be different ✨
ngl, different connectivity constructs can be requested in the service request, but the service provider gets to decide how many connectivity constructs per IETF Network Slice Service they want to support 👑 So one service might be limited to one connectivity construct, or it might support many 🧚
An IETF Network Slice Service customer can provide IETF Network Slice Services to other customers too, in a mode sometimes called "carrier's carrier" (see Section 9 of [RFC4364]) 💅 In this case, the relationship between the IETF Network Slice Service providers may be internal to one commercial organization, or external through service provision contracts 🤝 As noted in Section 5.3, network slices may be composed hierarchically or serially 🌀
Section 5.2 describes SDPs as endpoints in the context of IETF network slicing 🦋 For a given IETF Network Slice Service, the customer and provider agree, on a per-SDP basis, which end of the attachment circuit provides the SDP (in other words, whether the attachment circuit is inside or outside the IETF Network Slice Service) 🎀 This decides whether the attachment circuit is subject to the set of SLOs and SLEs at that specific SDP 💖
It is intended that the term "IETF Network Slice Service" be used only in this document 📝 Other documents that need to indicate the type of network slice service described here can use the term "RFC 9543 Network Slice Service" 🌈
4.2.1. Connectivity Constructs 🦋
specifying a Network Slice Service as a set of SDPs with connectivity constructs gives us the following possible connectivity constructs 💅
- For a P2P connectivity construct, there is one sending SDP and one receiving SDP. This construct is like a private wire or a tunnel 🧚 All traffic injected at the sending SDP is intended to be received by the receiving SDP. The SLOs and SLEs apply at the sender (and implicitly, at the receiver) ✨
- For a P2MP connectivity construct, there is only one sending SDP and more than one receiving SDP. This is like a P2MP tunnel or multi-access VLAN segment 🌸 All traffic from the sending SDP is intended to be received by all the receiving SDPs. There is one set of SLOs and SLEs that applies at the sending SDP (and implicitly, at all receiving SDPs) 💜
- With an A2A connectivity construct, any sending SDP may send to any one receiving SDP or any set of receiving SDPs in the construct 🌈 There is an implicit level of routing here that isn't present in the other connectivity constructs, because the provider's network must work out which receiving SDPs to deliver each packet to 🗺️ This construct may be used to support P2P traffic between any pair of SDPs, or to support multicast or broadcast traffic from one SDP to a set of other SDPs 📡 In the latter case, whether the service is delivered using multicast within the provider's network or using "ingress replication" or some other means is out of scope of the specification of the service 🙈 A service provider may choose to support A2A constructs but limit the traffic to unicast 🎀
- The SLOs/SLEs in an A2A connectivity construct apply to individual sending SDPs regardless of the receiving SDPs, and there is no linkage between sender and receiver in the specification of the connectivity construct 💀 A sending SDP may be "disappointed" if the receiver is over-subscribed 😭 If a customer wants to be more specific about different behaviors from one SDP to another SDP, they should use P2P connectivity constructs 🫶
A given sending SDP may be part of multiple connectivity constructs within a single IETF Network Slice Service, and the SDP may have different SLOs and SLEs for each connectivity construct it is sending into 🦋 Note that a given sending SDP's SLOs and SLEs for a given connectivity construct apply between it and each of the receiving SDPs for that connectivity construct 🔥
An IETF Network Slice Service provider may freely decide whether to offer a 1:1 relationship between an IETF Network Slice Service and connectivity construct, or to support multiple connectivity constructs in a single IETF Network Slice Service 💖 In the former case, the provider might need to deliver multiple IETF Network Slice Services to achieve the function of the second case 🌈
4.2.2. Mapping Traffic Flows to Network Realizations 🗺️
A customer traffic flow may be unicast or multicast, and various network realizations are possible 💅
- Unicast traffic may be mapped to a P2P connectivity construct for direct delivery, or to an A2A connectivity construct so the service provider performs routing to the destination SDP 🦋 It would be unusual to use a P2MP connectivity construct to deliver unicast traffic, because all receiving SDPs would get a copy 🙈 but this can still be done if the receivers are capable of dropping the unwanted traffic 🫶
- A bidirectional unicast service can be constructed by specifying two P2P connectivity constructs 🎀 An additional SLE may specify fate-sharing in this case 🔗
- Multicast traffic may be mapped to a set of P2P connectivity constructs, a single P2MP connectivity construct, or a mixture of P2P and P2MP connectivity constructs 🌸 Multicast may also be supported by an A2A connectivity construct 🌈 The choice clearly influences how and where traffic is replicated in the network 🧚 With a P2MP or A2A connectivity construct, it is the operator's choice whether to realize the construct with ingress replication, multicast in the core, P2MP tunnels, or hub-and-spoke 👑 This choice should not change how the customer perceives the service ✨
- The concept of a Multipoint-to-Point (MP2P) service can be realized with multiple P2P connectivity constructs 📥 Note that, in this case, the egress may simultaneously receive traffic from all ingresses 😬 The SLOs at the sending SDPs must be set with this in mind, because the provider's network is not capable of coordinating the policing of traffic across multiple distinct source SDPs 🚦 It is assumed that the customer, when requesting SLOs for the various P2P connectivity constructs, is aware of the capabilities of the receiving SDP 🧠 If the receiver gets more traffic than it can handle, it may drop some and introduce queuing delays 🥴
- The concept of a Multipoint-to-Multipoint (MP2MP) service can best be realized using a set of P2MP connectivity constructs, but could be delivered over an A2A connectivity construct if each sender is using multicast 🔁 As with MP2P, the customer is assumed to be familiar with the capabilities of all receivers 👀 A customer may wish to achieve an MP2MP service using a hub-and-spoke architecture where they control the hub 👑 That is, the hub may be an SDP or an ancillary CE (see Section 4.2.3), and the service may be achieved by using a set of P2P connectivity constructs to the hub and a single P2MP connectivity construct from the hub 🕸️
From the above, it can be seen that the SLOs of the senders define the SLOs for the receivers on any connectivity construct 💅 In particular, the network may be expected to handle the traffic volume from a sender to all destinations 🌊 This extends to all connectivity constructs in an IETF Network Slice Service 🫶
Note that the realization of an IETF Network Slice Service does not need to map connectivity constructs one-to-one onto underlying network constructs (such as tunnels) 🧩 The service provided to the customer is distinct from how the provider decides to deliver that service 💖
If a CE has multiple attachment circuits to PEs within a given IETF Network Slice Service, and they are operating in single-active mode, then all traffic between the CE and its attached PEs transits a single attachment circuit 🚪 If they are operating in all-active mode, then traffic between the CE and its attached PEs is distributed across all of the active attachment circuits 🌈
4.2.3. Ancillary CEs 🧚
It may be the case that the set of SDPs that delimits an IETF Network Slice Service needs to be supplemented with additional senders or receivers within the network that are not customer sites 🌟 An additional sender could be, for example, an IPTV or DNS server either within the provider's network or attached to it 📺 while an extra receiver could be, for example, a node reachable via the Internet 🌍 This is modeled in the Network Slicing architecture as a set of ancillary CEs that supplement the other SDPs in one or more connectivity constructs, or that are linked by their own connectivity constructs 🦋 Note that an ancillary CE can either have a resolvable address (e.g., an IP address or MAC address), or it may be a placeholder (e.g., a named IPTV or DNS service or server) that is resolved within the provider's network when the IETF Network Slice Service is instantiated 🎀
So an ancillary CE may be a node within the provider network (i.e., not a node at the edge of the customer's network) 🏢 An example is a node that provides a service function 🛠️ Another example is a node that acts as a hub 🕸️ There will be times when the customer wishes to explicitly select one of these 👑 Alternatively, an ancillary CE may be a service function at an unknown point in the provider's network 🌫️ In this case, the function may be a placeholder that has its addresses resolved as part of the realization of the slice service 🧩
Appendices A.2 and A.3 give simple worked examples of the use of ancillary CEs, which may help with understanding the concept 📚✨
5. IETF Network Slice System Characteristics 🌈
The following subsections describe the characteristics of IETF Network Slices, in addition to the list of SDPs, the connectivity constructs, and the technology of the ACs 💜
5.1. Objectives for IETF Network Slices
okay so an IETF Network Slice Service is described with two kinds of characteristics 💅 The first kind is quantifiable and called Service Level Objectives (SLOs). The second kind is unquantifiable and called Service Level Expectations (SLEs) 🎀 SLOs are expressed in terms of Service Level Indicators (SLIs), and together with the SLEs they form the contract between the service customer and the service provider, known as a Service Level Agreement (SLA) 📜
The terms are defined like this:
- Service Level Indicator (SLI): A quantifiable measure of an aspect of the performance of a network. For example, it may be a measure of throughput in bits per second, or it may be a measure of latency in milliseconds. 📊
- Service Level Objective (SLO): A target value or range for the measurements returned by observation of an SLI. For example, an SLO may be expressed as
SLI <= targetorlower bound <= SLI <= upper bound. A customer can determine whether the provider is meeting the SLOs by performing measurements on the traffic. 🎯 - Service Level Expectation (SLE): An expression of an unmeasurable service-related request that a customer of an IETF Network Slice Service makes of the provider. An SLE is distinct from an SLO because the customer may have little or no way of determining whether the SLE is being met, but they still contract with the provider for a service that meets the expectation. 🥹
- Service Level Agreement (SLA): An explicit or implicit contract between the customer of an IETF Network Slice Service and the provider of the slice. The SLA is expressed in terms of a set of SLOs and SLEs that are to be applied for a given connectivity construct between a sending SDP and the set of receiving SDPs. The SLA may describe the extent to which divergence from individual SLOs and SLEs can be tolerated, and commercial terms as well as any consequences for violating these SLOs and SLEs. 💼
5.1.1. Service Level Objectives
SLOs are all about a set of measurable network attributes and characteristics that describe an IETF Network Slice Service ✨ They do not describe how the service is implemented or realized in the underlying network layers. Instead, they are defined in terms of dimensions of operation (time, capacity, etc.), availability, and other attributes.
An IETF Network Slice Service may include multiple connectivity constructs that associate sets of endpoints (SDPs). SLOs apply to a given connectivity construct, and they apply to a specific direction of traffic flow. That means they apply to a specific sending SDP and the set of receiving SDPs. 🦋
5.1.1.1. Some Common SLOs
SLOs can be described as "Directly Measurable Objectives," which means they are always measurable 📏 Section 5.1.2 covers Service Level Expectations, which are unmeasurable service-related requests sometimes known as "Indirectly Measurable Objectives."
Objectives such as guaranteed minimum bandwidth, guaranteed maximum latency, maximum permissible delay variation, maximum permissible packet loss ratio, and availability are all "Directly Measurable Objectives" 🌈 Future specifications (such as IETF Network Slice Service YANG models) may precisely define these SLOs, and other SLOs may be introduced as described in Section 5.1.1.2.
Here's what each of these objectives means:
- Guaranteed Minimum Bandwidth: Minimum guaranteed bandwidth between two endpoints at any time. The bandwidth is measured in data rate units of bits per second and is measured unidirectionally. 🚀
- Guaranteed Maximum Latency: Upper bound of network latency when transmitting between two endpoints. The latency is measured in terms of network characteristics (excluding application-level latency). [RFC7679] discusses one-way metrics. ⏱️
- Maximum Permissible Delay Variation: Packet Delay Variation (PDV) as defined by [RFC3393] is the difference in the one-way delay between sequential packets in a flow. This SLO sets a maximum value PDV for packets between two endpoints. 🌊
- Maximum Permissible Packet Loss Ratio: The ratio of packets dropped to packets transmitted between two endpoints over a period of time. See [RFC7680]. 📉
- Availability: The ratio of uptime to the sum of uptime and downtime, where uptime is the time the connectivity construct is available in accordance with all of the SLOs associated with it. Availability will often be expressed along with the time period over which the availability is measured and the maximum allowed single period of downtime. 🟢
5.1.1.2. Other Service Level Objectives
Additional SLOs may be defined to give more detail about the IETF Network Slice Service that a customer requests 🧩 These would be specified in further documents.
If the IETF Network Slice Service is traffic-aware, other traffic-specific characteristics may be valuable, including MTU, traffic type (e.g., IPv4, IPv6, Ethernet, or unstructured), or a higher-level behavior to process traffic according to user application (which may be realized using network functions). 🎀
5.1.2. Service Level Expectations
SLEs define a set of network attributes and characteristics that describe an IETF Network Slice Service but are not directly measurable by the customer (e.g., diversity, isolation, and geographical restrictions) 🙈 Even though the customer usually can't determine whether an SLE is being delivered, SLEs are a really important part of the contract between customer and provider.
Quite often, an SLE will imply some details of how an IETF Network Slice Service is realized by the provider. Most aspects of the implementation in the underlying network layers still remain a free choice for the provider 🛠️ For example, activating unicast or multicast capabilities to deliver an IETF Network Slice Service could be explicitly requested by a customer, or it could be left as an engineering decision for the service provider based on the capabilities of the network and operational choices.
SLEs may be seen as aspirational on the part of the customer, and they are expressed as behaviors that the provider is expected to apply to the network resources used to deliver the IETF Network Slice Service ✨ Of course, over time, it is possible that mechanisms will be developed that enable a customer to verify the provision of an SLE, at which point it effectively becomes an SLO.
An IETF Network Slice Service may include multiple connectivity constructs that associate sets of endpoints (SDPs). SLEs apply to a given connectivity construct and apply to specific directions of traffic flow. That means they apply to a specific sending SDP and the set of receiving SDPs. Because they are more general in nature than SLOs, SLEs may commonly be applied to all connectivity constructs in an IETF Network Slice Service 💜
5.1.2.1. Some Common SLEs
SLEs can be described as "Indirectly Measurable Objectives," which means they are not generally directly measurable by the customer 🌸
Security, geographic restrictions, maximum occupancy level, and isolation are example SLEs, as follows:
- Security: A customer may request that the provider applies encryption or other security techniques to traffic flowing between SDPs of a connectivity construct within an IETF Network Slice Service. For example, the customer could request that only network links that have Media Access Control Security (MACsec) [MACsec] enabled are used to realize the connectivity construct.
This SLE may include a request for encryption (e.g., [RFC4303]) between the two SDPs explicitly to meet the architectural recommendations in [TS33.210] or for compliance with the HIPAA Security Rule [HIPAA] or the PCI Data Security Standard [PCI].
Whether or not the provider has met this SLE is generally not directly observable by the customer, and it cannot be measured as a quantifiable metric.
Please see further discussion on security in Section 10. 🔐
- Geographic Restrictions: A customer may request that certain geographic limits are applied to how the provider routes traffic for the IETF Network Slice Service. For example, the customer may have a preference that its traffic does not pass through a particular country for political or security reasons. 🗺️
Whether or not the provider has met this SLE is generally not directly observable by the customer, and it cannot be measured as a quantifiable metric.
- Maximal Occupancy Level: The maximal occupancy level specifies the number of flows to be admitted and optionally a maximum number of countable resource units (e.g., IP or MAC addresses) an IETF Network Slice Service can consume. Because an IETF Network Slice Service may include multiple connectivity constructs, this SLE should state whether it applies to all connectivity constructs, a specified subset of them, or an individual connectivity construct. 🚦
Again, a customer may not be able to fully determine whether this SLE is being met by the provider.
- Isolation: As described in Section 8, a customer may request that its traffic within its IETF Network Slice Service is isolated from the effects of other network services supported by the same provider. That is, if another service exceeds capacity or has a burst of traffic, the customer's IETF Network Slice Service should remain unaffected, and there should be no noticeable change to the quality of traffic delivered. 🛡️
In general, a customer cannot tell whether a service provider is meeting this SLE. They cannot tell whether the variation of an SLI is because of changes in the underlay network or because of interference from other services carried by the network. If the service varies within the allowed bounds of the SLOs, there may be no noticeable indication that this SLE has been violated. 🫣
- Diversity: A customer may request that different connectivity constructs use different underlay network resources. This might be done to enhance the availability of the connectivity constructs within an IETF Network Slice Service.
While availability is a measurable objective (see Section 5.1.1.1), this SLE requests a finer grade of control and is not directly measurable (although the customer might become suspicious if two connectivity constructs fail at the same time). 🦄
5.2. IETF Network Slice Service Demarcation Points 🎀
Okay so, bestie, remember from Section 4.1 that an IETF Network Slice gives you connectivity between sets of SDPs, each with its own SLOs and SLEs 💖. Section 4.2 then explains that the IETF Network Slice Service is built from one or more connectivity constructs, which describe how those Service Demarcation Points (SDPs) connect across the underlay network ✨.
The characteristics of IETF Network Slice SDPs are giving main character energy 👑:
- An SDP is the point of attachment to an IETF Network Slice Service. So SDPs are the IETF Network Slice ingress/egress points 🚪
- Each SDP has a unique identifier within the context of an IETF Network Slice Service customer 🫶
- The provider links each SDP to a set of provider-scope identifiers, like IP addresses, encapsulation-specific identifiers (e.g., VLAN tag and MPLS Label), interface/port numbers, node ID, and so on 🧚
- SDPs get mapped to endpoints of services, tunnels, and paths within the IETF Network Slice while it's being initialized and realized 🌈
- A combo of the SDP identifier and the SDP provider-network-scope identifiers defines an SDP in the context of the Network Slice Controller (NSC) (see Section 6.3) 💅
- The NSC uses the SDP provider-network-scope identifiers as part of realizing the IETF Network Slice 🔥
Quick aside: an ancillary CE (see Section 4.2.3) is the endpoint of a connectivity construct, so it counts as an SDP here too 💜
For a given IETF Network Slice Service, the customer and provider agree on where the SDP lives. That decides which edge resources end up as part of the IETF Network Slice and fall under the set of SLOs and SLEs for that specific SDP 🍓
Figure 1 shows the different scopes an IETF Network Slice can have, depending on where the SDPs sit. To keep things simple (and without loss of generality, as the RFC says), the figure shows Customer Edge (CE) and Provider Edge (PE) nodes linked by Attachment Circuits (ACs). The notes after the figure explain each option 🦋
|<---------------------- (1) ---------------------->|
| |
| |<-------------------- (2) -------------------->| |
| | | |
| | |<----------- (3) ----------->| | |
| | | | | |
| | | |<-------- (4) -------->| | | |
| | | | | | | |
V V AC V V V V AC V V
+-----+ | +-----+ +-----+ | +-----+
| |--------| | | |--------| |
| CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 |
| |--------| | | |--------| |
+-----+ | +-----+ +-----+ | +-----+
^ ^ ^ ^
| | | |
| | | |
Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2
Figure 1: Positioning IETF Service Demarcation PointsHere's what the numbers in the figure mean 🤓
- If the CE is run by the IETF Network Slice Service provider, the edge of the IETF Network Slice can reach inside the CE. The slicing process can then use resources inside the CE, like buffers and queues on the outgoing interfaces 📦
- The IETF Network Slice can stretch as far as the CE to include the AC, but not any part of the CE itself. Here the CE might belong to the customer or the provider. Slicing the AC resources might need traffic tagging (such as Ethernet VLAN tags) or traffic policing at the AC link ends 🏷️
- The SDPs are the customer-facing ports on the PEs. This works a lot like a port-based VPN: each port (AC) or virtual port (e.g., VLAN tag) identifies the IETF Network Slice and maps to an IETF Network Slice SDP 🎯
- Last one: the SDP can live inside the PE. The PE sorts the traffic coming in from the AC by things like source and destination IP addresses, payload protocol, and port numbers, and then places it onto an IETF Network Slice 🧁
Which of these you pick is totally up to the network operator 🫠. It can limit or unlock certain managed services, and the operator will want to think about how they manage CEs and how much control they give the customer over AC resources 💼
Figure 1 shows a symmetrical placement of SDPs, but this can be decided per SDP through agreement between the customer and provider 🌸
Sometimes you need to map traffic not just onto an IETF Network Slice, but onto a specific connectivity construct too. That happens when the IETF Network Slice supports more than one construct sourced at the same SDP 🔀 The mechanism used is one of the ones described above, depending on how the SDP is realized 💅
And finally (see Section 3.2 for the background), an SDP is an abstract endpoint of an IETF Network Slice Service. It could be a device, an interface, or a software component 🧚♀️ An ancillary CE (Section 4.2.3) should be thought of as an SDP too 💖
5.3. IETF Network Slice Composition 🧩
Operationally, one IETF Network Slice can be composed of two or more IETF Network Slices, as described below. Decomposed network slices are realized and managed independently 🫶
- Hierarchical (i.e., recursive) composition: An IETF Network Slice can be sliced again into other network slices. Recursive composition lets an IETF Network Slice at one layer get used by other layers. This multi-layer vertical IETF Network Slice links resources across different layers 🪜
- Sequential composition: Different IETF Network Slices can be lined up in a sequence to deliver an end-to-end service. With sequential composition, each IETF Network Slice could support a different data plane, and those need to be stitched together 🧵
6. Framework 🌈
A bunch of IETF Network Slice Services will usually run over a shared underlay network infrastructure. Each IETF Network Slice has both the overlay connectivity and a dedicated set of network resources and/or functions allocated in that shared underlay, all to meet the needs of the IETF Network Slice Service customer 💜 In at least some underlay network technologies, the overlay and the various underlay resources have to integrate to make sure the guaranteed performance requested for each IETF Network Slice actually happens ✨
This section lays out the main stakeholders in an IETF Network Slice and explains how the IETF Network Slice Service customer requests connectivity 📝 It then introduces the IETF Network Slice Controller (the functional component that receives customer requests and converts them into network configuration commands) and describes its interfaces 🔌
6.1. IETF Network Slice Stakeholders 🎭
An IETF Network Slice and its realization involve the following stakeholders 👀
- Orchestrator: An orchestrator is an entity that composes different services, resources, and network requirements. It talks to the IETF NSC when composing a complex service, like an end-to-end network slice 🎼
- IETF Network Slice Controller (NSC): The NSC realizes an IETF Network Slice in the underlay network, and it keeps track of and monitors the run-time state of the resources and topologies tied to it 🕹️ A well-defined interface is needed so different NSC implementations and different orchestrator implementations can interwork 🤝
- Network Controller: The Network Controller is a kind of network infrastructure controller that offers network resources to the NSC so it can realize a particular network slice 🏗️ It might be an existing network controller tied to one or more specific technologies, adapted to the job of realizing IETF Network Slices in a network 🔧
The IETF Network Slice Service customer and IETF Network Slice Service provider (see Section 3.2) are stakeholders too 💁♀️ Obviously, the service provider runs the network that gets sliced to deliver the IETF Network Slice Service to the customer 🏢 The Network Controller and NSC are management components the service provider uses to operate their networks and deliver IETF Network Slice Services 🛠️ As Figures 2 and 3 show, the Orchestrator might be a component in the customer environment that requests and coordinates IETF Network Slice Services from one or more service providers 🤝 But other times, the Orchestrator is a component the service provider uses to request and manage IETF Network Slices, delivering them to customers or building infrastructure for other services the customer gets 🚀
6.2. Expressing Connectivity Intents ✨
okay so an IETF Network Slice Service customer talks to the NSC through the IETF Network Slice Service Interface 💌
and a customer can be a network operator who then uses the IETF Network Slice to provide a service for another IETF Network Slice Service customer 🔁 (customers all the way down, bestie 💅)
using that interface, the customer expresses requirements for a slice by saying what they need, not how to get it 🦋 so their view of a slice is totally abstract 🌸. customers usually have limited (or no) peeking rights into the provider network's actual topology and resource availability 🙈
this should be true even if the customer and the provider are in the same administrative domain 💖. the reason is to lower the chance of messy interactions between slice customers and the other users of the underlay network infrastructure 🫶
the benefits of this model can include the following 👑
- Security 🔐: the underlay network components are less exposed to attack because the underlay network (or network operator) doesn't have to expose network details (topology, capacity, etc.) to the IETF Network Slice Service customers 🛡️
- Layered Implementation 🧁: the underlay network is made of network elements that belong to a different layer network than customer applications. network information (advertisements, protocols, etc.) that a customer can't interpret or respond to isn't exposed to the customer 🙅♀️ (note that a customer should not rely on network information not exposed directly to the customer by the network operator, such as via the IETF Network Slice Service Interface ⚠️)
- Scalability 📈: customers don't need to know any information about network topology, capabilities, or state beyond what's exposed via the IETF Network Slice Service Interface 🧠. this keeps the customer site from having to hold and process extra info, and from getting frequent updates about the status of the network 😌
the general issues of abstraction in a Traffic Engineered (TE) network are described more fully in [RFC7926] 📚
this framework document doesn't assume any particular technology layer where IETF Network Slices operate 🌈. a bunch of layers (including virtual L2, Ethernet, or IP connectivity) could be employed ✨
data models and interfaces are needed to set up IETF Network Slices, and specific interfaces may have capabilities that allow creating slices within specific technology layers 🎀
layered virtual connections are comprehensively discussed in other IETF documents 💜. for instance, GMPLS-based networks are discussed in [RFC5212] and [RFC4397], and Abstraction and Control of TE Networks (ACTN) is discussed in [RFC8453] and [RFC8454] 🧚. the principles and mechanisms of layered networking apply to IETF Network Slices too 💅
there are several IETF-defined mechanisms for expressing the need for a desired logical network 🔥. the IETF Network Slice Service Interface carries data either in a protocol-defined format or in a formalism tied to a modeling language 📝
for instance:
- The Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440] and GMPLS User-Network Interface (UNI) using RSVP-TE [RFC4208] use a TLV-based binary encoding to transmit data 🔢
- The Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF Protocol [RFC8040] use XML and JSON encoding 🍓
- gRPC and gRPC Network Management Interface (gNMI) [GNMI] use a binary encoded programmable interface. ProtoBufs can be used to model gRPC and gNMI data 🧩
- For data modeling, YANG [RFC6020] [RFC7950] may be used to model configuration and other data for NETCONF, RESTCONF, and gNMI, among others 🌷
while several generic formats and data models for specific purposes exist, it's expected that IETF Network Slice management may require enhancement or augmentation of existing data models 🛠️. it's also possible that mechanisms will be needed to figure out whether service requests are feasible before they're actually made 🔮 ngl that's a whole vibe 😭
6.3. IETF Network Slice Controller (NSC) 👑
an IETF NSC takes requests for IETF Network Slice Services and implements them using a suitable underlay technology 🛠️. it's the key component for controlling and managing the IETF Network Slice 🧠. it handles the creation/modification/deletion, monitoring, and optimization of IETF Network Slices in a multi-domain, multi-technology, and multi-vendor environment 🌍
the main job of an IETF NSC is to map abstract IETF Network Slice Service requirements to concrete technologies and set up the required connectivity 🔌, making sure resources get allocated to the IETF Network Slice as necessary 💖
the IETF Network Slice Service Interface is used to communicate details of an IETF Network Slice Service (configuration, selected policies, operational state, etc.) plus info about the status and performance of the IETF Network Slice 📬. the details of this interface are not in scope for this document, but further considerations of the requirements are discussed in [USE-CASES] 📖
the controller provides the following functions 🎀
- Exposes an IETF Network Slice Service Interface for creation/modification/deletion of IETF Network Slices that are agnostic to the technology of the underlay network 🦋. this API communicates the Service Demarcation Points of the IETF Network Slice, SLO parameters (and possibly monitoring thresholds), applicable input selection (filtering), and various policies 📋. if SLEs have been agreed between the customer and the network operator, and they're supported for the IETF Network Slice Service, the API will also let SLEs be selected for the IETF Network Slice and let any associated parameters be set ✅. the API also provides a way to monitor the slice 👀
- Determines an abstract topology connecting the SDPs of the IETF Network Slice that meets criteria specified via the IETF Network Slice Service Interface 🗺️. the NSC also keeps track of how this abstract topology maps to underlay components of the IETF Network Slice, as necessary to monitor IETF Network Slice status and performance 🔍
- Supports "Mapping Functions" for the realization of IETF Network Slices 🧩. in other words, it uses the mapping functions that:
- Map IETF Network Slice Service Interface requests that are agnostic to the technology of the underlay network to technology-specific network configuration interfaces 🔁
- Map filtering/selection information to entities in the underlay network so those entities can tell which traffic goes with which connectivity construct and IETF Network Slice 🏷️
- Depending on the realization solution, map to entities in the underlay network according to how traffic should be treated to meet the SLOs and SLEs of the connectivity construct 🚦
- Collects telemetry data (e.g., Operations, Administration, and Maintenance (OAM) results, statistics, states, etc.) via a network configuration interface for all elements in the abstract topology used to realize the IETF Network Slice 📊
- Evaluates the current performance against IETF Network Slice SLO parameters using telemetry data from the underlying realization of an IETF Network Slice (e.g., services, paths, and tunnels) ⏱️. this performance is exposed to the IETF Network Slice Service customer via the IETF Network Slice Service Interface 💌. the IETF Network Slice Service Interface may also include the capability to send notifications if the IETF Network Slice performance reaches threshold values defined by the IETF Network Slice Service customer 🔔
6.3.1. IETF Network Slice Controller Interfaces 🔗
the interworking and interoperability among the different stakeholders, so they can share common means of provisioning, operating, and monitoring IETF Network Slices, is enabled by the following communication interfaces (see Figure 2) 🤝
IETF Network Slice Service Interface: an interface between a customer's higher-level operation system (e.g., a network slice orchestrator or a customer network management system) and an NSC 💻. it's agnostic to the technology of the underlay network 🫧. the customer uses this interface to communicate the requested characteristics and other requirements for the IETF Network Slice Service, and an NSC uses it to report the operational state of an IETF Network Slice Service to the customer 📣. more discussion of the functionalities for this interface can be found in [USE-CASES] 📚
Network Configuration Interface: an interface between an NSC and network controllers 🎛️. it's technology specific and may be built around the many network models already defined within the IETF 🧱
these interfaces can be considered in the context of the Service Model and Network Service Model described in [RFC8309] 🪞. together with the Device Configuration Interface used by the Network Controllers, they provide a consistent view of service delivery and realization 🌟
+------------------------------------------+
| Customer higher-level operation system |
| (e.g., E2E network slice orchestrator, |
| customer network management system) |
+------------------------------------------+
A
| IETF Network Slice Service Interface
V
+------------------------------------------+
| IETF Network Slice Controller (NSC) |
+------------------------------------------+
A
| Network Configuration Interface
V
+------------------------------------------+
| Network Controllers |
+------------------------------------------+
Figure 2: Interfaces of the IETF Network Slice Controllerthe diagram above is the whole picture, bestie 🌈✨
6.3.1.1. IETF Network Slice Service Interface 💫
the IETF Network Slice Controller provides an IETF Network Slice Service Interface that lets customers manage IETF Network Slice Services 💅. customers work with abstract IETF Network Slice Services, and the details of how they're realized stay hidden 🙈
the IETF Network Slice Service Interface is also independent of the type of network functions or services that need to be connected 🧚. that means it doesn't depend on any specific storage, software, protocol, or platform used to realize physical or virtual network connectivity or functions in support of IETF Network Slices 🫶
the IETF Network Slice Service Interface uses protocol mechanisms, plus the information passed over those mechanisms, to convey desired attributes for IETF Network Slices and their status 📨. the information is expected to be represented as a well-defined data model and should include at least SDP and connectivity information, SLO/SLE specification, and status information 🍒 ok that's the end of this part, more is coming bestie 💜
6.3.2. Management Architecture 🦋
okay so the management setup from Figure 2 can be broken down even further, like Figure 3 shows 💅 and you should totally read it next to the component architecture in Figure 4 too. it also matches what [RFC8309] describes ✨
Note that the customer higher-level operation system of Figure 2 and the Network Slice Orchestrator of Figure 3 can be treated as the same thing as the Service Management & Orchestration (SMO) of [ORAN] 🫶
--------------
| Network |
| Slice |
| Orchestrator |
--------------
| IETF Network Slice
| Service Request
| Customer view
....|................................
-v------------------- Operator view
|Controller |
| ------------ |
| | IETF | |
| | Network | |--> Virtual Network
| | Slice | |
| | Controller | |
| | (NSC) | |
| ------------ |
..| | Network |............
| | Configuration | Underlay Network
| v |
| ------------ |
| | Network | |
| | Controller | |
| | (NC) | |
| ------------ |
---------------------
| Device Configuration
vFigure 3: Interface of IETF Network Slice Management Architecture 🎀
7. Realizing IETF Network Slices ✨
okay this part is about how an IETF Network Slice actually gets realized 🔥 basically it's mapping the slice's definition onto the underlying infrastructure. that mapping is always technology specific and an NSC makes it happen over the Network Configuration Interface. how realizations get achieved is out of scope for this document (no cap, it's a whole other conversation 💀), but this section gives you an overview of the parts and processes involved in realizing an IETF Network Slice 💜
7.1. An Architecture to Realize IETF Network Slices 🌸
the architecture in this section is deliberately high level 🧚 it's not meant to be prescriptive, so implementations and technical solutions can vary freely. still, this approach gives everyone a common framework that other documents can reference, so we all end up on the same page 🫶
Figure 4 shows the architectural components of a network that's managed to provide IETF Network Slices. the customer sees individual IETF Network Slice Services with their SDPs and connectivity constructs, and requests for those services get delivered to an NSC 💖
Figure 4 shows, without loss of generality, the CEs, ACs, and PEs that exist in the network. the SDPs aren't drawn in, and they can be placed in any of the ways described in Section 5.2 ✨
-- -- --
|CE| |CE| |CE|
-- -- --
AC : AC : AC :
---------------------- -------
( |PE|....|PE|....|PE| ) ( IETF )
IETF Network ( --: -- :-- ) ( Network )
Slice Service ( :............: ) ( Slice )
Request ( IETF Network Slice ) ( ) Customer
v ---------------------- ------- View
v ............................\........./...............
v \ / Provider
v >>>>>>>>>>>>>>> Grouping/Mapping v v View
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 ----------------------------------------------Figure 4: Architecture of an IETF Network Slice 🌈
the network itself (down at the bottom of Figure 4) is an underlay network 🍓 it could be a physical network, or it could be a virtual one. the underlay gets provisioned through network controllers [RFC8309], and those controllers may themselves use device controllers 💜
the underlay network may optionally be filtered or customized by the network operator to produce a bunch of network topologies that we call "Filtered Topologies" ✨ customization is just a way of picking specific resources (like nodes and links) from the underlay based on their capabilities and how they're connected in the underlay. filtering and customization are configuration options or operator policies that preselect links and nodes with certain performance characteristics. that makes it way easier to build Network Resource Partitions (NRPs; see below) that can reliably support specific IETF Network Slice SLAs. examples include preselecting links with certain security characteristics, preselecting links with specific geographic properties, or mapping onto colored topologies 🎀 the resulting topologies can be used as candidates to host IETF Network Slices, and they give the operator a handy way to know in advance that all the resources they're planning with can meet specific SLOs and SLEs 🫶 creating a Filtered Topology could be an offline planning activity, or it could happen dynamically as new demands come in. using Filtered Topologies is entirely optional in this architecture, and IETF Network Slices could be hosted directly on the underlay network 🦋
remember, an IETF Network Slice is a service requested by and/or provided for the customer 💅 the IETF Network Slice Service gets expressed in terms of one or more connectivity constructs. an implementation or operator is free to limit the number of connectivity constructs in an IETF Network Slice to exactly one. each connectivity construct is associated, within the IETF Network Slice Service request, with a set of SLOs and SLEs. that set doesn't have to be the same for every connectivity construct in the slice, but an implementation or operator is free to require that all connectivity constructs in an IETF Network Slice have the same set of SLOs and SLEs 🔥
an NRP is a subset of the buffer/queuing/scheduling resources and associated policies on each of a connected set of links in the underlay network (for example, as achieved in [RESOURCE-AWARE-SEGMENTS]) 💖 that connected set could be the entire set of links, with all of their buffer/queuing/scheduling resources and behaviors in the underlay network. in that case there would be just one NRP supported in the underlay network. the amount and granularity of resources allocated in an NRP is flexible and depends on the operator's policy. some NRP realizations build NRPs with dedicated topologies, while others use a shared topology for multiple NRPs. realizations of an NRP can be built on a range of existing or new technologies, and this document doesn't constrain which solution technologies get used 🌸
one or more connectivity constructs from one or more IETF Network Slices get mapped to an NRP. a single connectivity construct is mapped to only one NRP (so the relationship is many to one) 🧚 that means all traffic flows in a connectivity construct assigned to an NRP are assigned to that NRP too. also, all PEs connected by a connectivity construct must be present in the NRP that connectivity construct is assigned to ✨
an NRP may be chosen to support a specific connectivity construct because of its ability to support a specific set of SLOs and SLEs, its ability to support particular connectivity constructs, or any administrative or operational reason 💜 an implementation or operator is free to map each connectivity construct to a separate NRP, although there may be scaling implications depending on the solution implemented. so the connectivity constructs from one slice may end up mapped to one or more NRPs. by implication from the above, an implementation or operator is also free to map all the connectivity constructs in a slice to a single NRP and to not share that NRP with connectivity constructs from another slice 👑
an NRP may use work-conserving schedulers, non-work-conserving schedulers, or both (see Section 2 of [RFC3290]), depending on the function it needs to deliver 🫶 how network resources get allocated and managed for an NRP is technology specific, and whether a work-conserving or a non-work-conserving scheduling approach gets adopted is up to the implementation or operator, who is free to choose the set of techniques for NRP realization 💅
figuring out the NRP can get easier if the underlay network topology is first filtered into a Filtered Topology, so you know which subset of network resources suits specific NRPs 🦋 in that case, each Filtered Topology is treated as an underlay network that NRPs can be built on. generating Filtered Topologies is optional in this framework 🌈
the steps described here can be applied in a variety of orders, depending on implementation and deployment preferences 🍓 and the steps can be iterative, so the components keep getting refined and modified as network conditions change and as service requests come in or get relinquished. the underlay network could even be extended, if necessary, to meet the customers' demands 😭✨
7.2. Procedures to Realize IETF Network Slices ✨
okay so there are a bunch of different technologies that can live in the underlay 🧚, including physical connections, MPLS, Time-Sensitive Networking (TSN), Flex-E, etc. 💅
An IETF Network Slice can be realized in a network using specific underlay technology or technologies 🦋. Making a brand new IETF Network Slice happens in these steps:
- An NSC exposes the network slicing capabilities it offers for the network it manages, so the customer can figure out whether to request services and what features are in scope 👀.
- The customer may issue a request to find out whether a specific IETF Network Slice Service could be supported by the network 🤔. An NSC may respond with a simple yes or no and may add some info to a negative response about what it could support if the customer changed some requirements.
- The customer requests an IETF Network Slice Service 💌. An NSC may respond that the slice has or has not been created, and may add some info to a negative response about what it could support if the customer changed some requirements.
- When processing a customer request for an IETF Network Slice Service, an NSC maps the request to the network capabilities and applies provider policies before creating or supplementing the NRP 🎀.
Regardless of how an IETF Network Slice is realized in the network (e.g., using tunnels of different types), the definition of the IETF Network Slice Service does not change at all 🙈. The only difference is how the slice is realized. The following sections briefly introduce how some existing architectural approaches can be applied to realize IETF Network Slices 🌈.
7.3. Applicability of ACTN to IETF Network Slices
Abstraction and Control of TE Networks (ACTN) [RFC8453] is a management architecture and toolkit used to create virtual networks (VNs) on top of a TE underlay network 🧩. The VNs can be presented to customers so they can operate them as private networks 🔐.
ngl the function of ACTN is kind of similar to IETF network slicing 👯. Customer requests for connectivity-based overlay services are mapped to dedicated or shared resources in the underlay network, in a way that meets customer guarantees for SLOs and for separation from other customers' traffic 💜. [RFC8453] describes the function of ACTN as collecting resources to establish a logically dedicated virtual network over one or more TE networks. So in the case of a TE-enabled underlay network, the ACTN VN can be used as a basis to realize IETF network slicing ✨.
While the ACTN framework is a generic VN framework that can be used for VN services beyond the IETF Network Slice, it is also a suitable basis for delivering and realizing IETF Network Slices 💖.
Further discussion of the applicability of ACTN to IETF Network Slices, including a discussion of the relevant YANG models, can be found in [ACTN-NS] 📚.
7.4. Applicability of Enhanced VPNs to IETF Network Slices
An enhanced VPN is designed to support the needs of new applications, particularly applications associated with 5G services 📱. The approach is based on existing VPN and TE technologies, but it adds characteristics that specific services require over and above those previously associated with VPN services 🦋.
An enhanced VPN can be used to provide enhanced connectivity services between customer sites, and it can be used to create the infrastructure that underpins an IETF Network Slice Service 🏗️.
It is envisaged that enhanced VPNs will be delivered using a combination of existing, modified, and new networking technologies 🌸.
[ENHANCED-VPN] describes the framework for enhanced VPN services 📖.
7.5. Network Slicing and Aggregation in IP/MPLS Networks
Network slicing gives you the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions, so each slice can be dedicated to specific services or customers 🍰. The support of resource preemption between IETF Network Slices is deployment specific 🤷♀️.
Lots of approaches are being worked on right now to support IETF Network Slices in IP and MPLS networks, with or without the use of Segment Routing 🛠️. Most of these approaches use a way of marking packets so that network nodes can apply specific routing and forwarding behaviors to packets that belong to different IETF Network Slices 🏷️. Different mechanisms for marking packets have been proposed (including using MPLS labels and Segment Routing segment IDs), and those mechanisms are agnostic to the path control technology used within the underlay network 🫶.
These approaches are also sensitive to the scaling concerns of supporting a large number of IETF Network Slices within a single IP or MPLS network 😭. So they offer ways to aggregate the connectivity constructs of slices (or whole slices), so the packet markings indicate an aggregate or grouping where all of the packets are subject to the same routing and forwarding behavior 🧁.
At this stage, it is inappropriate to cite any of these proposed solutions that are currently work in progress and not yet adopted as IETF work 🚫.
7.6. Network Slicing and Service Function Chaining (SFC)
A customer may request an IETF Network Slice Service that involves a set of service functions (SFs), together with the order in which these SFs are invoked 🔗. The customer can also specify the service objectives to be met by the underlay network (e.g., one-way delay to cross a service function path, one-way delay to reach a specific SF) ⏱️. These SFs are considered ancillary CEs and are possibly placeholders (i.e., the SFs are identified, but not their locators) 👻.
Service Function Chaining (SFC) [RFC7665] techniques can be used by a provider to instantiate such an IETF Network Slice Service. An NSC may proceed as follows 🪄.
- Expose a set of ancillary CEs that are hosted in the underlay network 🏠.
- Capture the SFC requirements (including traffic performance metrics) from the customer. One or more service chains may be associated with the same IETF Network Slice Service as connectivity constructs 📋.
- Execute an SF placement algorithm to decide where to locate the ancillary CEs in order to fulfill the service objectives 🧠.
- Generate SFC classification rules to identify part of the slice traffic that will be bound to an SFC. These classification rules may be the same as or distinct from the identification rules used to bind incoming traffic to the associated IETF Network Slice 🎯.
An NSC also generates a set of SFC forwarding policies that govern how the traffic will be forwarded along a Service Function Path (SFP) 🛣️.
- Identify the appropriate Classifiers in the underlay network and provision them with the classification rules. Likewise, an NSC communicates the SFC forwarding policies to the appropriate Service Function Forwarders (SFFs) 📬.
The provider can enable an SFC data plane mechanism, such as those described in [RFC8300], [RFC8596], or [RFC9491] 💫.
8. Isolation in IETF Network Slices 🫧
8.1. Isolation as a Service Requirement
An IETF Network Slice Service customer may request that the IETF Network Slice delivered to them is such that changes to other IETF Network Slices or to other services do not have any negative impact on the delivery of the IETF Network Slice 🛡️. The IETF Network Slice Service customer may specify the extent to which their IETF Network Slice Service is unaffected by changes in the provider network or by the behavior of other IETF Network Slice Service customers 🙅♀️. The customer may express this via an SLE they agree on with the provider 🤝. This concept is termed "isolation" 💅.
In general, a customer cannot tell whether a service provider is meeting an isolation SLE 🫣. If the service varies such that an SLO is breached, then the customer will become aware of the problem. And if the service varies within the allowed bounds of the SLOs, there may be no noticeable indication that this SLE has been violated 👀.
8.2. Isolation in IETF Network Slice Realization
Isolation may be achieved in the underlay network by various forms of resource partitioning, ranging from dedicated allocation of resources for a specific IETF Network Slice to sharing resources with safeguards 🏰. For example, traffic separation between different IETF Network Slices may be achieved using VPN technologies, such as L3VPN, L2VPN, EVPN, etc. 🔀. Interference avoidance may be achieved by network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing in using shared network resources, etc. 🚦. Finally, service continuity may be ensured by reserving backup paths for critical traffic and dedicating specific network resources for a selected number of IETF Network Slices 🩷.
9. Management Considerations 🎀
IETF Network Slice realization needs to be instrumented so you can track how it is working, and it might be necessary to modify the IETF Network Slice as requirements change 🔧. Dynamic reconfiguration might be needed 🔄.
The various management interfaces and components are discussed in Section 6 🗂️.
10. Security Considerations 🔐
Okay bestie, this document is all about terminology, so it has no direct effect on the security of implementations or deployments 💅. There are still a few security aspects worth flagging, so let's go 👀.
Conformance to security constraints: Specific security requests from customer-defined IETF Network Slice Services will be mapped to their realization in the underlay networks. Underlay networks will need capabilities to conform to the customer's requests, since some aspects of security may be expressed in SLEs ✨.
IETF NSC authentication: Underlay networks need to be protected against attacks from an adversary NSC, because that could destabilize overall network operations 😭. An IETF Network Slice may span different networks, so an NSC should have strong authentication with each of these networks 🔒. Both the IETF Network Slice Service Interface and the Network Configuration Interface also need to be secured with a robust authentication and authorization mechanism, plus an associated auditing mechanism 🧾.
Specific isolation criteria: The nature of conformance to isolation requests means that it should not be possible to attack an IETF Network Slice Service by varying the traffic on other services or slices carried by the same underlay network 🛡️. In general, isolation is expected to strengthen the IETF Network Slice security 💜.
Data confidentiality and integrity of an IETF Network Slice: An IETF Network Slice might include encryption and other security features as part of the service (for example, as SLEs). However, a customer who wants to guarantee that their data is secure from inspection or modification as it passes through the network of the operator that provides the IETF Network Slice Service will need to provision their own security solutions (e.g., with IPsec) or send only already otherwise-encrypted traffic through the slice 🙅. Don't assume the slice is doing the locking for you 🔐.
See [NGMN-SEC] on 5G network slice security for discussion relevant to this section 📚.
IETF Network Slices might use underlying virtualized networking. All types of virtual networking require special consideration to be given to the separation of traffic between distinct virtual networks, as well as some amount of protection from effects of traffic use of underlay network (and other) resources from other virtual networks sharing those resources 🌐.
For example, if a service requires a specific upper bound on latency, then that service could be degraded with added delay caused by the processing of packets from another service or application that shares the same network resources. Thus, without careful planning or traffic policing, it may be possible to attack an IETF Network Slice Service simply by increasing the traffic on another service in the network 🙈.
Similarly, in a network with virtual functions, noticeably impeding access to a function used by another IETF Network Slice (for instance, compute resources) can be just as service-degrading as delaying physical transmission of associated packet in the network. Again, careful planning and policing of service demands may mitigate such attacks 🧠.
Both of these forms of attack may also be mitigated by reducing the access to information about how IETF Network Slice Services are supported in a network 🕵️.
11. Privacy Considerations 🫣
Privacy of IETF Network Slice Service customers must be preserved. It should not be possible for one IETF Network Slice Service customer to discover the presence of other customers, nor should sites that are members of one IETF Network Slice be visible outside the context of that IETF Network Slice 👀.
In this sense, it is of paramount importance that the system uses the privacy protection mechanism defined for the specific underlay technologies that support the slice, including in particular those mechanisms designed to preclude acquiring identifying information associated with any IETF Network Slice Service customer 🔥.
12. IANA Considerations 📋
This document has no IANA actions 🌸.
13. Informative References ✨
okay bestie, here's the reading list 📚 these are the outside docs the spec points to, and I'm copying every tag, title, date, and link exactly so nothing gets lost 🫶
[ACTN-NS] King, D., Drake, J., Zheng, H., and A. Farrel,
"Applicability of Abstraction and Control of Traffic
Engineered Networks (ACTN) to Network Slicing", Work in
Progress, Internet-Draft, draft-ietf-teas-applicability-
actn-slicing-05, 11 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
applicability-actn-slicing-05>.
[ENHANCED-VPN]
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
Framework for NRP-based Enhanced Virtual Private Network",
Work in Progress, Internet-Draft, draft-ietf-teas-
enhanced-vpn-17, 25 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
enhanced-vpn-17>.
[GNMI] Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
C., and C. Morrow, "gRPC Network Management Interface
(gNMI)", Work in Progress, Internet-Draft, draft-
openconfig-rtgwg-gnmi-spec-01, 5 March 2018,
<https://datatracker.ietf.org/doc/html/draft-openconfig-
rtgwg-gnmi-spec-01>.
[HIPAA] HHS, "The Security Rule", <https://www.hhs.gov/hipaa/for-
professionals/security/index.html>.
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Security", IEEE Std
802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
2018, <https://ieeexplore.ieee.org/document/8585421>.
[NFVArch] ETSI, "Network Functions Virtualisation (NFV);
Architectural Framework", V1.1.1, ETSI GS NFV 002, October
2013, <http://www.etsi.org/deliver/etsi_gs/
nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf>.
[NGMN-NS-Concept]
NGMN Alliance, "Description of Network Slicing Concept",
January 2016, <https://ngmn.org/wp-content/
uploads/160113_NGMN_Network_Slicing_v1_0.pdf>.
[NGMN-SEC] NGMN, "5G security recommendations Package #2 - Network
Slicing", April 2016, <https://www.ngmn.org/wp-
content/uploads/Publications/2016/160429_NGMN_5G_Security_
Network_Slicing_v1_0.pdf>.
[ORAN] O-RAN, "O-RAN Working Group 1 Slicing Architecture",
O-RAN.WG1 v06.00, 2022,
<https://orandownloadsweb.azurewebsites.net/
specifications>.
[PCI] PCI Security Standards Council, "PCI DSS", March 2022,
<https://www.pcisecuritystandards.org/document_library>.
[RESOURCE-AWARE-SEGMENTS]
Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li,
"Introducing Resource Awareness to SR Segments", Work in
Progress, Internet-Draft, draft-ietf-spring-resource-
aware-segments-08, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
resource-aware-segments-08>.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, DOI 10.17487/RFC4397, February
2006, <https://www.rfc-editor.org/info/rfc4397>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008,
<https://www.rfc-editor.org/info/rfc5212>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/info/rfc7239>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>.
[RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu,
Q., and V. Lopez, "A YANG Network Data Model for Service
Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408,
June 2023, <https://www.rfc-editor.org/info/rfc9408>.
[RFC9491] Guichard, J., Ed. and J. Tantsura, Ed., "Integration of
the Network Service Header (NSH) and Segment Routing for
Service Function Chaining (SFC)", RFC 9491,
DOI 10.17487/RFC9491, November 2023,
<https://www.rfc-editor.org/info/rfc9491>.
[TS23.501] 3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501, 2019.
[TS28.530] 3GPP, "Management and orchestration; Concepts, use cases
and requirements", 3GPP TS 28.530, 2019.
[TS33.210] 3GPP, "Network Domain Security (NDS); IP network layer
security", Release 14, December 2016,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2279>.
[USE-CASES]
Contreras, L. M., Homma, S., Ordonez-Lucena, J. A.,
Tantsura, J., and H. Nishihara, "IETF Network Slice Use
Cases and Attributes for the Slice Service Interface of
IETF Network Slice Controllers", Work in Progress,
Internet-Draft, draft-ietf-teas-ietf-network-slice-use-
cases-01, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slice-use-cases-01>.Appendix A. Examples 🎀
okay so this appendix is all about realization examples 🌸 it is not meant to be a complete list of every possible deployment, and it does not give you the one true way to build these things 🙈
the examples here must not be considered to be normative 💅 the descriptions of terms and concepts in the body of the document take precedence, so if an example and the main text ever disagree, the main text wins, no debate 👑
A.1. Multi-Point to Point Service
ok so as we saw in Section 4.2, an MP2P service can be realized with multiple P2P connectivity constructs ✨ Figure 5 is a super simple MP2P service where traffic goes from any of CE1, CE2, and CE3 to the receiver, which is CE4 🦋 the service is made of three P2P connectivity constructs: CE1-CE4, CE2-CE4, and CE3-CE4 💜
CE1
___|________
/ \ \
( \______ )
( \)
CE2---(--------------)---CE4
( _______/)
( / )
\___|________/
|
CE3
Figure 5: Example MP2P Service with P2P ConnectionsA.2. Service Function Chaining and Ancillary CEs ✨
Okay so, Section 4.2.3 is where ancillary CEs first show up 🦋. Figure 6 is a super simple example of IETF Network Slices with connectivity constructs that deliver traffic from CE1 to CE3, and it picks up a service function along the way 💅.
CE1 CE2 CE3
xo* * * *ox
____xo*_________*_*_________*ox____
_/ xo* * * *ox \_
/ xo*********** ***********ox \
( xo ox )
( xooooooooo(ACE1)oooooooooox )
( x x )
( x ------------------ x )
( x | Service Function | x )
( x | ....(ACE2).... | x )
( x | : : | x )
( xxxx.:....(ACE3)....:.xxxxx )
( | : : | )
( | ....(ACE4).... | )
( | | )
( ------------------ )
( )
\_ Operator Network _/
\___________________________________/
Figure 6: Example with Ancillary CEsSo picture this 🌸: a customer wants traffic to go from CE1 to CE3, but they also want a service function sitting inside their own network at CE2 🏠. To make that happen, the customer can request an IETF Network Slice Service with two P2P connectivity constructs: CE1-CE2 and CE2-CE3. Those are the * lines in Figure 6 ✨.
Or, plot twist 🎀, the service function for that same CE1 to CE3 flow can live at a node inside the network operator's infrastructure. That node is an ancillary CE in the IETF Network Slice Service the customer asks for. This version has two P2P connectivity constructs: CE1-ACE1 and ACE1-CE3, drawn with o in Figure 6 💜. How the customer finds out that the ancillary CE exists, and what service functions it offers, is something the customer and the network operator agree on between themselves 🤝.
And then there's the most flexible option 🧚. The customer knows the operator can provide the service function, but doesn't know where the ancillary CE hosting it is. It could even be that the service function is hosted at several ancillary CEs (ACE2, ACE3, and ACE4 in Figure 6). The customer might know those identities but not want to pick one, or might not know they exist at all 🙈. In that case, the IETF Network Slice Service request has two P2P connectivity constructs: CE1-ServiceFunction and ServiceFunction-CE3, drawn with x in Figure 6 🦋. It's left up to the network operator to decide which ancillary CE to use and how to realize the connectivity constructs 👑.
A.3. Hub and Spoke 🌈
Hub and spoke is a super popular way to realize A2A connectivity, supporting multiple P2P traffic flows (where the hub does the routing) or P2MP flows (where the hub handles replication) 🔥. Honestly, in a lot of cases it's the network operator's call whether to use hub and spoke to realize a mesh of P2P connectivity constructs or P2MP connectivity constructs. It's entirely their business, because the customer isn't aware of how the connectivity constructs are supported inside the network 🤫.
BUT 💅, the customer might want to control the behavior and location of the hub. In that case, the hub shows up as an ancillary CE, like in Figure 7 ✨.
For the P2P mesh case, the customer doesn't specify a mesh of P2P connectivity constructs (like CE1-CE2, CE1-CE3, CE2-CE3, and the matching reverse direction connectivity). Instead, they connect each CE to the hub with P2P connectivity constructs (CE1-Hub, CE2-Hub, CE3-Hub, and the matching reverse direction connectivity). This scales way better for provisioning than a full mesh, but it requires that the hub can route traffic between connectivity constructs 💖.
For the P2MP case, the customer doesn't specify a single P2MP connectivity construct (here, CE3-{CE1+CE2}). They request three P2P connectivity constructs instead: CE3-Hub, Hub-CE1, and Hub-CE2 🍓. The hub is responsible for replicating the traffic from CE3 and sending it to both CE1 and CE2 🫶.
------------
CE1 | Hub | CE2
|| ------------ ||
___||_____||__||__||_____||___
/ || || || || || \
( ====== || ====== )
( || )
( || )
\______________||______________/
||
CE3
Figure 7: Example Hub and Spoke under Customer ControlA.4. Layer 3 VPN 💜
Layer 3 VPNs are a really common service that network operators offer their customers 💼. They can be modeled as an A2A service, but they're often realized as a mesh of P2P connections. If multicast is supported, they may be realized as a mesh of P2MP connections instead 🌸.
Figure 8 shows an IETF Network Slice Service with a single A2A connectivity construct between the SDPs CE1, CE2, CE3, and CE4. It's a free choice how the network operator realizes this service 🎀. They might use a full mesh of P2P connections, a hub-and-spoke configuration, or some combination of the two 🦋.
CE1 CE2
____|_______________|____
/ :...............: \
( :. . : )
( : ...... . : )
( : ..... : )
( : .... . : )
( : . .... : )
( : . . : )
( :...............: )
\____:_______________:____/
| |
CE3 CE4
Figure 8: Example L3VPN ServiceA.5. Hierarchical Composition of Network Slices 🧩
As mentioned in Section 5.3, IETF Network Slices may be arranged hierarchically ✨. There's nothing special or novel about that kind of arrangement. It models the hierarchical arrangement of services of virtual networks in lots of other environments too 🌈.
As shown in Figure 9, an Operator's Controller (NSC) that's asked to provide an IETF Network Slice Service for a customer may, in turn, request an IETF Network Slice Service from another carrier 👑. The Operator's NSC may manage and control the underlay IETF Network Slice by modifying the requested connectivity constructs and changing the SLAs 🛠️. The customer is totally unaware of the slice hierarchy, and the underlay carrier is totally unaware of how its slice is being used 🙈.
This stacking of IETF Network Slice constructs isn't different from how virtual networks may be arranged 💅.
--------------
| Network |
| Slice |
| Orchestrator |
--------------
| IETF Network Slice
| Service Request
| Customer view
....|................................
-v---------------- Operator view
|Controller |
| ------------ |
| | IETF | |
| | Network |---|---
| | Slice | | |
| | Controller | | |
| | (NSC) | | |
| ------------ | |
------------------ |
| IETF Network Slice
| Service Request
|
.........................|.....................
----------v------- Carrier view
|Controller |
| ------------ |
| | IETF | |
| | Network | |
| | Slice | |
| | Controller | |
| | (NSC) | |
| ------------ |
....| | Network |............
| | Configuration | Underlay Network
| v |
| ------------ |
| | Network | |
| | Controller | |
| | (NC) | |
| ------------ |
------------------
| Device Configuration
v
Figure 9: Example Hierarchical Arrangement of IETF Network SlicesIn this case, the network hierarchy can also be used to provide connectivity between points in the higher-layer network, as shown in Figure 10 🦋. Here, an IETF Network Slice may be requested of the lower-layer network to supply the desired connectivity constructs. Those supplement the connectivity in the higher-layer network, where that connectivity might be presented as a virtual link 🔗.
CE1 CE2
| |
| |
_|_________________________________________|_
( : : )
( :.............. ..............: )
(_______________:_____________:_______________)
__|_____________|__
( : : )
( :.............: )
(___________________)
Figure 10: Example Hierarchical Arrangement of IETF Network
Slices to Bridge ConnectivityA.6. Horizontal Composition of Network Slices ✨
okay so sometimes end-to-end connectivity comes from a team of networks working together, not just one network 🫶 (this is the stuff we covered in Section 5.3). picture multiple interconnected networks that all chip in to give you the connectivity you need, as shown in Figure 11 🦋. they can use totally different technologies and they might belong to different administrators, so it's a whole group project 💅
CE1 CE2
| |
SDP1 SDP2
| |
_|____ ______ ______ ____|_
( ) ( ) ( ) ( )
( )---( )---( )---( )
(______) (______) (______) (______)
Figure 11: Example Customer View of Interconnected Networks
Providing End-to-End Connectivityso in this setup the customer (that's CE1 and CE2 🎀) can ask for an IETF Network Slice Service that links the CEs together. the customer only looks at the SDPs on the edges (SDP1 and SDP2 in Figure 11) and honestly? they probably have no idea how the end-to-end connectivity gets put together behind the scenes 🙈
but here's the tea 🍵: since the networks can be different technologies run by different admins, each network gets sliced separately, and the networks have to coordinate to actually deliver what was asked for 🔥 the Network-to-Network Interfaces (NNIs) show up as SDPs for the IETF Network Slices in each network, so every network is individually sliced. in Figure 12, network 1 (N/w1) is sliced between SDP1 and SDPX, N/w2 is sliced between SDPY and SDPU, and so on 💜 the coordination part is all about binding those SDPs (and therefore the connectivity constructs) together so the end-to-end connectivity hits the required SLOs and SLEs ✨ that's how you get simple OR super complex end-to-end connectivity, with different connectivity constructs in each slice of each network "stitched" together. iconic, honestly 👑
CE1 CE2
| |
SDP1 SDP2
| |
_|____ ______ ______ ____|_
( ) SDPX ( ) SDPU ( ) SDPS ( )
( N/w1 )------( N/w2 )------( N/w3 )------( N/w4 )
(______) SDPY (______) SDPV (______) SDPT (______)
Figure 12: Example Delivery of an End-to-End IETF Network Slice with
Interconnected Networksand the controller and coordinator setup? it's giving layers 🧚 Figure 13 shows how it all fits together, with the coordinator sitting between the customer's view and the controllers that run each operator's network.
--------------
| Network |
| Slice |
| Orchestrator |
--------------
| IETF Network Slice
| Service Request
| Customer view
....|................................
-v---------------- Coordinator view
|Coordinator |
| |
------------------
| |_________________
| |
| |
....|....................... ....|.....................
-v-------------- -v--------------
|Controller1 | Operator1 |Controller2 | Operator2
| ------------ | | ------------ |
| | IETF | | | | IETF | |
| | Network | | | | Network | |
| | Slice | | | | Slice | |
| | Controller | | | | Controller | |
| | (NSC) | | | | (NSC) | |
| ------------ | | ------------ |
....| | Network |............ | | Network |............
| | Config | Underlay1 | | Config | Underlay2
| v | | v |
| ------------ | | ------------ |
| | Network | | | | Network | |
| | Controller | | | | Controller | |
| | (NC) | | | | (NC) | |
| ------------ | | ------------ |
---------------- ----------------
| Device Configuration
v
Figure 13: Example Relationship of IETF Network Slice CoordinationAcknowledgments ✨
okay so the whole TEAS Network Slicing design team, plus everyone who joined the related chats, helped make this document 🫶 some text bits were copied over from [ENHANCED-VPN], and we are so grateful for that 🙏
big thanks to the contributing authors listed in the "Contributors" section for their significant help 💖 we also want to shout out these people who came to one or more design team meetings (and aren't listed anywhere else in this doc) 📣
- Aihua Guo
- Bo Wu
- Greg Mirsky
- Lou Berger
- Rakesh Gandhi
- Ran Chen
- Sergio Belotti
- Stewart Bryant
- Tomonobu Niwa
- Xuesong Geng
and extra useful comments came from Daniele Ceccarelli, Uma Chunduri, Pavan Beeram, Tarek Saad, Kenichi Ogaki, Oscar Gonzalez de Dios, Xiaobing Niu, Dan Voyer, Igor Bryskin, Luay Jalil, Joel Halpern, John Scudder, John Mullooly, Krzysztof Szarkowicz, Jingrong Xie, Jia He, Reese Enghardt, Dirk Von Hugo, Erik Kline, and Éric Vyncke 🌸 literally iconic people, all of them 😭
this work is partly supported by the European Commission under Horizon 2020 grant agreement number 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow) 🇪🇺 💜
Contributors ✨
these folks contributed a lot to the content and should be treated as coauthors 👑 Eric Gray was the original editor of the foundation documents, and his name is still very much part of the legacy 🧚
Eric Gray
RetiredJari Arkko
Ericsson
Email: jari.arkko@piuha.netMohamed Boucadair
Orange
Email: mohamed.boucadair@orange.comDhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.comJie Dong
Huawei
Email: jie.dong@huawei.comXufeng Liu
Volta Networks
Email: xufeng.liu.ietf@gmail.comAuthors' Addresses ✨
and here are the authors, with all their contact details 💅🦋
Adrian Farrel (editor)
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.ukJohn Drake (editor)
Individual
United States of America
Email: je_drake@yahoo.comReza Rokui
Ciena
Email: rrokui@ciena.comShunsuke Homma
NTT
Japan
Email: shunsuke.homma.ietf@gmail.comKiran Makhijani
Futurewei
United States of America
Email: kiran.ietf@gmail.comLuis M. Contreras
Telefonica
Spain
Email: luismiguel.contrerasmurillo@telefonica.comJeff Tantsura
Nvidia
Email: jefftant.ietf@gmail.com📦 where this page comes from
- ietf: rfc9543 2024-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms