rfc9732v1.txt | rfc9732.txt | |||
---|---|---|---|---|
skipping to change at line 12 ¶ | skipping to change at line 12 ¶ | |||
Internet Engineering Task Force (IETF) J. Dong | Internet Engineering Task Force (IETF) J. Dong | |||
Request for Comments: 9732 Huawei | Request for Comments: 9732 Huawei | |||
Category: Informational S. Bryant | Category: Informational S. Bryant | |||
ISSN: 2070-1721 University of Surrey | ISSN: 2070-1721 University of Surrey | |||
Z. Li | Z. Li | |||
China Mobile | China Mobile | |||
T. Miyasaka | T. Miyasaka | |||
KDDI Corporation | KDDI Corporation | |||
Y. Lee | Y. Lee | |||
Samsung | Samsung | |||
January 2025 | February 2025 | |||
A Framework for Network Resource Partition Based Enhanced Virtual | A Framework for NRP-Based Enhanced Virtual Private Networks | |||
Private Networks | ||||
Abstract | Abstract | |||
This document describes the framework for enhanced Virtual Private | This document describes a framework for Enhanced Virtual Private | |||
Networks (VPNs) that are Network Resource Partition (NRP) based in | Networks (VPNs) based on Network Resource Partitions (NRPs) in order | |||
order to support the needs of applications with specific traffic | to support the needs of applications with specific traffic | |||
performance requirements (e.g., low latency, bounded jitter). An NRP | performance requirements (e.g., low latency, bounded jitter). An NRP | |||
represents a subset of network resources and associated policies in | represents a subset of network resources and associated policies in | |||
the underlay network. NRP-based enhanced VPNs leverage the VPN and | the underlay network. NRP-based enhanced VPNs leverage the VPN and | |||
Traffic Engineering (TE) technologies and add characteristics that | Traffic Engineering (TE) technologies and add characteristics that | |||
specific services require beyond those provided by conventional VPNs. | specific services require beyond those provided by conventional VPNs. | |||
Typically, an NRP-based enhanced VPN will be used to underpin network | Typically, an NRP-based enhanced VPN will be used to underpin network | |||
slicing, but it could also be of use in its own right providing | slicing, but it could also be of use in its own right providing | |||
enhanced connectivity services between customer sites. This document | enhanced connectivity services between customer sites. This document | |||
also provides an overview of relevant technologies in different | also provides an overview of relevant technologies in different | |||
network layers and identifies some areas for potential new work. | network layers and identifies some areas for potential new work. | |||
skipping to change at line 88 ¶ | skipping to change at line 87 ¶ | |||
3.5. Customized Control | 3.5. Customized Control | |||
3.6. Applicability to Overlay Technologies | 3.6. Applicability to Overlay Technologies | |||
3.7. Inter-Domain and Inter-Layer Network | 3.7. Inter-Domain and Inter-Layer Network | |||
4. The Architecture of NRP-Based Enhanced VPNs | 4. The Architecture of NRP-Based Enhanced VPNs | |||
4.1. Layered Architecture | 4.1. Layered Architecture | |||
4.2. Connectivity Types | 4.2. Connectivity Types | |||
4.3. Application-Specific Data Types | 4.3. Application-Specific Data Types | |||
4.4. Scalable Service Mapping | 4.4. Scalable Service Mapping | |||
5. Candidate Technologies | 5. Candidate Technologies | |||
5.1. Underlay Forwarding Resource Partitioning | 5.1. Underlay Forwarding Resource Partitioning | |||
5.1.1. Flexible Ethernet | 5.1.1. Flex Ethernet | |||
5.1.2. Dedicated Queues | 5.1.2. Dedicated Queues | |||
5.1.3. Time-Sensitive Networking | 5.1.3. Time-Sensitive Networking | |||
5.2. Network Layer Encapsulation and Forwarding | 5.2. Network Layer Encapsulation and Forwarding | |||
5.2.1. Deterministic Networking (DetNet) | 5.2.1. Deterministic Networking (DetNet) | |||
5.2.2. MPLS Traffic Engineering (MPLS-TE) | 5.2.2. MPLS Traffic Engineering (MPLS-TE) | |||
5.2.3. Segment Routing | 5.2.3. Segment Routing | |||
5.2.4. New Encapsulation Extensions | 5.2.4. New Encapsulation Extensions | |||
5.3. Non-Packet Data Plane | 5.3. Non-Packet Data Plane | |||
5.4. Control Plane | 5.4. Control Plane | |||
5.5. Management Plane | 5.5. Management Plane | |||
skipping to change at line 173 ¶ | skipping to change at line 172 ¶ | |||
simply use the term "network slice" to refer to this concept. A | simply use the term "network slice" to refer to this concept. A | |||
network slice service enables connectivity between a set of Service | network slice service enables connectivity between a set of Service | |||
Demarcation Points (SDPs) with specific Service Level Objectives | Demarcation Points (SDPs) with specific Service Level Objectives | |||
(SLOs) and Service Level Expectations (SLEs) over a common underlay | (SLOs) and Service Level Expectations (SLEs) over a common underlay | |||
network. A network slice can be realized as a logical network | network. A network slice can be realized as a logical network | |||
connecting a number of endpoints and is associated with a set of | connecting a number of endpoints and is associated with a set of | |||
shared or dedicated network resources that are used to satisfy the | shared or dedicated network resources that are used to satisfy the | |||
SLO and SLE requirements. A network slice is considered to be one | SLO and SLE requirements. A network slice is considered to be one | |||
target use case of enhanced VPNs. | target use case of enhanced VPNs. | |||
[RFC9543] also introduces the concept of Network Resource Partition | [RFC9543] also introduces the concept of NRP, which is a subset of | |||
(NRP), which is a subset of the buffer/queuing/scheduling resources | the buffer/queuing/scheduling resources and associated policies on | |||
and associated policies on each of a connected set of links in the | each of a connected set of links in the underlay network. An NRP can | |||
underlay network. An NRP can be associated with a dedicated or | be associated with a dedicated or shared network topology to select | |||
shared network topology to select or specify the set of links and | or specify the set of links and nodes involved. | |||
nodes involved. | ||||
The requirements of enhanced VPN services cannot simply be met by | The requirements of enhanced VPN services cannot simply be met by | |||
overlay networks: enhanced VPN services require tighter coordination | overlay networks: enhanced VPN services require tighter coordination | |||
and integration between the overlay and the underlay networks. | and integration between the overlay and the underlay networks. | |||
In the overlay network, the VPN has been defined as the network | In the overlay network, the VPN has been defined as the network | |||
construct to provide the required connectivity for different services | construct to provide the required connectivity for different services | |||
or customers. Multiple VPN flavors can be considered to create that | or customers. Multiple VPN flavors can be considered to create that | |||
construct [RFC4026]. In the underlay network, the NRP is used to | construct [RFC4026]. In the underlay network, the NRP is used to | |||
represent a subset of the network resources and associated policies | represent a subset of the network resources and associated policies | |||
skipping to change at line 220 ¶ | skipping to change at line 218 ¶ | |||
enhanced VPN service. | enhanced VPN service. | |||
* The design of the data plane for NRP-based enhanced VPNs. | * The design of the data plane for NRP-based enhanced VPNs. | |||
* The necessary control and management protocols in both the | * The necessary control and management protocols in both the | |||
underlay and the overlay of enhanced VPNs. | underlay and the overlay of enhanced VPNs. | |||
* The mechanisms to achieve integration between the overlay network | * The mechanisms to achieve integration between the overlay network | |||
and the underlay network. | and the underlay network. | |||
* The necessary Operation, Administration, and Management (OAM) | * The necessary Operation, Administration, and Maintenance (OAM) | |||
methods to instrument an enhanced VPN to make sure that the | methods to instrument an enhanced VPN to make sure that the | |||
required Service Level Agreement (SLA) between the customer and | required Service Level Agreement (SLA) between the customer and | |||
the network operator is met and to take any corrective action | the network operator is met and to take any corrective action | |||
(such as switching traffic to an alternate path) to avoid SLA | (such as switching traffic to an alternate path) to avoid SLA | |||
violation. | violation. | |||
One possible layered network structure to achieve these objectives is | One possible layered network structure to achieve these objectives is | |||
shown in Section 4.1. | shown in Section 4.1. | |||
It is not envisaged that enhanced VPN services will replace | It is not envisaged that enhanced VPN services will replace | |||
skipping to change at line 245 ¶ | skipping to change at line 243 ¶ | |||
2. Terminology | 2. Terminology | |||
In this document, the relationship of the four terms "VPN", "enhanced | In this document, the relationship of the four terms "VPN", "enhanced | |||
VPN", "NRP", and "Network Slice" are as follows: | VPN", "NRP", and "Network Slice" are as follows: | |||
* A Virtual Private Network (VPN) refers to the overlay network | * A Virtual Private Network (VPN) refers to the overlay network | |||
service that provides connectivity between different customer | service that provides connectivity between different customer | |||
sites and that maintains traffic separation between different | sites and that maintains traffic separation between different | |||
customers. Examples of technologies to provide VPN services are | customers. Examples of technologies to provide VPN services are | |||
as follows: IPVPN [RFC2764], L2VPN [RFC4664], L3VPN [RFC4364], and | as follows: IPVPN [RFC2764] [RFC4364], L2VPN [RFC4664], and EVPN | |||
EVPN [RFC7432]. | [RFC7432]. | |||
* An enhanced VPN service is an evolution of the VPN service that | * An enhanced VPN service is an evolution of the VPN service that | |||
makes additional service-specific commitments. An NRP-based | makes additional service-specific commitments. An NRP-based | |||
enhanced VPN is made by integrating a VPN with a set of network | enhanced VPN is made by integrating a VPN with a set of network | |||
resources allocated in the underlay network (i.e., an NRP). | resources allocated in the underlay network (i.e., an NRP). | |||
* A Network Resource Partition (NRP), as defined in [RFC9543], is a | * An NRP, as defined in [RFC9543], is a subset of the | |||
subset of the buffer/queuing/scheduling resources and associated | buffer/queuing/scheduling resources and associated policies on | |||
policies on each of a connected set of links in the underlay | each of a connected set of links in the underlay network. An NRP | |||
network. An NRP can be associated with a dedicated or shared | can be associated with a dedicated or shared network topology to | |||
network topology to select or specify the set of links and nodes | select or specify the set of links and nodes involved. An NRP is | |||
involved. An NRP is designed to meet the network resources and | designed to meet the network resources and performance | |||
performance characteristics required by the enhanced VPN services. | characteristics required by the enhanced VPN services. | |||
* A network slice service could be delivered by provisioning one or | * A network slice service could be delivered by provisioning one or | |||
more NRP-based enhanced VPNs in the network. Other mechanisms for | more NRP-based enhanced VPNs in the network. Other mechanisms for | |||
realizing network slices may exist but are not in the scope of | realizing network slices may exist but are not in the scope of | |||
this document. | this document. | |||
The term "tenant" is used in this document to refer to a customer of | The term "tenant" is used in this document to refer to a customer of | |||
the enhanced VPN services. | the enhanced VPN services. | |||
The following terms, defined in other documents, are also used in | The following terms, defined in other documents, are also used in | |||
skipping to change at line 282 ¶ | skipping to change at line 280 ¶ | |||
SLA: Service Level Agreement (see [RFC9543]) | SLA: Service Level Agreement (see [RFC9543]) | |||
SLO: Service Level Objective (see [RFC9543]) | SLO: Service Level Objective (see [RFC9543]) | |||
SLE: Service Level Expectation (see [RFC9543]) | SLE: Service Level Expectation (see [RFC9543]) | |||
ACTN: Abstraction and Control of TE Networks (see [RFC8453]) | ACTN: Abstraction and Control of TE Networks (see [RFC8453]) | |||
DetNet: Deterministic Networking (see [RFC8655]) | DetNet: Deterministic Networking (see [RFC8655]) | |||
FlexE: Flexible Ethernet (see [FLEXE]) | FlexE: Flex Ethernet (see [FLEXE]) | |||
TSN: Time-Sensitive Networking (see [TSN]) | TSN: Time-Sensitive Networking (see [TSN]) | |||
VN: Virtual Network (see [RFC8453]) | VN: Virtual Network (see [RFC8453]) | |||
3. Overview of the Requirements | 3. Overview of the Requirements | |||
This section provides an overview of the requirements of an enhanced | This section provides an overview of the requirements of an enhanced | |||
VPN service. | VPN service. | |||
skipping to change at line 310 ¶ | skipping to change at line 308 ¶ | |||
guaranteed maximum packet loss, guaranteed maximum delay, and | guaranteed maximum packet loss, guaranteed maximum delay, and | |||
guaranteed delay variation. Note that these guarantees apply to | guaranteed delay variation. Note that these guarantees apply to | |||
conformance traffic; out-of-profile traffic will be handled according | conformance traffic; out-of-profile traffic will be handled according | |||
to a separate agreement with the customer (see, for example, | to a separate agreement with the customer (see, for example, | |||
Section 3.6 of [RFC7297]). | Section 3.6 of [RFC7297]). | |||
Guaranteed maximum packet loss is usually addressed by setting packet | Guaranteed maximum packet loss is usually addressed by setting packet | |||
priorities, queue sizes, and discard policies. However, this becomes | priorities, queue sizes, and discard policies. However, this becomes | |||
more difficult when the requirement is combined with latency | more difficult when the requirement is combined with latency | |||
requirements. The limiting case is zero congestion loss, and that is | requirements. The limiting case is zero congestion loss, and that is | |||
the goal of Deterministic Networking (DetNet) [RFC8655] and Time- | the goal of DetNet [RFC8655] and Time-Sensitive Networking (TSN) | |||
Sensitive Networking (TSN) [TSN]. In modern optical networks, loss | [TSN]. In modern optical networks, loss due to transmission errors | |||
due to transmission errors already approaches zero, but there is the | already approaches zero, but there is the possibility of failure of | |||
possibility of failure of the interface or the fiber itself. This | the interface or the fiber itself. This type of fault can be | |||
type of fault can be addressed by some form of signal duplication and | addressed by some form of signal duplication and transmission over | |||
transmission over diverse paths. | diverse paths. | |||
Guaranteed maximum latency is required by a number of applications, | Guaranteed maximum latency is required by a number of applications, | |||
particularly real-time control applications and some types of | particularly real-time control applications and some types of | |||
augmented reality and virtual reality (AR/VR) applications. DetNet | augmented reality and virtual reality (AR/VR) applications. DetNet | |||
techniques may be considered [RFC8655]; however, additional methods | techniques may be considered [RFC8655]; however, additional methods | |||
of enhancing the underlay to better support the delay guarantees may | of enhancing the underlay to better support the delay guarantees may | |||
be needed. These methods will need to be integrated with the overall | be needed. These methods will need to be integrated with the overall | |||
service provisioning mechanisms. | service provisioning mechanisms. | |||
Guaranteed maximum delay variation is a performance guarantee that | Guaranteed maximum delay variation is a performance guarantee that | |||
skipping to change at line 499 ¶ | skipping to change at line 497 ¶ | |||
traffic policing or shaping, prioritizing in using shared network | traffic policing or shaping, prioritizing in using shared network | |||
resources, etc., so that a subset of bandwidth, buffers, and queueing | resources, etc., so that a subset of bandwidth, buffers, and queueing | |||
resources can be available in the underlay network to support the | resources can be available in the underlay network to support the | |||
enhanced VPN services. | enhanced VPN services. | |||
To provide the required traffic isolation, or to reduce the | To provide the required traffic isolation, or to reduce the | |||
interaction with other enhanced VPN services, network resources may | interaction with other enhanced VPN services, network resources may | |||
need to be reserved in the data plane of the underlay network and | need to be reserved in the data plane of the underlay network and | |||
dedicated to traffic from a specific enhanced VPN service or a | dedicated to traffic from a specific enhanced VPN service or a | |||
specific group of enhanced VPN services. This may introduce | specific group of enhanced VPN services. This may introduce | |||
scalability concerns both in the implementation (as each enhanced VPN | scalability concerns in the implementation, as each enhanced VPN may | |||
may need to be tracked in the network) and in how many resources need | need to be tracked in the network. It may also introduce scalability | |||
to be reserved and how the services are mapped to the resources | concerns in deployment, such as how many resources need to be | |||
reserved and how the services are mapped to the resources | ||||
(Section 4.4). Thus, some trade-off needs to be considered to | (Section 4.4). Thus, some trade-off needs to be considered to | |||
provide the traffic isolation and limited interaction between an | provide the traffic isolation and limited interaction between an | |||
enhanced VPN service and other services. | enhanced VPN service and other services. | |||
A dedicated physical network can be used to meet stricter SLO and SLE | A dedicated physical network can be used to meet stricter SLO and SLE | |||
requests, at the cost of allocating resources on a long-term and end- | requests, at the cost of allocating resources on a long-term and end- | |||
to-end basis. On the other hand, where adequate traffic isolation | to-end basis. On the other hand, where adequate traffic isolation | |||
and limited interaction can be achieved at the packet layer, this | and limited interaction can be achieved at the packet layer, this | |||
permits the resources to be shared amongst a group of services and | permits the resources to be shared amongst a group of services and | |||
only dedicated to a service on a temporary basis. By combining | only dedicated to a service on a temporary basis. By combining | |||
conventional VPNs with TE/QoS/security techniques, an enhanced VPN | conventional VPNs with TE, QoS, and security techniques, an enhanced | |||
offers a variety of means to honor customer's requirements. | VPN offers a variety of means to honor customer's requirements. | |||
3.3. Integration with Network Resources and Service Functions | 3.3. Integration with Network Resources and Service Functions | |||
The way to achieve the characteristics demand of an enhanced VPN | The way to meet the enhanced VPN service's demand for certain | |||
service (such as guaranteed or predictable performance) is by | characteristics (such as guaranteed or predictable performance) is by | |||
integrating the overlay VPN with a particular set of resources in the | integrating the overlay VPN with a particular set of resources in the | |||
underlay network that are allocated to meet the service requirements. | underlay network that are allocated to meet the service requirements. | |||
This needs to be done in a flexible and scalable way so that it can | This needs to be done in a flexible and scalable way so that it can | |||
be widely deployed in operators' networks to support a good number of | be widely deployed in operators' networks to support a good number of | |||
enhanced VPN services. | enhanced VPN services. | |||
Taking mobile networks and, in particular, 5G into consideration, the | Taking mobile networks and, in particular, 5G into consideration, the | |||
integration of the network with service functions is likely a | integration of the network with service functions is likely a | |||
requirement. The IETF's work on Service Function Chaining (SFC) | requirement. The IETF's work on Service Function Chaining (SFC) | |||
[RFC7665] provides a foundation for this. Service functions in the | [RFC7665] provides a foundation for this. Service functions in the | |||
skipping to change at line 540 ¶ | skipping to change at line 539 ¶ | |||
services, which means the service functions may need to be an | services, which means the service functions may need to be an | |||
integral part of the corresponding NRP. The details of the | integral part of the corresponding NRP. The details of the | |||
integration between service functions and enhanced VPNs are out of | integration between service functions and enhanced VPNs are out of | |||
the scope of this document. | the scope of this document. | |||
3.3.1. Abstraction | 3.3.1. Abstraction | |||
Integration of the overlay VPN and the underlay network resources and | Integration of the overlay VPN and the underlay network resources and | |||
service functions does not always need to be a direct mapping. As | service functions does not always need to be a direct mapping. As | |||
described in [RFC7926], abstraction is the process of applying policy | described in [RFC7926], abstraction is the process of applying policy | |||
to a set of information about a traffic engineered (TE) network to | to a set of information about a traffic-engineered network to produce | |||
produce selective information that represents the potential ability | selective information that represents the potential ability to | |||
to connect across the network. The process of abstraction presents | connect across the network. The process of abstraction presents the | |||
the connectivity graph in a way that is independent of the underlying | connectivity graph in a way that is independent of the underlying | |||
network technologies, capabilities, and topology so that the graph | network technologies, capabilities, and topology so that the graph | |||
can be used to plan and deliver network services in a uniform way. | can be used to plan and deliver network services in a uniform way. | |||
With the approach of abstraction, an enhanced VPN may be built on top | Using the abstraction approach, an enhanced VPN may be built on top | |||
of an abstracted topology that represents the connectivity | of an abstracted topology that represents the connectivity | |||
capabilities of the underlay TE-based network as described in the | capabilities of the underlay TE-based network as described in the | |||
framework for Abstraction and Control of TE Networks (ACTN) [RFC8453] | framework for Abstraction and Control of TE Networks (ACTN) [RFC8453] | |||
as discussed further in Section 5.5. | as discussed further in Section 5.5. | |||
3.4. Dynamic Changes | 3.4. Dynamic Changes | |||
Enhanced VPNs need to be created, modified, and removed from the | Enhanced VPNs need to be created, modified, and removed from the | |||
network according to service demands (including scheduled requests). | network according to service demands (including scheduled requests). | |||
An enhanced VPN that requires limited interaction with other services | An enhanced VPN that requires limited interaction with other services | |||
skipping to change at line 574 ¶ | skipping to change at line 573 ¶ | |||
Dynamic changes both to the enhanced VPN and to the underlay network | Dynamic changes both to the enhanced VPN and to the underlay network | |||
need to be managed to avoid disruption to services that are sensitive | need to be managed to avoid disruption to services that are sensitive | |||
to changes in network performance. | to changes in network performance. | |||
In addition to managing the network without disruption during changes | In addition to managing the network without disruption during changes | |||
such as the inclusion of a new enhanced VPN service endpoint or a | such as the inclusion of a new enhanced VPN service endpoint or a | |||
change to a link, enhanced VPN traffic might need to be moved because | change to a link, enhanced VPN traffic might need to be moved because | |||
of changes to traffic patterns and volume. This means that during | of changes to traffic patterns and volume. This means that during | |||
the lifetime of an enhanced VPN service, closed-loop optimization is | the lifetime of an enhanced VPN service, closed-loop optimization is | |||
needed so that the delivered service always matches the ordered | needed so that the delivered service always matches the ordered SLA. | |||
service SLA. | ||||
The data plane aspects of this problem are discussed further in | The data plane aspects of this problem are discussed further in | |||
Sections 5.1, 5.2, and 5.3. | Sections 5.1, 5.2, and 5.3. | |||
The control plane aspects of this problem are discussed further in | The control plane aspects of this problem are discussed further in | |||
Section 5.4. | Section 5.4. | |||
The management plane aspects of this problem are discussed further in | The management plane aspects of this problem are discussed further in | |||
Section 5.5. | Section 5.5. | |||
skipping to change at line 711 ¶ | skipping to change at line 709 ¶ | |||
- Maps enhanced VPN services to an appropriate NRP. | - Maps enhanced VPN services to an appropriate NRP. | |||
- Determines the risk of SLA violation and takes appropriate | - Determines the risk of SLA violation and takes appropriate | |||
avoidance/correction actions. | avoidance/correction actions. | |||
- Considers the right balance of per-packet and per-node state | - Considers the right balance of per-packet and per-node state | |||
according to the needs of the enhanced VPN services to scale to | according to the needs of the enhanced VPN services to scale to | |||
the required size. | the required size. | |||
* The management plane includes management interfaces, the | * The management plane includes management interfaces, the OAM and | |||
Operations, Administration, and Maintenance (OAM) and telemetry | telemetry mechanisms. More specifically, it provides: | |||
mechanisms. More specifically, it provides: | ||||
- An interface between the enhanced VPN service provider (e.g., | - An interface between the enhanced VPN service provider (e.g., | |||
the operator's network management system) and the enhanced VPN | the operator's network management system) and the enhanced VPN | |||
customer (e.g., an organization or service with an enhanced VPN | customer (e.g., an organization or service with an enhanced VPN | |||
requirement) such that the operation requests and the related | requirement) such that the requests for specific operations and | |||
parameters can be exchanged without the awareness of other | the related parameters can be exchanged without the awareness | |||
enhanced VPN customers. | of other enhanced VPN customers. | |||
- An interface between the enhanced VPN service provider and the | - An interface between the enhanced VPN service provider and the | |||
enhanced VPN customers to expose the network capability | enhanced VPN customers to expose the network capability | |||
information toward the customer. | information toward the customer. | |||
- The service life-cycle management and operation of enhanced VPN | - The service life-cycle management and operation of enhanced VPN | |||
services (e.g., creation, modification, assurance/monitoring, | services (e.g., creation, modification, assurance/monitoring, | |||
and decommissioning). | and decommissioning). | |||
- The OAM tools to verify whether the underlay network resources | - The OAM tools to verify whether the underlay network resources | |||
skipping to change at line 816 ¶ | skipping to change at line 813 ¶ | |||
== Physical Link with resource partition | == Physical Link with resource partition | |||
Figure 1: The Layered Architecture of Enhanced VPNs | Figure 1: The Layered Architecture of Enhanced VPNs | |||
Various components and techniques discussed in Section 5 can be used | Various components and techniques discussed in Section 5 can be used | |||
to enable resource partitioning of the physical network | to enable resource partitioning of the physical network | |||
infrastructure, such as FlexE, TSN, dedicated queues, etc. These | infrastructure, such as FlexE, TSN, dedicated queues, etc. These | |||
partitions may be physical or virtual so long as the SLA required by | partitions may be physical or virtual so long as the SLA required by | |||
the higher layers is met. | the higher layers is met. | |||
Based on the set of network resource partitions provided by the | Based on the set of NRPs provided by the physical network | |||
physical network infrastructure, multiple NRPs can be created. Each | infrastructure, multiple NRPs can be created. Each of these NRPs: | |||
of these NRPs: | ||||
* has a set of dedicated or shared network resources allocated from | * has a set of dedicated or shared network resources allocated from | |||
the physical underlay network, and | the physical underlay network, | |||
* can be associated with a customized logical network topology so as | * can be associated with a customized logical network topology, and | |||
to meet the requirements of different enhanced VPN services or | ||||
* meets the requirements of different enhanced VPN services or | ||||
different groups of enhanced VPN services. | different groups of enhanced VPN services. | |||
According to the associated logical network topology, each NRP needs | According to the associated logical network topology, each NRP needs | |||
to be instantiated on a set of network nodes and links that are | to be instantiated on a set of network nodes and links that are | |||
involved in the logical topology. On each node or link, each NRP is | involved in the logical topology. On each node or link, each NRP is | |||
associated with a set of local resources that are allocated for the | associated with a set of local resources that are allocated for the | |||
processing of traffic in the NRP. The NRP provides the integration | processing of traffic in the NRP. The NRP provides the integration | |||
between the logical network topology and the required underlying | between the logical network topology and the required underlying | |||
network resources. | network resources. | |||
skipping to change at line 928 ¶ | skipping to change at line 925 ¶ | |||
[NRP-SCALABILITY] provides more details of scalability considerations | [NRP-SCALABILITY] provides more details of scalability considerations | |||
for the NRPs used to instantiate NRPs, and Section 7 includes a | for the NRPs used to instantiate NRPs, and Section 7 includes a | |||
greater discussion of scalability considerations. | greater discussion of scalability considerations. | |||
5. Candidate Technologies | 5. Candidate Technologies | |||
A VPN is created by applying a demultiplexing technique to the | A VPN is created by applying a demultiplexing technique to the | |||
underlying network (the underlay) to distinguish the traffic of one | underlying network (the underlay) to distinguish the traffic of one | |||
VPN from that of another. The connections of a VPN are supported by | VPN from that of another. The connections of a VPN are supported by | |||
a set of underlay paths. A path that travels by other than the | a set of underlay paths. Any path other than the shortest path | |||
shortest path through the underlay normally requires state to specify | through the underlay normally requires state to specify that path. | |||
that path. The state of the paths could be applied to the underlay | The state of the paths could be applied to the underlay through the | |||
through the use of the RSVP-TE signaling protocol or directly through | use of the RSVP-TE signaling protocol or directly through the use of | |||
the use of a Software-Defined Networking (SDN) controller. Based on | a Software-Defined Networking (SDN) controller. Based on Segment | |||
Segment Routing (SR), state could be maintained at the ingress node | Routing (SR), state could be maintained at the ingress node of the | |||
of the path and carried in the data packet. Other techniques may | path and carried in the data packet. Other techniques may emerge as | |||
emerge as this problem is studied. This state gets harder to manage | this problem is studied. This state gets harder to manage as the | |||
as the number of paths increases. Furthermore, as we increase the | number of paths increases. Furthermore, as we increase the coupling | |||
coupling between the underlay and the overlay to support the enhanced | between the underlay and the overlay to support the enhanced VPN | |||
VPN service, this state is likely to increase further. Through the | service, this state is likely to increase further. Through the use | |||
use of NRP, a subset of underlay network resources can be either | of NRP, a subset of underlay network resources can be either | |||
dedicated for a particular enhanced VPN service or shared among a | dedicated for a particular enhanced VPN service or shared among a | |||
group of enhanced VPN services. A group of underlay paths can be | group of enhanced VPN services. A group of underlay paths can be | |||
established using the common set of network resources of the NRP. | established using the common set of network resources of the NRP. | |||
This section describes the candidate technologies and examines them | This section describes the candidate technologies and examines them | |||
in the context of the different network planes that may be used | in the context of the different network planes that may be used | |||
together to build NRPs. Section 5.1 discusses the L2 packet-based or | together to build NRPs. Section 5.1 discusses the L2 packet-based or | |||
frame-based forwarding-plane mechanisms for resource partitioning. | frame-based forwarding-plane mechanisms for resource partitioning. | |||
Section 5.2 discusses the corresponding encapsulation and forwarding | Section 5.2 discusses the corresponding encapsulation and forwarding | |||
mechanisms in the network layer. Non-packet data plane mechanisms | mechanisms in the network layer. Non-packet data plane mechanisms | |||
are briefly discussed in Section 5.3. The control plane and | are briefly discussed in Section 5.3. The control plane and | |||
management plane mechanisms are discussed in Sections 5.4 and 5.5, | management plane mechanisms are discussed in Sections 5.4 and 5.5, | |||
respectively. | respectively. | |||
5.1. Underlay Forwarding Resource Partitioning | 5.1. Underlay Forwarding Resource Partitioning | |||
Several candidate L2 packet-based or frame-based forwarding-plane | Several candidate L2 packet-based or frame-based forwarding-plane | |||
mechanisms that can provide the required traffic isolation and | mechanisms that can provide the required traffic isolation and | |||
performance guarantees are described in the following sections. | performance guarantees are described in the following sections. | |||
5.1.1. Flexible Ethernet | 5.1.1. Flex Ethernet | |||
FlexE [FLEXE] provides the ability to multiplex channels over an | FlexE [FLEXE] provides the ability to multiplex channels over an | |||
Ethernet link to create point-to-point fixed-bandwidth connections in | Ethernet link to create point-to-point fixed-bandwidth connections in | |||
a way that provides separation between enhanced VPN services. FlexE | a way that provides separation between enhanced VPN services. FlexE | |||
also supports bonding links to create larger links out of multiple | also supports bonding multiple low-capacity links to create larger | |||
low-capacity links. | links. | |||
However, FlexE is only a link-level technology. When packets are | However, FlexE is only a link-level technology. When packets are | |||
received by the downstream node, they need to be processed in a way | received by the downstream node, they need to be processed in a way | |||
that preserves that traffic isolation in the downstream node. In | that preserves traffic isolation. In turn, this requires a queuing | |||
turn, this requires a queuing and forwarding implementation that | and forwarding implementation that preserves the end-to-end | |||
preserves the end-to-end separation of enhanced VPNs. | separation of enhanced VPNs. | |||
If different FlexE channels are used for different services, then no | If different FlexE channels are used for different services, then no | |||
sharing is possible between the FlexE channels. Thus, it may be | sharing is possible between the FlexE channels. Thus, it may be | |||
difficult to dynamically redistribute unused bandwidth to lower | difficult to dynamically redistribute unused bandwidth to lower | |||
priority services in another FlexE channel. If one FlexE channel is | priority services in another FlexE channel. If one FlexE channel is | |||
used by one customer, the customer can use some methods to manage the | used by one customer, the customer can use some methods to manage the | |||
relative priority of their own traffic in the FlexE channel. | relative priority of their own traffic in the FlexE channel. | |||
5.1.2. Dedicated Queues | 5.1.2. Dedicated Queues | |||
skipping to change at line 1019 ¶ | skipping to change at line 1016 ¶ | |||
packet scheduling where a packet stream may be given a time slot | packet scheduling where a packet stream may be given a time slot | |||
guaranteeing that it will experience no queuing delay or increase in | guaranteeing that it will experience no queuing delay or increase in | |||
latency beyond a very small scheduling delay. The mechanisms defined | latency beyond a very small scheduling delay. The mechanisms defined | |||
in TSN can be used to meet the requirements of time-sensitive traffic | in TSN can be used to meet the requirements of time-sensitive traffic | |||
flows of enhanced VPN service. | flows of enhanced VPN service. | |||
Ethernet can be emulated over a L3 network using an IP or MPLS | Ethernet can be emulated over a L3 network using an IP or MPLS | |||
pseudowire. However, a TSN Ethernet payload would be opaque to the | pseudowire. However, a TSN Ethernet payload would be opaque to the | |||
underlay; thus, it would not be treated specifically as time- | underlay; thus, it would not be treated specifically as time- | |||
sensitive data. The preferred method of carrying TSN over a L3 | sensitive data. The preferred method of carrying TSN over a L3 | |||
network is through the use of deterministic networking as explained | network is through the use of DetNet as explained in Section 5.2.1. | |||
in Section 5.2.1. | ||||
5.2. Network Layer Encapsulation and Forwarding | 5.2. Network Layer Encapsulation and Forwarding | |||
This section considers the problem of enhanced VPN service | This section considers the problem of enhanced VPN service | |||
differentiation and the representation of underlying network | differentiation and the representation of underlying network | |||
resources in the network layer. More specifically, it describes the | resources in the network layer. More specifically, it describes the | |||
possible data plane mechanisms to determine the network resources and | possible data plane mechanisms to determine the network resources and | |||
the logical network topology or paths associated with an NRP. | the logical network topology or paths associated with an NRP. | |||
5.2.1. Deterministic Networking (DetNet) | 5.2.1. Deterministic Networking (DetNet) | |||
skipping to change at line 1056 ¶ | skipping to change at line 1052 ¶ | |||
MPLS-TE (see [RFC2702] and [RFC3209]) introduces the concept of | MPLS-TE (see [RFC2702] and [RFC3209]) introduces the concept of | |||
reserving end-to-end bandwidth for a TE-LSP, which can be used to | reserving end-to-end bandwidth for a TE-LSP, which can be used to | |||
provide a set of point-to-point resource-reserved paths across the | provide a set of point-to-point resource-reserved paths across the | |||
underlay network to support VPN services. VPN traffic can be carried | underlay network to support VPN services. VPN traffic can be carried | |||
over dedicated TE-LSPs to provide guaranteed bandwidth for each | over dedicated TE-LSPs to provide guaranteed bandwidth for each | |||
specific connection in a VPN, and VPNs with similar behavior | specific connection in a VPN, and VPNs with similar behavior | |||
requirements may be multiplexed onto the same TE-LSPs. Some network | requirements may be multiplexed onto the same TE-LSPs. Some network | |||
operators have concerns about the scalability and management overhead | operators have concerns about the scalability and management overhead | |||
of MPLS-TE system, especially with regard to those systems that use | of MPLS-TE system, especially with regard to those systems that use | |||
an active control plane, and this has lead them to consider other | an active control plane, and this has lead them to consider other | |||
solutions for traffic engineering in their networks. | solutions for TE in their networks. | |||
5.2.3. Segment Routing | 5.2.3. Segment Routing | |||
Segment Routing (SR) [RFC8402] is a method that prepends instructions | SR [RFC8402] is a method that prepends instructions to packets at the | |||
to packets at the headend of a path. These instructions are used to | headend of a path. These instructions are used to specify the nodes | |||
specify the nodes and links to be traversed, and they allow the | and links to be traversed, and they allow the packets to be routed on | |||
packets to be routed on paths other than the shortest path. By | paths other than the shortest path. By encoding the state in the | |||
encoding the state in the packet, per-path state is transitioned out | packet, per-path state is transitioned out of the network. SR can be | |||
of the network. SR can be instantiated using the MPLS data plane | instantiated using the MPLS data plane (SR-MPLS) (see [RFC8660]) or | |||
(SR-MPLS) (see [RFC8660]) or the IPv6 data plane (SRv6) (see | the IPv6 data plane (SRv6) (see [RFC8986]). | |||
[RFC8986]). | ||||
An SR traffic engineered path operates with the granularity of a | An SR traffic-engineered path operates with the granularity of a | |||
link. Hints about priority are provided using the Traffic Class (TC) | link. Hints about priority are provided using the Traffic Class (TC) | |||
field in the packet header. However, to achieve the performance and | field in the packet header. However, to achieve the performance and | |||
isolation characteristics that are sought by enhanced VPN customers, | isolation characteristics that are sought by enhanced VPN customers, | |||
it will be necessary to steer packets through specific virtual links | it will be necessary to steer packets through specific virtual links | |||
and/or queues on the same link and direct them to use specific | and/or queues on the same link and direct them to use specific | |||
resources. With SR, it is possible to introduce such fine-grained | resources. With SR, it is possible to introduce such fine-grained | |||
packet steering by specifying the queues and the associated resources | packet steering by specifying the queues and the associated resources | |||
through an SR instruction list. One approach to do this is described | through an SR instruction list. One approach to do this is described | |||
in [RESOURCE-AWARE-SEGMENTS]. | in [RESOURCE-AWARE-SEGMENTS]. | |||
Note that the concept of a queue is a useful abstraction for | Note that the concept of a queue is a useful abstraction for | |||
different types of underlay mechanisms that may be used to provide | different types of underlay mechanisms that may be used to provide | |||
enhanced isolation and performance support. How the queue satisfies | enhanced isolation and performance support. How the queue satisfies | |||
the requirement is implementation specific and is transparent to the | the requirement is implementation specific and is transparent to the | |||
L3 data plane and control plane mechanisms used. | L3 data plane and control plane mechanisms used. | |||
With Segment Routing, the SR instruction list could be used to build | With SR, the SR instruction list could be used to build a P2P SR | |||
a P2P SR path. In addition, a group of SR Segment Identifiers (SIDs) | path. In addition, a group of SR Segment Identifiers (SIDs) could | |||
could also be used to represent an MP2MP network. Thus, the SR-based | also be used to represent an MP2MP network. Thus, the SR-based | |||
mechanism could be used to provide both resource-reserved paths and | mechanism could be used to provide both resource-reserved paths and | |||
NRPs for enhanced VPN services. | NRPs for enhanced VPN services. | |||
5.2.4. New Encapsulation Extensions | 5.2.4. New Encapsulation Extensions | |||
In contrast to reusing an existing data plane for enhanced VPN, | In contrast to reusing an existing data plane for enhanced VPN, | |||
another possible approach is to introduce new encapsulations or | another possible approach is to introduce new encapsulations or | |||
extensions to an existing data plane to allow dedicated identifiers | extensions to an existing data plane to allow dedicated identifiers | |||
for the underlay network resources of an enhanced VPN and the logical | for the underlay network resources of an enhanced VPN and the logical | |||
network topology or paths associated with an enhanced VPN. This may | network topology or paths associated with an enhanced VPN. This may | |||
skipping to change at line 1131 ¶ | skipping to change at line 1126 ¶ | |||
The cost is that the resources are allocated on a long-term and end- | The cost is that the resources are allocated on a long-term and end- | |||
to-end basis. Such an arrangement means that the full cost of the | to-end basis. Such an arrangement means that the full cost of the | |||
resources has to be borne by the client to which the resources are | resources has to be borne by the client to which the resources are | |||
allocated. When an NRP built with this data plane is used to support | allocated. When an NRP built with this data plane is used to support | |||
multiple enhanced VPN services, the cost could be distributed among | multiple enhanced VPN services, the cost could be distributed among | |||
such a group of services. | such a group of services. | |||
5.4. Control Plane | 5.4. Control Plane | |||
The control plane of NRP-based enhanced VPNs is likely to be based on | The control plane of NRP-based enhanced VPNs is likely be based on a | |||
a hybrid control mechanism that takes advantage of a logically | hybrid control mechanism that takes advantage of a logically | |||
centralized controller for on-demand provisioning and Global | centralized controller for on-demand provisioning and global | |||
Concurrent Optimization (GCO) while still relying on a distributed | optimization while still relying on a distributed control plane to | |||
control plane to provide scalability, high reliability, fast | provide scalability, high reliability, fast reaction, automatic | |||
reaction, automatic failure recovery, etc. Extension to and | failure recovery, etc. Extension to and optimization of the | |||
optimization of the centralized and distributed control plane is | centralized and distributed control plane is needed to support the | |||
needed to support the enhanced properties of an NRP-based enhanced | enhanced properties of an NRP-based enhanced VPN. | |||
VPN. | ||||
As described in Section 4, the enhanced VPN control plane needs to | As described in Section 4, the enhanced VPN control plane needs to | |||
provide the following functions: | provide the following functions: | |||
* Collection of information about the underlying network topology | * Collection of information about the underlying network topology | |||
and network resources and exportation of this to network nodes | and network resources and exportation of this to network nodes | |||
and/or a centralized controller as required. | and/or a centralized controller as required. | |||
* Creation of NRPs with the network resource and topology properties | * Creation of NRPs with the network resource and topology properties | |||
needed by NRP-based enhanced VPN services. | needed by NRP-based enhanced VPN services. | |||
skipping to change at line 1169 ¶ | skipping to change at line 1163 ¶ | |||
Underlying network topology and resource information can be collected | Underlying network topology and resource information can be collected | |||
using mechanisms based on the existing IGP and Border Gateway | using mechanisms based on the existing IGP and Border Gateway | |||
Protocol - Link State (BGP-LS) [RFC9552]. The creation of NRPs and | Protocol - Link State (BGP-LS) [RFC9552]. The creation of NRPs and | |||
the distribution of NRP attributes may need further control protocol | the distribution of NRP attributes may need further control protocol | |||
extensions. The computation of service paths based on the attributes | extensions. The computation of service paths based on the attributes | |||
and constraints of the NRP can be performed either by the headend | and constraints of the NRP can be performed either by the headend | |||
node of the path or by a centralized Path Computation Element (PCE) | node of the path or by a centralized Path Computation Element (PCE) | |||
[RFC4655]. | [RFC4655]. | |||
Two candidate control plane mechanisms for path setup in the NRP are | Two candidate control plane mechanisms for path setup in the NRP are | |||
RSVP-TE and Segment Routing (SR). | RSVP-TE and SR. | |||
* RSVP-TE, as described in [RFC3209], provides the signaling | * RSVP-TE, as described in [RFC3209], provides the signaling | |||
mechanism for establishing a TE-LSP in an MPLS network with end- | mechanism for establishing a TE-LSP in an MPLS network with end- | |||
to-end resource reservation. This can be seen as an approach of | to-end resource reservation. This can be seen as an approach of | |||
providing resource-reserved paths that could be used to bind the | providing resource-reserved paths that could be used to bind the | |||
VPN to a specific set of network resources allocated within the | VPN to a specific set of network resources allocated within the | |||
underlay; however, there remain scalability concerns, as mentioned | underlay; however, there remain scalability concerns, as mentioned | |||
in Section 5.2.2. | in Section 5.2.2. | |||
* The SR control plane, as described in [RFC8665], [RFC8667], and | * The SR control plane, as described in [RFC8665], [RFC8667], and | |||
skipping to change at line 1214 ¶ | skipping to change at line 1208 ¶ | |||
models for the description of the information and operations needed | models for the description of the information and operations needed | |||
on the interface. | on the interface. | |||
As an example, in the context of 5G end-to-end network slicing | As an example, in the context of 5G end-to-end network slicing | |||
[TS28530], the management of the transport network segment of the 5G | [TS28530], the management of the transport network segment of the 5G | |||
end-to-end network slice can be realized with the management plane of | end-to-end network slice can be realized with the management plane of | |||
the enhanced VPN. The 3GPP management system may provide the | the enhanced VPN. The 3GPP management system may provide the | |||
connectivity and performance-related parameters as requirements to | connectivity and performance-related parameters as requirements to | |||
the management plane of the transport network. It may also require | the management plane of the transport network. It may also require | |||
the transport network to expose the capabilities and status of the | the transport network to expose the capabilities and status of the | |||
network slice. Thus, an interface between the enhanced VPN | network slice. Thus, the coordination of 5G end-to-end network slice | |||
management plane and the 5G network slice management system, and | management requires an interface between the enhanced VPN management | |||
relevant service data models are needed for the coordination of 5G | plane and the 5G network slice management system, and relevant | |||
end-to-end network slice management. | service data models. | |||
The management plane interface and data models for enhanced VPN | The management plane interface and data models for enhanced VPN | |||
services can be based on the service models described in Section 5.6. | services can be based on the service models described in Section 5.6. | |||
It is important that the life-cycle management support in-place | It is important that the life-cycle management support in-place | |||
modification of enhanced VPN services. That is, it should be | modification of enhanced VPN services. That is, it should be | |||
possible to add and remove endpoints, as well as to change the | possible to add and remove endpoints, as well as to change the | |||
requested characteristics of the service that is delivered. The | requested characteristics of the service that is delivered. The | |||
management system needs to be able to assess the revised enhanced VPN | management system needs to be able to assess the revised enhanced VPN | |||
requests and determine whether they can be provided by the existing | requests and determine whether they can be provided by the existing | |||
skipping to change at line 1276 ¶ | skipping to change at line 1270 ¶ | |||
progress service data models to enhanced VPNs. [RFC8309] describes | progress service data models to enhanced VPNs. [RFC8309] describes | |||
the scope and purpose of service models and shows where a service | the scope and purpose of service models and shows where a service | |||
model might fit into an SDN-based network management architecture. | model might fit into an SDN-based network management architecture. | |||
New service models may also be introduced for some of the required | New service models may also be introduced for some of the required | |||
management functions. | management functions. | |||
Service data models are used to represent, monitor, and manage the | Service data models are used to represent, monitor, and manage the | |||
virtual networks and services enabled by enhanced VPNs. The VPN | virtual networks and services enabled by enhanced VPNs. The VPN | |||
customer service models (e.g., the L3VPN Service Model (L3SM) in | customer service models (e.g., the L3VPN Service Model (L3SM) in | |||
[RFC8299], the L2VPN Service Model (L2SM) in [RFC8466]), or the ACTN | [RFC8299], the L2VPN Service Model (L2SM) in [RFC8466]), or the ACTN | |||
Virtual Network (VN) model in [RFC9731]) are service models that can | VN model in [RFC9731]) are service models that can provide the | |||
provide the customer's view of the enhanced VPN service. The L3VPN | customer's view of the enhanced VPN service. The L3VPN Network Model | |||
Network Model (L3NM) from [RFC9182] and the L2VPN Network Model | (L3NM) from [RFC9182] and the L2VPN Network Model (L2NM) from | |||
(L2NM) from [RFC9291] provide the operator's view of the managed | [RFC9291] provide the operator's view of the managed infrastructure | |||
infrastructure as a set of virtual networks and the associated | as a set of virtual networks and the associated resources. The | |||
resources. The Service Attachment Points (SAPs) model in [RFC9408] | Service Attachment Points (SAPs) model in [RFC9408] provides an | |||
provides an abstract view of the Service Attachment Points (SAPs) to | abstract view of the SAPs to various network services in the provider | |||
various network services in the provider network, where enhanced VPN | network, where enhanced VPN could be one of the service types. | |||
could be one of the service types. [RFC9375] provides the data model | [RFC9375] provides the data model for performance monitoring of | |||
for performance monitoring of network and VPN services. Augmentation | network and VPN services. Augmentation to these service models may | |||
to these service models may be needed to provide the enhanced VPN | be needed to provide the enhanced VPN services. The NRP model in | |||
services. The NRP model in [NRP-YANG] further provides the | [NRP-YANG] further provides the management of the NRP topology and | |||
management of the NRP topology and resources both in the controller | resources both in the controller and in the network devices to | |||
and in the network devices to instantiate the NRPs needed for the | instantiate the NRPs needed for the enhanced VPN services. | |||
enhanced VPN services. | ||||
6. Applicability in Network Slice Realization | 6. Applicability in Network Slice Realization | |||
This section describes the applicability of NRP-based enhanced VPN | This section describes the applicability of NRP-based enhanced VPN | |||
for network slice realization. | for network slice realization. | |||
In order to provide network slice services to customers, a | In order to provide network slice services to customers, a | |||
technology-agnostic network slice service model [NETWORK-SLICE-YANG] | technology-agnostic network slice service model [NETWORK-SLICE-YANG] | |||
is needed for the customers to communicate the requirements of | is needed for the customers to communicate the requirements of | |||
network slices (SDPs, connectivity, SLOs, and SLEs). These | network slices (SDPs, connectivity, SLOs, and SLEs). These | |||
skipping to change at line 1416 ¶ | skipping to change at line 1409 ¶ | |||
path. This is more network state than is needed using SR, but the | path. This is more network state than is needed using SR, but the | |||
packets are usually shorter. | packets are usually shorter. | |||
* by providing a hybrid approach. One example is based on using | * by providing a hybrid approach. One example is based on using | |||
binding SIDs (see [RFC8402]) to represent path fragments and | binding SIDs (see [RFC8402]) to represent path fragments and | |||
binding them together with SR. Dynamic creation of a VPN service | binding them together with SR. Dynamic creation of a VPN service | |||
path using SR requires less state maintenance in the network core | path using SR requires less state maintenance in the network core | |||
at the expense of larger packet headers. The packet size can be | at the expense of larger packet headers. The packet size can be | |||
lower if a form of loose source routing is used (using a few nodal | lower if a form of loose source routing is used (using a few nodal | |||
SIDs), and it will be lower if no specific functions or resources | SIDs), and it will be lower if no specific functions or resources | |||
on the routers are specified. For SRv6, the packet size may also | on the routers are specified. For Segment Routing over IPv6 | |||
be reduced by utilizing the compression techniques specified in | (SRv6), the packet size may also be reduced by utilizing the | |||
[SRv6-SRH-COMPRESSION]. | compression techniques specified in [SRv6-SRH-COMPRESSION]. | |||
Reducing state in the network is important to enhanced VPNs, as it | Reducing the state in the network is important to the deployment of | |||
requires the overlay to be more closely integrated with the underlay | enhanced VPNs, as they require the overlay to be more closely | |||
than with conventional VPNs. This tighter coupling would normally | integrated with the underlay than with conventional VPNs. This | |||
mean that more state needs to be created and maintained in the | tighter coupling would normally mean that more state needs to be | |||
network, as state about fine-granularity processing would need to be | created and maintained in the network, as state about fine- | |||
loaded and maintained in the routers. Aggregation is a well- | granularity processing would need to be loaded and maintained in the | |||
established approach to reduce the amount of state and improve | routers. Aggregation is a well-established approach to reduce the | |||
scaling, and NRP is considered to be the network construct to | amount of state and improve scaling, and NRP is considered to be the | |||
aggregate the states of enhanced VPN services. In addition, an SR | network construct to aggregate the states of enhanced VPN services. | |||
approach allows much of the state to be spread amongst the network | In addition, an SR approach allows much of the state to be spread | |||
ingress nodes and transiently carried in the packets as SIDs. | amongst the network ingress nodes and transiently carried in the | |||
packets as SIDs. | ||||
The following subsections describe some of the scalability concerns | The following subsections describe some of the scalability concerns | |||
that need to be considered. Further discussion of the scalability | that need to be considered. Further discussion of the scalability | |||
considerations of the underlaying network constructs of NRP-based | considerations of the underlaying network constructs of NRP-based | |||
enhanced VPNs can be found in [NRP-SCALABILITY]. | enhanced VPNs can be found in [NRP-SCALABILITY]. | |||
7.1. Maximum Stack Depth of SR | 7.1. Maximum Stack Depth of SR | |||
One of the challenges with SR is the stack depth that nodes are able | One of the challenges with SR is the stack depth that nodes are able | |||
to impose on packets [RFC8491]. This leads to a difficult balance | to impose on packets [RFC8491]. This leads to a difficult balance | |||
skipping to change at line 1461 ¶ | skipping to change at line 1455 ¶ | |||
maintenance in the network. Work to improve the scalability of RSVP- | maintenance in the network. Work to improve the scalability of RSVP- | |||
TE LSPs in the control plane can be found in [RFC8370]. | TE LSPs in the control plane can be found in [RFC8370]. | |||
There is also concern at the scalability of the forwarder footprint | There is also concern at the scalability of the forwarder footprint | |||
of RSVP-TE as the number of paths through a Label Switching Router | of RSVP-TE as the number of paths through a Label Switching Router | |||
(LSR) grows. [RFC8577] addresses this by employing SR within a | (LSR) grows. [RFC8577] addresses this by employing SR within a | |||
tunnel established by RSVP-TE. | tunnel established by RSVP-TE. | |||
7.3. SDN Scaling | 7.3. SDN Scaling | |||
The centralized approach of SDN requires control plane state to be | The centralized SDN-based approach requires control plane state to be | |||
stored in the network, but can reduce the overhead of control | stored in the network, but can reduce the overhead of control | |||
channels to be maintained. Each individual network node may need to | channels to be maintained. Each individual network node may need to | |||
maintain a control channel with an SDN controller, which is | maintain a control channel with an SDN controller, which is | |||
considered more scalable compared to the need of maintaining control | considered more scalable compared to the need of maintaining control | |||
channels with a set of neighbor nodes. | channels with a set of neighbor nodes. | |||
However, SDN may transfer some of the scalability concerns from the | However, SDN may transfer some of the scalability concerns from the | |||
network to a centralized controller. In particular, there may be a | network to a centralized controller. In particular, there may be a | |||
heavy processing burden at the controller and a heavy load in the | heavy processing burden at the controller and a heavy load in the | |||
network surrounding the controller. A centralized controller may | network surrounding the controller. A centralized controller may | |||
skipping to change at line 1492 ¶ | skipping to change at line 1486 ¶ | |||
Systems in which the path is imposed, such as SR or some form of | Systems in which the path is imposed, such as SR or some form of | |||
explicit routing, tend to do well in these applications because it is | explicit routing, tend to do well in these applications because it is | |||
possible to perform an atomic transition from one path to another. | possible to perform an atomic transition from one path to another. | |||
That is, a single action by the headend that changes the path without | That is, a single action by the headend that changes the path without | |||
the need for coordinated action by the routers along the path. | the need for coordinated action by the routers along the path. | |||
However, implementations and the monitoring protocols need to make | However, implementations and the monitoring protocols need to make | |||
sure that the new path is operational and meets the required SLA | sure that the new path is operational and meets the required SLA | |||
before traffic is transitioned to it. It is possible for deadlocks | before traffic is transitioned to it. It is possible for deadlocks | |||
to arise as a result of the network becoming fragmented over time, | to arise as a result of the network becoming fragmented over time, | |||
such that it is impossible to create a new path or to modify an | such that it is impossible to create a new path or to modify an | |||
existing path without impacting the SLA of other paths. The GCO | existing path without impacting the SLA of other paths. The global | |||
mechanisms as described in [RFC5557] and discussed in [RFC7399] may | concurrent optimization mechanisms as described in [RFC5557] and | |||
be helpful, while complete resolution of this situation is as much a | discussed in [RFC7399] may be helpful, while complete resolution of | |||
commercial issue as it is a technical issue. | this situation is as much a commercial issue as it is a technical | |||
issue. | ||||
However, there are two manifestations of the latency problem that are | However, there are two manifestations of the latency problem that are | |||
for further study in any of these approaches: | for further study in any of these approaches: | |||
* Packets overtaking one another if path latency reduces during a | * Packets overtaking one another if path latency reduces during a | |||
transition. | transition. | |||
* Transient variation in latency in either direction as a path | * Transient variation in latency in either direction as a path | |||
migrates. | migrates. | |||
skipping to change at line 1537 ¶ | skipping to change at line 1532 ¶ | |||
This section describes the considerations about the OAM and telemetry | This section describes the considerations about the OAM and telemetry | |||
mechanisms used to support the verification, monitoring, and | mechanisms used to support the verification, monitoring, and | |||
optimization of the characteristics and SLA fulfillment of NRP-based | optimization of the characteristics and SLA fulfillment of NRP-based | |||
enhanced VPN services. It should be read along with Section 5.5, | enhanced VPN services. It should be read along with Section 5.5, | |||
which gives consideration to the management plane techniques that can | which gives consideration to the management plane techniques that can | |||
be used to build NRPs. | be used to build NRPs. | |||
9.1. OAM Considerations | 9.1. OAM Considerations | |||
The design of OAM for enhanced VPN services needs to consider the | The following requirements need to be considered in the design of OAM | |||
following requirements: | for enhanced VPN services: | |||
* Instrumentation of the NRP (the virtual underlay) so that the | * Instrumentation of the NRP (the virtual underlay) so that the | |||
network operator can be sure that the resources committed to a | network operator can be sure that the resources committed to a | |||
customer are operating correctly and delivering the required | customer are operating correctly and delivering the required | |||
performance. It is important that the OAM packets follow the same | performance. It is important that the OAM packets follow the same | |||
path and set of resources as the service packets mapped to the | path and set of resources as the service packets mapped to the | |||
NRP. | NRP. | |||
* Instrumentation of the overlay by the customer. This is likely to | * Instrumentation of the overlay by the customer. This is likely to | |||
be transparent to the network operator and to use existing | be transparent to the network operator and to use existing | |||
skipping to change at line 1573 ¶ | skipping to change at line 1568 ¶ | |||
telemetry has been considered to be an ideal means to gain sufficient | telemetry has been considered to be an ideal means to gain sufficient | |||
network visibility with better flexibility, scalability, accuracy, | network visibility with better flexibility, scalability, accuracy, | |||
coverage, and performance than conventional OAM technologies. | coverage, and performance than conventional OAM technologies. | |||
As defined in [RFC9232], the objective of network telemetry is to | As defined in [RFC9232], the objective of network telemetry is to | |||
acquire network data remotely for network monitoring and operation. | acquire network data remotely for network monitoring and operation. | |||
It is a general term for a large set of network visibility techniques | It is a general term for a large set of network visibility techniques | |||
and protocols. Network telemetry addresses the current network | and protocols. Network telemetry addresses the current network | |||
operation issues and enables smooth evolution toward intent-driven | operation issues and enables smooth evolution toward intent-driven | |||
autonomous networks. Telemetry can be applied on the forwarding | autonomous networks. Telemetry can be applied on the forwarding | |||
plane, the control plane, and the management plane in a network. | plane, the control plane, and the management plane in a network. The | |||
Telemetry for enhanced VPN service needs to consider the following | following requirements need to be considered for telemetry for | |||
requirements: | enhanced VPN service: | |||
* Collecting data of NRPs for overall performance evaluation and the | * Collecting data of NRPs for overall performance evaluation and the | |||
planning of the enhanced VPN services. | planning of the enhanced VPN services. | |||
* Collecting data of each enhanced VPN service for monitoring and | * Collecting data of each enhanced VPN service for monitoring and | |||
analytics of the service characteristics and SLA fulfillment. | analytics of the service characteristics and SLA fulfillment. | |||
How the telemetry mechanisms could be used or extended for enhanced | How the telemetry mechanisms could be used or extended for enhanced | |||
VPN services is out of the scope of this document. | VPN services is out of the scope of this document. | |||
skipping to change at line 1675 ¶ | skipping to change at line 1670 ¶ | |||
"Carrying Network Resource (NR) related Information in | "Carrying Network Resource (NR) related Information in | |||
IPv6 Extension Header", Work in Progress, Internet-Draft, | IPv6 Extension Header", Work in Progress, Internet-Draft, | |||
draft-ietf-6man-enhanced-vpn-vtn-id-09, 3 November 2024, | draft-ietf-6man-enhanced-vpn-vtn-id-09, 3 November 2024, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-6man- | <https://datatracker.ietf.org/doc/html/draft-ietf-6man- | |||
enhanced-vpn-vtn-id-09>. | enhanced-vpn-vtn-id-09>. | |||
[NETWORK-SLICE-YANG] | [NETWORK-SLICE-YANG] | |||
Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly, | Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly, | |||
"A YANG Data Model for the RFC 9543 Network Slice | "A YANG Data Model for the RFC 9543 Network Slice | |||
Service", Work in Progress, Internet-Draft, draft-ietf- | Service", Work in Progress, Internet-Draft, draft-ietf- | |||
teas-ietf-network-slice-nbi-yang-20, 27 January 2025, | teas-ietf-network-slice-nbi-yang-22, 8 February 2025, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- | <https://datatracker.ietf.org/doc/html/draft-ietf-teas- | |||
ietf-network-slice-nbi-yang-20>. | ietf-network-slice-nbi-yang-22>. | |||
[NGMN-NS-Concept] | [NGMN-NS-Concept] | |||
hao ,, "NGMN NS Concept", <https://www.ngmn.org/fileadmin/ | NGMN Alliance, "NGMN 5G P1 Requirements and Architecture | |||
user_upload/161010_NGMN_Network_Slicing_framework_v1.0.8.p | Work Stream End-to-End Architecture: Description of | |||
df>. | Network Slicing Concept", Version 1.0.8 (draft), 14 | |||
September 2016, <https://www.ngmn.org/wp-content/uploads/P | ||||
ublications/2016/161010_NGMN_Network_Slicing_framework_v1. | ||||
0.8.pdf>. | ||||
[NRP-SCALABILITY] | [NRP-SCALABILITY] | |||
Dong, J., Li, Z., Gong, L., Yang, G., and G. S. Mishra, | Dong, J., Li, Z., Gong, L., Yang, G., and G. S. Mishra, | |||
"Scalability Considerations for Network Resource | "Scalability Considerations for Network Resource | |||
Partition", Work in Progress, Internet-Draft, draft-ietf- | Partition", Work in Progress, Internet-Draft, draft-ietf- | |||
teas-nrp-scalability-06, 21 October 2024, | teas-nrp-scalability-06, 21 October 2024, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- | <https://datatracker.ietf.org/doc/html/draft-ietf-teas- | |||
nrp-scalability-06>. | nrp-scalability-06>. | |||
[NRP-YANG] Wu, B., Dhody, D., Beeram, V. P., Saad, T., and S. Peng, | [NRP-YANG] Wu, B., Dhody, D., Beeram, V. P., Saad, T., and S. Peng, | |||
End of changes. 43 change blocks. | ||||
147 lines changed or deleted | 145 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |