Discovery of Network Rate-Limit Policies (NRLPs)
draft-brw-scone-rate-policy-discovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Mohamed Boucadair , Dan Wing , Tirumaleswar Reddy.K , Sridharan Rajagopalan , Gyan Mishra , Markus Amend , Luis M. Contreras | ||
| Last updated | 2024-10-09 (Latest revision 2024-10-08) | ||
| Replaces | draft-brw-sconepro-rate-policy-discovery | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-brw-scone-rate-policy-discovery-00
scone M. Boucadair
Internet-Draft Orange
Intended status: Standards Track D. Wing
Expires: 11 April 2025 Cloud Software Group
T. Reddy
Nokia
S. Rajagopalan
Cloud Software Group
G. Mishra
Verizon Inc
M. Amend
Deutsche Telekom
L. Contreras
Telefonica
8 October 2024
Discovery of Network Rate-Limit Policies (NRLPs)
draft-brw-scone-rate-policy-discovery-00
Abstract
Traffic exchanged over a network attachment may be subject to rate-
limit policies. These policies may be intentional policies (e.g.,
enforced as part of the activation of the network attachment and
typically agreed upon service subscription) or be reactive policies
(e.g., enforced temporarily to manage an overload or during a DDoS
attack mitigation). This document specifies a mechanims for hosts to
dynamically discover Network Rate-Limit Policies (NRLPs). This
information is then passed to applicaitons that might adjust their
behaviors accordingly.
Networks already support mechanisms to advertize a set of network
properties to hosts using Neighbor Discovery options. Examples of
such properties are link MTU (RFC 4861) and PREFIX64 (RFC 8781).
This document complements these tools and specifies a Neighbor
Discovery option to be used in Router Advertisements (RAs) to
communicate these policies to hosts. For address family parity, a
new DHCP option is also defined. The document also discusses how
Provisioning Domains (PvD) can be used to notify hosts with NRLPs.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/boucadair/draft-xxx-ac-rate-policy-discovery.
Boucadair, et al. Expires 11 April 2025 [Page 1]
Internet-Draft Rate-Limit Policies Discovery October 2024
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Networks Are Already Sharing Network Properties with
Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. What's In? . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. What's Out? . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Design Motivation & Rationale . . . . . . . . . . . . . . 7
1.6. Sample Deployment Cases . . . . . . . . . . . . . . . . . 9
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 10
3. NRLP Blob . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. IPv6 RA NRLP Option . . . . . . . . . . . . . . . . . . . . . 13
4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 13
4.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 15
5. DHCP NRLP Option . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 16
Boucadair, et al. Expires 11 April 2025 [Page 2]
Internet-Draft Rate-Limit Policies Discovery October 2024
5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 18
6. Provisioning Domains . . . . . . . . . . . . . . . . . . . . 19
7. Operational Considerations . . . . . . . . . . . . . . . . . 19
7.1. NRLP Is Complementary Not Replacement Solution . . . . . 19
7.2. Provisionning Policies . . . . . . . . . . . . . . . . . 19
7.3. Redundant vs. Useful Signal . . . . . . . . . . . . . . . 20
7.4. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 20
7.5. Architectural Considerations Matter . . . . . . . . . . . 20
7.6. Service Considerations: Application Diversity & Realistic
Assessment . . . . . . . . . . . . . . . . . . . . . . . 21
7.7. Operational Guidance for Signal Enforcement . . . . . . . 21
7.8. Signal Estimation . . . . . . . . . . . . . . . . . . . . 22
7.9. Signal "Interference" . . . . . . . . . . . . . . . . . . 22
8. Deployment Incentives . . . . . . . . . . . . . . . . . . . . 22
8.1. Networks . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Applications . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Host OS . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. ND . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Rate-Limit Policy Objects Registry Group . . . . . . . . 25
10.2. Optional Parameter Flags Registry . . . . . . . . . . . 25
10.3. Flow Flags Registry . . . . . . . . . . . . . . . . . . 26
10.4. Neighbor Discovery Option . . . . . . . . . . . . . . . 27
10.5. DHCP Option . . . . . . . . . . . . . . . . . . . . . . 27
10.6. DHCP Options Permitted in the RADIUS DHCPv4-Options
Attribute . . . . . . . . . . . . . . . . . . . . . . . 27
10.7. Provisioning Domains Split DNS Additional Information . 28
10.8. New PvD Network Rate-Limit Policies (NRLPs) Registry . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Example of Authentication, Authorization, and
Accounting (AAA) . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Alternative/Complementary Mechanisms . . . . . . . . 36
B.1. L4S . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.2. Network Slicing . . . . . . . . . . . . . . . . . . . . . 37
B.3. 3GPP UE Route Selection Policy . . . . . . . . . . . . . 37
B.4. Network APIs . . . . . . . . . . . . . . . . . . . . . . 38
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
Boucadair, et al. Expires 11 April 2025 [Page 3]
Internet-Draft Rate-Limit Policies Discovery October 2024
1.1. Context
Connectivity services are provided by networks to customers via
dedicated terminating points, such as customer edges (CEs) or User
Equipment (UE). To facilitate data transfer via the provider
network, it is assumed that appropriate setup is provisioned over the
links that connect customer terminating points and a provider network
(usually via a Provider Edge (PE)), successfully allowing data
exchange over these links. The required setup is referred to in this
document as network attachments, while the underlying link is
referred to as "bearers".
The bearer can be a physical or logical link that connects a customer
device to a provider network. A bearer can be a wireless or wired
link. The same or multiple bearer technologies can be used to
establish the bearer (e.g., WLAN, cellular) to graft customer
terminating points to a network.
Network attachment is also known as "Attachment Circuit (AC)"
which is an established concept in the industry and also in the
IETF ([RFC4026], [RFC4664], [RFC4364], etc.).
Figure 1 shows an example of a network that connects CEs and hosts
(UE, for example).These CEs are servicing other (internal) hosts.
The identification of these hosts is hidden from the network. The
policies enforced at the network for an AC are per-subscriber, not
per-host. Typically, if a CE is provided with a /56 IPv6 prefix,
policies are enforced on that /56 not the individual /64s that will
be used by internal hosts. A customer terminating point may be
serviced with one (e.g., UE#1, CE#1, and CE#3) or multiple ACs (e.g.,
CE#2).
Hosts
O O O
\|/
.------. .--------------------. .------.
| +------+ | +---AC----+ |
| UE#1 | | | +---AC----+ CE#2 |
'------' +---AC----+ | '------'
| Network |
.------. .---AC----+ |
| | | | | .------.
| CE#1 +------' | +---AC----+ CE#3 |
'------' | | '------'
/|\ '--------------------' /|\
O O O O O O
Hosts Hosts
Boucadair, et al. Expires 11 April 2025 [Page 4]
Internet-Draft Rate-Limit Policies Discovery October 2024
Figure 1: Sample Network Attachments
Customer terminating points are provided with a set of information
(e.g., IP address/prefix) to successfully be able to send and receive
traffic over an AC. A comprehensive list of provisioning parameters
that are available on the PE-side of an AC is documented in
[I-D.ietf-opsawg-ntw-attachment-circuit].
The required set of parameters is a function of the service offering.
For example, a very limited set of parameters is required for mass-
market service offering while a more elaborated set is required for
Enterprise services (e.g., Layer 2 VPN [RFC9291] or Layer 3 VPN
[RFC9182]). This document *leverages access control, authorization,
and authentication mechanisms that are already in place for the
delivery of services over these ACs*.
1.2. Networks Are Already Sharing Network Properties with Hosts
To optimally deliver connectivity services via a network attachment,
networks also advertize a set of network properties [RFC9473] to
connected hosts such as:
Link Maximum Transmission Unit (MTU): For example, the 3GPP
[TS-23.501] specifies that "the link MTU size for IPv4 is sent to
the UE by including it in the PCO (see TS 24.501). The link MTU
size for IPv6 is sent to the UE by including it in the IPv6 Router
Advertisement message (see RFC 4861)".
Section 2.10 of [RFC7066] indicates that a cellular host should
honor the MTU option in the Router Advertisement (Section 4.6.4 of
[RFC4861]) given that the 3GPP system architecture uses extensive
tunneling in its packet core network below the 3GPP link, and this
may lead to packet fragmentation issues.
MTU is cited as an example of path properties in Section 4 of
[RFC9473].
Prefixes of Network Address and Protocol Translation from IPv6
clients to IPv4 servers (NAT64) [RFC8781]: This option is useful to
enable local DNSSEC validation, support networks with no DNS64,
support IPv4 address literals on an IPv6-only host, etc.
NAT is cited as an example of path properties (see "Service
Function" bullet in Section 4 of [RFC9473]).
Encrypted DNS option [RFC9463]: This option is used to discover
encrypted DNS resolvers of a network.
Boucadair, et al. Expires 11 April 2025 [Page 5]
Internet-Draft Rate-Limit Policies Discovery October 2024
1.3. What's In?
*Given that all IPv6 hosts and networks are required to support
Neighbor Discovery [RFC4861]*, this document specifies a Neighbor
Discovery option to be used in Router Advertisements (RAs) to
communicate rate-limit policies to hosts (Section 4). For address
family parity, a DHCP option [RFC2132] is also defined for IPv4 in
Section 5. Section 6 describes a discovery approach using
Provisioning Domains (PvDs) [RFC8801].
These options are called: Network Rate-Limit Policy (NRLP).
In order to ensure consistent design for both IPv4 and IPv6 ACs,
Section 3 groups the set of NRLP parameters that are returned
independent of the address family. This blob can be leveraged in
networks where ND/DHCP/PvD are not used and ease the mapping with
specific protocols used in these networks. For example, *_a Protocol
Configuration Option (PCO) [TS-24.008] NRLP Information Element can
be defined in 3GPP_*.
Whether host-to-network, network-to-host, or both policies are
returned in an NRLP is deployment specific. All these combinations
are supported in this document.
Also, the design supports returning one more NRLP instances for a
given traffic direction.
1.4. What's Out?
This document does not make any assumption about the type of the
network (fixed, cellular, etc.) that terminates an AC.
Likewise, the document does not make any assumption about the
services or applications that are delivered over an AC. Whether one
or multiple services are bound to the same AC is deployment specific.
Applications will have access to all these NRLPs and will, thus,
adjust their behavior as a function of scope and traffic category
indicated in a policy (all traffic, streaming, etc.). An application
that couples multiple flow types will adjust each flow type to be
consistent with the specific policy for the relevant traffic
category. Likewise, a host with multiple ACs may use the discovered
NRLPs AC to decide how to distribute its flows over these ACs (prefer
an AC to place an application session, migrate connection, etc.).
That's said, this document does not make any recommendation about how
a receiving host uses the discovered policy.
Boucadair, et al. Expires 11 April 2025 [Page 6]
Internet-Draft Rate-Limit Policies Discovery October 2024
Networks that advertize NLRPs are likely to maintain the policing in
place within the network because of the trust model (hosts are not
considered as trusted devices). Per-subscriber rate-limit policies
are generally recommended to protect nodes against Denial of Service
(DoS) attacks (e.g., Section 9.3 of [RFC8803] or Section 8 of
[I-D.ietf-masque-quic-proxy]). Discussion about conditions under
which such a trust model can be relaxed is out of scope of this
document.
This document does not assume nor preclude that other mechanisms,
e.g., Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9330],
are enabled in a bottleneck link. The reader may refer to Appendix B
for a list of relevant mechanisms. Whether these mechanism as
alternative or complementary to explicit host/network signals is to
be further assessed.
1.5. Design Motivation & Rationale
The main motivations for the use of ND for such a discovery are
listed in Section 3 of [RFC8781]:
* Fate sharing
* Atomic configuration
* Updatability: change the policy at any time
* Deployability
The solution specified in the document is designed to *ease
integration with network management tools* that are used to manage
and expose policies. It does so by leveraging the policy structure
defined in [I-D.ietf-opsawg-ntw-attachment-circuit]. That same
structure is also used in the context of service activation such as
Network Slicing [RFC9543]; see the example depicted in Appendix B.5
of [I-D.ietf-teas-ietf-network-slice-nbi-yang].
The solution defined in this document:
* *Does not require any data plane change*.
* *Applicable to any transport protocol*.
* *Does not impact the connection setup delay*.
* *Does not require to reveal the identity of the target server or
the application itself* to consume the signal.
Boucadair, et al. Expires 11 April 2025 [Page 7]
Internet-Draft Rate-Limit Policies Discovery October 2024
* *Supports cascaded environments* where multiple levels to enforce
rate-limiting polices is required (e.g., WAN and LAN shown in
Figure 2). NRLP signals can be coupled or decoupled as a function
of the local policy.
* *Supports signaling policies bound to one or both traffic
directions*.
* Is able to *signal whether a policy applies to a specific host or
all hosts of a given subscriber*.
.------. .--------------------.
| Host +---+ .---. | |
| #1 | | | | | |
'------' +-----+ C | | |
nrlp#2 | P +--------+ Network |
.------. .-----+ E | nrlp#1 | |
| Host | | | | | |
| #2 +---' '---' | |
'------' nrlp#3 | |
'--------------------'
Figure 2: Example of Cascaded NRLPs
Compared to a proxy or an encapsulation-based proposal (e.g.,
[I-D.ihlar-masque-sconepro-mediabitrate]), the solution defined in
this document:
* *Does not impact the MTU tweaking*: No packet overhead is
required.
* *Does not suffer from side effects of multi-layer encryption
schemes* on the packet processing and overall performance of
involved network nodes. Such issues are encountered, e.g., with
the tunneled mode or long header packets in the forwarded QUIC
proxy mode [I-D.ietf-masque-quic-proxy].
* *Does not suffer from nested congestion control* for tunneled
proxy mode.
* *Does not incur multiple round-trips* in the forwarding mode for
the client to start sending Short Header packets.
* *Does not incur the overhead of unauthenticated re-encryption of
QUIC packets* in the scramble transform of the forwarding mode.
Boucadair, et al. Expires 11 April 2025 [Page 8]
Internet-Draft Rate-Limit Policies Discovery October 2024
* *Does not impact the forwarding peformance of network nodes*. For
example, the proxy forwarded mode [I-D.ietf-masque-quic-proxy]
requires rewriting connection identifiers; that is, the
performance degradation will be at least equivalent to NAT.
* *Does not suffer from the complications of IP address sharing
[RFC6269]*. Such issues are likely to be experienced for proxy-
based solutions that multiplex internal connections using one or
more external IP addresses.
* *Does not suffer from penalizing the proxy* which could serve both
good and bad clients (e.g., launching Layer 7 DDoS attacks).
* *Does not require manipulating extra steering policies on the
host* to decide which flows can be forwarded over or outside the
proxy connection.
* *Requires a minor change to the network*: For IPv6, upgrade PE
nodes to support a new ND option. Note that all IPv6 hosts and
networks are required to support Neighbor Discovery [RFC4861].
For IPv4, configure DHCP servers to include a new DHCP option.
1.6. Sample Deployment Cases
Some deployment use cases for NRLP are provided below:
* A network may advertize an NRLP when it is overloaded, including
when it is under attack. The rate-limit policy is basically a
reactive policy that is meant to adjust the behavior of connected
hosts to better control the load during these exceptional events
(issue with RAN resources, for example). The mechanism can also
be used to enrich the tools that are already available to better
handle attack traffic close to the source [RFC9066].
* Discovery of intentional policy applied on ACs (peering links, CE-
PE links, etc.) when such information is not made available during
the service activation or when network upgrades are performed.
* A user may configure policies on the CPE such as securing some
resources to a specific internal host used for gaming or video
streaming. The CPE can use the NRLP option to share these rate-
limit policies to connected hosts to adjust their forwarding
behavior.
Operational considerations are discussed in Section 7, while
deployment incentives are described in Section 8.
Boucadair, et al. Expires 11 April 2025 [Page 9]
Internet-Draft Rate-Limit Policies Discovery October 2024
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the terms defined in Section 2 of
[I-D.ietf-opsawg-ntw-attachment-circuit] and [RFC9473].
Also, this document makes use fo the following terms:
Reactive policy: Treatment given to a flow when an exceptional event
occurs, such as diminished throughput to the host caused by radio
interference or weak radio signal, congestion on the network
caused by other users or other applications on the same host.
Intentional policy: Configured bandwidth, pps, or similar throughput
constraints applied to a flow, application, host, or subscriber.
Rate-limit: Used as a generic term to refer to a policy to restrict
the maximum bitrate of a flow.
It can be used with or without any traffic classification.
3. NRLP Blob
This section defines the set of attributes that are included in an
NRLP blob:
Optional Parameter Flags (OPF): These flags indicate the presence of
some optional parameters. The following flags are defined (from
MSB to LSB):
E: When set to "1", this flag indicates the presence of Excess
Information Rate (EIR).
When set to "0", this flag indicates that EIR is not present.
P: When set to "1", this flag indicates the presence of Peak
Information Rate (PIR).
When set to "0", this flag indicates that PIR is not present.
U: Unassigned bits. See Section 10.2.
Unassigned bits MUST be set to zero by senders and MUST be
Boucadair, et al. Expires 11 April 2025 [Page 10]
Internet-Draft Rate-Limit Policies Discovery October 2024
ignored by receivers.
Flow flags (FF): These flags are used to express some generic
properties of the flow. The following flags are defined (from MSB
to LSB):
S (Scope): 1-bit field which specifies whether the policy is per
host (when set to "1") or per subscriber (when set to "0).
D (Direction): 1-bit flag which indicates the direction on which
to apply the enclosed policy.
When set to "1", this flag indicates that this policy is for
network-to-host direction.
When set to "0", this flag indicates that this policy is for
host-to-network direction.
R (Reliablity): 2-bit flag which indicates the reliability type
of traffic on which to apply the enclosed policy.
When set to "00b", this flag indicates that this policy is for
unreliable traffic.
When set to "01b", this flag indicates that this policy is for
reliable traffic.
When set to "10b", this flag indicates that this policy is for
both reliable and unreliable traffic.
No meaning is associated with setting the field to "11b". Such
value MUST be silently ignored by the receiver.
U: Unassigned bits. See Section 10.3.
Unassigned bits MUST be set to zero by senders and MUST be
ignored by receivers.
TC (Traffic Category): 6-bit field which specifies a traffic
category to which this policy applies.
The following values are supported:
* "0": All traffic. This is the default value.
* "1": Streaming
* "2": Real-time
Boucadair, et al. Expires 11 April 2025 [Page 11]
Internet-Draft Rate-Limit Policies Discovery October 2024
* "3": Bulk traffic
* 4-63: Unassigned values
Committed Information Rate (CIR) (Mbps): Specifies the maximum
number of bits that a network can receive or send during one
second over an AC for a traffic category.
If set to 0, this indicates to the host that an alternate path (if
any) should be preferred over this one.
This parameter is mandatory.
Committed Burst Size (CBS) (bytes): Specifies the maximum burst size
that can be transmitted at CIR.
MUST be greater than zero.
This parameter is mandatory.
Excess Information Rate (EIR) (Mbps): MUST be present only if the E
flag is set to '1'.
Specifies the maximum number of bits that a network can receive or
send during one second over an AC for a traffic category that is
out of profile.
This parameter is optional.
Excess Burst Size (EBS) (bytes): MUST be present only if EIR is also
present.
Indicates the maximum excess burst size that is allowed while not
complying with the CIR.
MUST be greater than zero, if present.
This parameter is optional.
Peak Information Rate (PIR) (Mbps): MUST be present only if P flag
is set to '1'.
Traffic that exceeds the CIR and the CBS is metered to the PIR.
This parameter is optional.
Peak Burst Size (PBS) (bytes): MUST be present only if PIR is also
present.
Boucadair, et al. Expires 11 April 2025 [Page 12]
Internet-Draft Rate-Limit Policies Discovery October 2024
Specifies the maximum burst size that can be transmitted at PIR.
MUST be greater than zero, if present.
The reader should refer to [RFC2697], [RFC2698], and [RFC4115] for
examples of how various combinations of CIR/CBS/EIR/EBS/PIR/PBS are
used for policing. Typically:
* A Single-Rate, Three-Color Marker [RFC2697] uses CIR, CBS, and
EBS.
* A Dual-Rate, Three-Color Marker [RFC2698] uses CIR, CBS, PIR, and
PBS.
4. IPv6 RA NRLP Option
4.1. Option Format
The format of the IPv6 RA NRLP option, with only mandatory fields
included, is illustrated in Figure 3.
MSB LSB
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | OPF | FF | TC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Information Rate (CIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NRLP Option Format with Mandatory Fields
The format of the IPv6 RA NRLP option, with optional fields included,
is illustrated in Figure 3.
Boucadair, et al. Expires 11 April 2025 [Page 13]
Internet-Draft Rate-Limit Policies Discovery October 2024
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | OPF | FF | TC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Information Rate (CIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Information Rate (EIR) (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Burst Size (EBS) (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Information Rate (PIR) (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size (PBS) (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NRLP Option Format with Optional Fields
The fields of the option shown in Figure 4 are as follows:
Type: 8-bit identifier of the NRLP option as assigned by IANA (TBD1)
(see Section 10.4).
Length: 8-bit unsigned integer. The length of the option (including
the Type and Length fields) is in units of 8 octets.
OPF (Optional Parameter Flags): 4-bit flags which indicates the
presence of some optional inforamtion in the option.
See Section 3 for the structure of this field.
See Table 1 for current assigned flags.
FF (Flow flags): 6-bit flags used to express some generic properties
of the flow.
See Section 3 for the structure of this field.
See Table 2 for current assigned flags.
TC: See Section 3.
Committed Information Rate (CIR) (Mbps): See Section 3.
Committed Burst Size (CBS) (bytes): See Section 3.
Boucadair, et al. Expires 11 April 2025 [Page 14]
Internet-Draft Rate-Limit Policies Discovery October 2024
Excess Information Rate (EIR) (Mbps): See Section 3. This is an
optional field.
Excess Burst Size (EBS) (bytes): See Section 3. This is an optional
field.
Peak Information Rate (PIR) (Mbps): See Section 3. This is an
optional field.
Peak Burst Size (PBS) (bytes): See Section 3. This is an optional
field.
4.2. IPv6 Host Behavior
The procedure for rate-limit configuration is the same as it is with
any other Neighbor Discovery option [RFC4861].
The host MUST be prepared to receive multiple NRLP options in RAs;
each with distinct scope and/or application group.
If the host receives multiple NRLP options with overlapping scope/TC,
the host MUST silently discard all these options.
If the receiving host has LAN capabilities (e.g., mobile CE or mobile
handset with tethering), the following behavior applies:
* If an RA NRLP is advertised from the network, and absent local
rate-limit policies, the device should send RAs to the downstream
attached LAN devices with the same NRLP values received from the
network.
* If local rate-limit policies are provided to the device, the
device may change the scope or values received from the network to
accommodate these policies. The device may decide to not relay
received RAs to internal nodes if local policies were already
advertized using RAs and those policies are consistent with the
network policies.
Applications running over a host can learn the bitrates associated
with a network attachment by invoking a dedicated API. The exact
details of the API is OS-specific and, thus, out of scope of this
document.
Boucadair, et al. Expires 11 April 2025 [Page 15]
Internet-Draft Rate-Limit Policies Discovery October 2024
5. DHCP NRLP Option
Note that the base DHCP can only signal a rate policy change when
the client first joins the network or renews its lease, whereas
IPv6 ND can update the rate policy at the network's discretion.
[RFC6704] specifies an approach for forcing reconfiguration of
individual hosts without suffering from the limitations of the
FORCERENEW design in [RFC3203].
5.1. Option Format
The format of the DHCP NRLP option is illustrated in Figure 5.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V4_NRLP| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ NRLP Instance Data #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
. ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional
~ NRLP Instance Data #n ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 5: NRLP DHCP Option Format
The fields of the option shown in Figure 5 are as follows:
Code: OPTION_V4_NRLP (TBD2). (see Section 10.5).
Length: Indicates the length of the enclosed data in octets.
NRLP Instance Data: Includes a network rate-limit policy. The
format of this field with only mandatory parameters is shown in
Figure 6.
When several NRLPs are to be included, the "NRLP Instance Data"
field is repeated.
Boucadair, et al. Expires 11 April 2025 [Page 16]
Internet-Draft Rate-Limit Policies Discovery October 2024
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NRLP Instance Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPF | FF | TC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Information Rate |
| (CIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NRLP Instance Data Format with Mandatory Fields
The format of this field, with optional parameters included, is shown
in Figure 6.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NRLP Instance Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPF | FF | TC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Information Rate |
| (CIR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Excess Information Rate | |
| (EIR) | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| Excess Burst Size (CBS) | T
| | I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O
| Peak Information Rate | N
| (PIR) | A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L
| Peak Burst Size (PBS) | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 7: NRLP Instance Data Format with Optional Fields Included
The fields shown in Figure 7 are as follows:
Boucadair, et al. Expires 11 April 2025 [Page 17]
Internet-Draft Rate-Limit Policies Discovery October 2024
NRLP Instance Data Length: Length of all following data in octets.
This field is set to '8' when only the nominal bitrate is provided
for an NLRP instance.
OPF (Optional Parameter Flags): 4-bit flags which indicates the
presence of some optional inforamtion in the option.
See Section 3 for the structure of this field.
See Table 1 for current assigned flags.
FF (Flow flags): 6-bit flags used to express some generic properties
of the flow.
See Section 3 for the structure of this field.
See Table 2 for current assigned flags.
TC: See Section 3.
Committed Information Rate (CIR) (Mbps): See Section 3.
Committed Burst Size (CBS) (bytes): See Section 3.
Excess Information Rate (EIR) (Mbps): See Section 3. This is an
optional field.
Excess Burst Size (EBS) (bytes): See Section 3. This is an optional
field.
Peak Information Rate (PIR) (Mbps): See Section 3. This is an
optional field.
Peak Burst Size (PBS) (bytes): See Section 3. This is an optional
field.
OPTION_V4_NRLP is a concatenation-requiring option. As such, the
mechanism specified in [RFC3396] MUST be used if OPTION_V4_NRLP
exceeds the maximum DHCP option size of 255 octets.
OPTION_V4_NRLP is permitted to be included in the RADIUS
DHCPv4-Options Attribute [RFC9445].
5.2. DHCPv4 Client Behavior
To discover a network rate-limit policy, the DHCP client includes
OPTION_V4_NRLP in a Parameter Request List option [RFC2132].
Boucadair, et al. Expires 11 April 2025 [Page 18]
Internet-Draft Rate-Limit Policies Discovery October 2024
The DHCP client MUST be prepared to receive multiple "NRLP Instance
Data" field entries in the OPTION_V4_NRLP option; each instance is to
be treated as a separate network rate-limit policy.
6. Provisioning Domains
PvD may also be used as a mechanism to discover NRLP. Typically, the
network will configured to set the H-flag so clients can request PvD
Additional Information (Section 4.1 of [RFC8801]).
Figure 8 provides an example of the returned "application/pvd+json"
to indicate a network-to-host NRLP for all subscriber traffic. The
NRLP list may include multiple instances if distinct policies are to
be returned for distinct traffic categories.
{
"nrlp":[
{
"direction":1,
"scope":1,
"tc":0,
"cir":50,
"cbs":10000,
"ebs":20000
}
]
}
Figure 8: NRLP Example with PvD
7. Operational Considerations
7.1. NRLP Is Complementary Not Replacement Solution
Sharing NRLP signals are not intended to replace usual actions to
soften bottlenck issues (e.g., adequate network dimensioning and
upgrades). However, given that such actions may not be always
immediately possible or economically justified, NRLP signals can be
considered as complementary mitigations to soften these issues by
introducing some collaboration between a host and its networks to
adjust their behaviors.
7.2. Provisionning Policies
NRLP senders should be configured with instructions about the type of
network rate-limit policies to be shared with requesting hosts.
These types can be provided using mechanisms such as
[I-D.ietf-opsawg-ntw-attachment-circuit].
Boucadair, et al. Expires 11 April 2025 [Page 19]
Internet-Draft Rate-Limit Policies Discovery October 2024
7.3. Redundant vs. Useful Signal
In contexts where the bitrate policies are known during the
establishment of the underlying bearer (e.g., GBR PDU Sessions),
sending NRLP signals over the AC may be redundant and should thus be
disabled.
In contexts where the (average) bitrate policies provided during the
establishment of a bearer cannot be refreshed to echo network-
specific conditions (e.g., overload) using bearer-specific
mechanisms, sending NRLP signals over the AC would allow control the
load at the source.
When both bearer-specific policies and NRLP signals are communicated
to a host, the NRLP signals takes precedence.
7.4. Fairness
Rate-limit policies enforced at the network are assumed to be
consistent with the local jurisdictions. For example:
* [BEREC] states that ISPs are prohibited from blocking or slowing
down of Internet traffic, except for legal reasons, network
security, or congestion, provided that equivalent categories of
traffic are treated equally.
* [FCC] states that net neutrality policies "prohibits internet
service providers from blocking, throttling, or engaging in paid
prioritization of lawful content". The FCC allows some
exceptions, like for security and emergencies.
These regulatory frameworks align with the goals of this document.
7.5. Architectural Considerations Matter
Approaches based on middleboxes are generally not recommended due to
their inherent limitations, in terms of performance, scalability,
redundancy, etc. Specifically, if the management and operation of
such middleboxes remain unclear, that motivate operational issues and
responsibilities. Furthermore, it is important to note that any
middlebox could not necessarily cover an entire service end-to-end,
thus *producing only partial observations which could not be
sufficiently good at the time of generating appropriate signals*.
The NRLP solution does not require such middleboxes but the
consideration about partial observability applies. That concern can
be softened by cascaded NLRP design. However, network integration of
such appraoch is to be further elaborated.
Boucadair, et al. Expires 11 April 2025 [Page 20]
Internet-Draft Rate-Limit Policies Discovery October 2024
7.6. Service Considerations: Application Diversity & Realistic
Assessment
Signals could be generated for multiple services and/or applications.
For instance, services providing short video content might require
signals different to those based on long videos. This implies the
need of defining a generic method suitable for any kind of service
and application, avoiding the multiplicity of solutions and the
dominance of some applications over others.
It should be also noted that more experimentation is needed in order
to fully understand the implications of the signals in the overall
performance of the network. On one hand, the co-existence of
multiple flows, some of them using the signals for improving the
experience, some others not. For this, more experimentation and
datasets are required, so then can be clear that no flows are
negatively impacted at all.
On the other hand, if the experience of the flows improves and
depending on the nature of the signals themselves, this might
motivate a more intense usage of the network, then requiring to
accommodate larger number of flows, and in consequence, reducing the
available resources per application. This kind of paradox can be
*assessed with more experimental results under realistic conditions
(i.e., multiple users and multiple services in the network)*.
7.7. Operational Guidance for Signal Enforcement
Signals are conceived as indications from the network towards
applications. It is not clear the way of enforcing the application
to follow the indication, especially in a context where different
applications from a user, or multiple users, simultaneously access
the network. This can motivate a wastage of resources for generating
signals with the risk of not being effective. Furthermore, it might
lead to a continuous loop of signal generation because the initial
signals being ignored. It is then necessary to define mechanisms to
avoid permanent signal generation when ignored.
Finally, signals could not be required at every moment, but only in
situations that can benefit the service. Such situations could be
due, for instance, to given levels of congestion, or based on
previous information shared by the application (e.g., SLO thresholds)
so that signals can be triggered according to service conditions.
*Elaborating more operational guidance on intended signal enforcment
policy is key*.
Boucadair, et al. Expires 11 April 2025 [Page 21]
Internet-Draft Rate-Limit Policies Discovery October 2024
7.8. Signal Estimation
The validity of the estimation produced by a network might be
questioned by the application. Trust is required in a way that
applications can safely follow guidance from a network. Furthermore,
whatever estimation should be timely produced, avoiding the
generation of aged estimations that could not correspond to the
actual service circumstances. Finally, some common guidance is
necessary to define a standard way of generating signals, for
instance, per-flow or per group of flows.
An open point is how to deal with adaptive applications, in the sense
that signals could not be of value because the self-adaptation nature
of these applications.
7.9. Signal "Interference"
The network is built on multiple layers. In some cases, different
solutions targeting similar objectives (e.g., congestion control or
bottleneck mitigation) can be in place. It is then necessary to
*assess the simultaneous coexistence of these solutions to avoid
contradictory effects or "interferences"*.
8. Deployment Incentives
8.1. Networks
There are a set of tradeoffs for networks to deploy NRLP discovery:
* Cost vs. benefit
* Impact on operations vs incentive to deploy
* Enhanced experience vs. impacts on nominal mode
The procedure defined in the document provides a mechanism to assist
networks managing the load at the source and, thus, contribute to
better handle network overloads and optimize the use of resources
under non nominal conditions. The mechanism also allows to enhance
the quality of experience at the LAN by providing a simple tool to
communicate local policies to hosts. A minimal change is required to
that aim.
With the OS support, the following benefits might be considered by
networks:
Improved Network Performance: The OS can schedule network requests
Boucadair, et al. Expires 11 April 2025 [Page 22]
Internet-Draft Rate-Limit Policies Discovery October 2024
more efficiently, preventing network congestion, and improving
overall stability and network performance with NRLP signals.
Cost Efficiency: By managing network usage based on known rate
limits, the OS can help reduce network-related costs. However,
this is difficult to assess.
Networks that throttle bandwidth for reasons that are not compliant
with local jurisdictions, not communicated to customers, etc. are
unlikely to share NRLP signals. If these signals are shared, it is
unlikely that they will mirror the actual network configuration
(e.g., application-specific policies).
8.2. Applications
Some applications support some forms of bandwidth measurements (e.g.,
[app-measurement]) which feed how the content is accessed to using
ABR. Complementing or replacing these measurements with explicit
signals depends upon:
* The extra cost that is required to support both mechanisms at the
application layer.
* The complexity balance between performing the measurements vs.
consuming the signal.
* Whether the measurements ("assessed property" per [RFC9473])
reflect actual network conditions or severely diverge.
* The availability of the network signals at the first place: it is
unlikely that all networks will support sending the signals.
Deployment incentives at the network may vary.
* The host support may be variable.
Applications that don't support (embedded) bandwidth measurement
schemes will be enriched with the NRLP signals as this will be
exposed by an OS API.
8.3. Host OS
API to facilitate Application Development: An OS can provide more
accurate available bandwidth to applications through the API (as
mentioned in Section 8.2), making implementation easier for
applications that don't requrie dedicated bandwidth measurement.
Prevent Abuse: The OS can allocate network resources more fairly
Boucadair, et al. Expires 11 April 2025 [Page 23]
Internet-Draft Rate-Limit Policies Discovery October 2024
among different processes, with NRLP signals, ensuring that no
single process monopolizes the network.
Better Resource Management: OS can also optimize resource
allocation, by deprioritizing background/inactive applications in
the event of high network utilization.
Enhanced Security: Awareness of NRLPs can help the OS detect and
mitigate network-related security threats, such as denial-of-
service (DoS) attacks.
Improved User Experience: By avoiding network congestion and
ensuring fair resource allocation, the OS can provide a smoother,
more responsive user experience.
Improved Application Development Efficiency: OS providing rate
limits through an API (as mentioned in Section 8.2) can provide
the above listed benefits at per application level.
9. Security Considerations
The techniques discussed in the document offer the following security
benefit: An OS can identify the type of application (background,
foreground, streaming, real-time, etc.) and enforce appropriate
network policies, even if a misbehaving application tries to evade
the rate-limit policies. If an application attempts to bypass rate-
limiting by changing its 5-tuple or creating multiple flows, the OS
can detect this and manage the application's traffic accordingly.
9.1. ND
As discussed in [RFC8781], because RAs are required in all IPv6
configuration scenarios, RAs must already be secured, e.g., by
deploying an RA-Guard [RFC6105]. Providing all configuration in RAs
reduces the attack surface to be targeted by malicious attackers
trying to provide hosts with invalid configuration, as compared to
distributing the configuration through multiple different mechanisms
that need to be secured independently.
RAs are already used in mobile networks to advertize the link MTU.
The same security considerations for MTU discovery apply for the NRLP
discover.
An attacker who has access to the RAs exchanged over an AC may:
Decrease the bitrate: This may lower the perceived QoS if the host
aggressively lowers its transmission rate.
Boucadair, et al. Expires 11 April 2025 [Page 24]
Internet-Draft Rate-Limit Policies Discovery October 2024
Increase the bitrate value: The AC will be overloaded, but still the
rate-limit at the network will discard excess traffic.
Drop RAs: This is similar to the current operations, where no NRLP
RA is shared.
Inject fake RAs: The implications are similar to the impacts of
tweaking the values of a legitimate RA.
9.2. DHCP
An attacker who has access to the DHCP exchanged over an AC may do a
lot of harm (e.g., prevent access to the network).
The following mechanisms may be considered to mitigate spoofed or
modified DHCP responses:
DHCPv6-Shield [RFC7610]: The network access node (e.g., a border
router, a CPE, an Access Point (AP)) discards DHCP response
messages received from any local endpoint.
Source Address Validation Improvement (SAVI) solution for DHCP
[RFC7513]: The network access node filters packets with forged
source IP addresses.
The above mechanisms would ensure that the endpoint receives the
correct NRLP information, but these mechanisms cannot provide any
information about the DHCP server or the entity hosting the DHCP
server.
10. IANA Considerations
10.1. Rate-Limit Policy Objects Registry Group
This document requests IANA to create a new registry group entitled
"Rate-Limit Policy Objects".
10.2. Optional Parameter Flags Registry
This document requests IANA to create a new registry entitled
"Optional Parameter Flags" under the "Rate-Limit Policy Objects"
registry group (Section 10.1).
The initial values of this registry is provided in Table 1.
Boucadair, et al. Expires 11 April 2025 [Page 25]
Internet-Draft Rate-Limit Policies Discovery October 2024
+==============+=============+===============+
| Bit Position | Description | Reference |
+==============+=============+===============+
| 1 | E-flag | This-Document |
+--------------+-------------+---------------+
| 2 | P-flag | This-Document |
+--------------+-------------+---------------+
| 3 | Unassigned | |
+--------------+-------------+---------------+
| 4 | Unassigned | |
+--------------+-------------+---------------+
Table 1: Optional Parameter Flags
The allocation policy of this new registry is "IETF Review"
(Section 4.8 of [RFC8126]).
10.3. Flow Flags Registry
This document requests IANA to create a new registry entitled "Flow
flags" under the "Rate-Limit Policy Objects" registry group
(Section 10.1).
The initial values of this registry is provided in Table 2.
+==============+=======================+===============+
| Bit Position | Description | Reference |
+==============+=======================+===============+
| 1 | Scope (S) Flag | This-Document |
+--------------+-----------------------+---------------+
| 2 | Direction (D) Flag | This-Document |
+--------------+-----------------------+---------------+
| 3-4 | Reliability (R) Flags | This-Document |
+--------------+-----------------------+---------------+
| 5 | Unassigned | |
+--------------+-----------------------+---------------+
| 6 | Unassigned | |
+--------------+-----------------------+---------------+
Table 2: Flow flags
The allocation policy of this new registry is "IETF Review"
(Section 4.8 of [RFC8126]).
Boucadair, et al. Expires 11 April 2025 [Page 26]
Internet-Draft Rate-Limit Policies Discovery October 2024
10.4. Neighbor Discovery Option
This document requests IANA to assign the following new IPv6 Neighbor
Discovery Option type in the "IPv6 Neighbor Discovery Option Formats"
sub-registry under the "Internet Control Message Protocol version 6
(ICMPv6) Parameters" registry maintained at [IANA-ND].
+======+=============+===============+
| Type | Description | Reference |
+======+=============+===============+
| TBD1 | NRLP Option | This-Document |
+------+-------------+---------------+
Table 3: Neighbor Discovery NRLP
Option
Note to the RFC Editor: Please replace all "TBD1" occurrences with
the assigned value.
10.5. DHCP Option
This document requests IANA to assign the following new DHCP Option
Code in the "BOOTP Vendor Extensions and DHCP Options" registry
maintained at [IANA-BOOTP].
+======+================+=============+=============+===============+
| Tag | Name | Data Length | Meaning | Reference |
+======+================+=============+=============+===============+
| TBD2 | OPTION_V4_NRLP | N | NRLP | This-Document |
| | | | Option | |
+------+----------------+-------------+-------------+---------------+
Table 4: DHCP NRLP Option
Note to the RFC Editor: Please replace all "TBD2" occurrences with
the assigned value.
10.6. DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute
This document requests IANA to add the following DHCP Option Code to
the "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute"
registry maintained at [IANA-BOOTP].
Boucadair, et al. Expires 11 April 2025 [Page 27]
Internet-Draft Rate-Limit Policies Discovery October 2024
+======+================+===============+===========+
| Tag | Name | | Reference |
+======+================+===============+===========+
| TBD2 | OPTION_V4_NRLP | This-Document | |
+------+----------------+---------------+-----------+
Table 5: New DHCP Option Permitted in the RADIUS
DHCPv4-Options Attribute Registry
10.7. Provisioning Domains Split DNS Additional Information
IANA is requested to add the following entry to the "Additional
Information PvD Keys" registry under the "Provisioning Domains
(PvDs)" registry group [IANA-PVD]:
JSON key: "nrlp"
Description: "Network Rate-Limit Policies (NRLPs)"
Type: Array of Objects
Example:
{
"nrlp":[
{
"direction":1,
"scope":1,
"tc":0,
"cir":50
}
]
}
Reference: This_Document
10.8. New PvD Network Rate-Limit Policies (NRLPs) Registry
IANA is requested to create a new registry "PvD Rate-Limit Policies
(NRLPs)" registry, within the "Provisioning Domains (PvDs)" registry
group.
The initial contents of this registry are as follows:
Boucadair, et al. Expires 11 April 2025 [Page 28]
Internet-Draft Rate-Limit Policies Discovery October 2024
+===========+===================+=========+=========+===============+
| JSON key | Description | Type | Example | Reference |
+===========+===================+=========+=========+===============+
| direction | Indicates the | Boolean | 1 | This-Document |
| | traffic | | | |
| | direction to | | | |
| | which a policy | | | |
| | applies. When | | | |
| | set to "1", this | | | |
| | parameter | | | |
| | indicates that | | | |
| | this policy is | | | |
| | for network-to- | | | |
| | host direction. | | | |
| | When set to "0", | | | |
| | this parameter | | | |
| | indicates that | | | |
| | this policy is | | | |
| | for host-to- | | | |
| | network | | | |
| | direction. | | | |
+-----------+-------------------+---------+---------+---------------+
| scope | Specifies | Boolean | 1 | This-Document |
| | whether the | | | |
| | policy is per | | | |
| | host (when set | | | |
| | to "1") or per | | | |
| | subscriber (when | | | |
| | set to "0) | | | |
+-----------+-------------------+---------+---------+---------------+
| tc | Specifies a | Integer | 0 | This-Document |
| | traffic category | | | |
| | to which this | | | |
| | policy applies. | | | |
| | Values are taken | | | |
| | from the Rate- | | | |
| | Limit Policy | | | |
| | Objects Registry | | | |
| | Section 10.1 | | | |
+-----------+-------------------+---------+---------+---------------+
| cir | Specifies the | Integer | 50 | This-Document |
| | maximum number | | | |
| | of bits that a | | | |
| | network can | | | |
| | receive or send | | | |
| | during one | | | |
| | second over an | | | |
| | AC for a traffic | | | |
Boucadair, et al. Expires 11 April 2025 [Page 29]
Internet-Draft Rate-Limit Policies Discovery October 2024
| | category. | | | |
+-----------+-------------------+---------+---------+---------------+
| xxx | xxx | xxx | xx | This-Document |
+-----------+-------------------+---------+---------+---------------+
Table 6: Initial PvD Network Rate-Limit Policies (NRLPs) Registry
Content
New assignments in the "PvD Network Rate-Limit Policies (NRLPs)"
registry will be administered by IANA through Expert Review policy
[RFC8126]. Experts are requested to ensure that defined keys do not
overlap in names or semantics.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/rfc/rfc2132>.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
DOI 10.17487/RFC3396, November 2002,
<https://www.rfc-editor.org/rfc/rfc3396>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Boucadair, et al. Expires 11 April 2025 [Page 30]
Internet-Draft Rate-Limit Policies Discovery October 2024
[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/rfc/rfc8801>.
[RFC9445] Boucadair, M., Reddy.K, T., and A. DeKok, "RADIUS
Extensions for DHCP-Configured Services", RFC 9445,
DOI 10.17487/RFC9445, August 2023,
<https://www.rfc-editor.org/rfc/rfc9445>.
11.2. Informative References
[app-measurement]
Gurel, Z. and A. C. Begen, "Bandwidth measurement for
QUIC", 2024, <https://datatracker.ietf.org/doc/slides-119-
moq-bandwidth-measurement-for-quic/>.
[BEREC] BEREC, "All you need to know about Net Neutrality rules in
the EU", <https://www.berec.europa.eu/en/all-you-need-to-
know-about-net-neutrality-rules-in-the-eu-0>.
[FCC] FCC, "FCC Restores Net Neutrality",
<https://www.fcc.gov/document/fcc-restores-net-neutrality-
0>.
[I-D.ietf-masque-quic-proxy]
Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware
Proxying Using HTTP", Work in Progress, Internet-Draft,
draft-ietf-masque-quic-proxy-03, 7 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
quic-proxy-03>.
[I-D.ietf-opsawg-ntw-attachment-circuit]
Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,
and B. Wu, "A Network YANG Data Model for Attachment
Circuits", Work in Progress, Internet-Draft, draft-ietf-
opsawg-ntw-attachment-circuit-13, 5 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
ntw-attachment-circuit-13>.
[I-D.ietf-teas-5g-ns-ip-mpls]
Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M.,
and L. M. Contreras, "A Realization of Network Slices for
5G Networks Using Current IP/MPLS Technologies", Work in
Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip-mpls-
12, 7 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-
ns-ip-mpls-12>.
Boucadair, et al. Expires 11 April 2025 [Page 31]
Internet-Draft Rate-Limit Policies Discovery October 2024
[I-D.ietf-teas-ietf-network-slice-nbi-yang]
Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
"A YANG Data Model for the RFC 9543 Network Slice
Service", Work in Progress, Internet-Draft, draft-ietf-
teas-ietf-network-slice-nbi-yang-16, 28 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slice-nbi-yang-16>.
[I-D.ihlar-masque-sconepro-mediabitrate]
Ihlar, M. and M. Kühlewind, "MASQUE extension for
signaling media bitrate", Work in Progress, Internet-
Draft, draft-ihlar-masque-sconepro-mediabitrate-00, 9
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ihlar-masque-sconepro-mediabitrate-00>.
[IANA-BOOTP]
IANA, "BOOTP Vendor Extensions and DHCP Options",
<https://www.iana.org/assignments/bootp-dhcp-parameters/>.
[IANA-ND] IANA, "IPv6 Neighbor Discovery Option Formats",
<https://www.iana.org/assignments/icmpv6-parameters/>.
[IANA-PVD] IANA, "Provisioning Domains (PvDs)",
<https://www.iana.org/assignments/pvds/>.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<https://www.rfc-editor.org/rfc/rfc2697>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
<https://www.rfc-editor.org/rfc/rfc2698>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, DOI 10.17487/RFC3203,
December 2001, <https://www.rfc-editor.org/rfc/rfc3203>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/rfc/rfc4026>.
Boucadair, et al. Expires 11 April 2025 [Page 32]
Internet-Draft Rate-Limit Policies Discovery October 2024
[RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service
Two-Rate, Three-Color Marker with Efficient Handling of
in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July
2005, <https://www.rfc-editor.org/rfc/rfc4115>.
[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/rfc/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006,
<https://www.rfc-editor.org/rfc/rfc4664>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/rfc/rfc6105>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/rfc/rfc6269>.
[RFC6704] Miles, D., Dec, W., Bristow, J., and R. Maglione,
"Forcerenew Nonce Authentication", RFC 6704,
DOI 10.17487/RFC6704, August 2012,
<https://www.rfc-editor.org/rfc/rfc6704>.
[RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S.
Krishnan, "IPv6 for Third Generation Partnership Project
(3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066,
November 2013, <https://www.rfc-editor.org/rfc/rfc7066>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/rfc/rfc7513>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
Protecting against Rogue DHCPv6 Servers", BCP 199,
RFC 7610, DOI 10.17487/RFC7610, August 2015,
<https://www.rfc-editor.org/rfc/rfc7610>.
[RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
2020, <https://www.rfc-editor.org/rfc/rfc8781>.
Boucadair, et al. Expires 11 April 2025 [Page 33]
Internet-Draft Rate-Limit Policies Discovery October 2024
[RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S.,
Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol",
RFC 8803, DOI 10.17487/RFC8803, July 2020,
<https://www.rfc-editor.org/rfc/rfc8803>.
[RFC9066] Reddy.K, T., Boucadair, M., Ed., and J. Shallow,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Call Home", RFC 9066,
DOI 10.17487/RFC9066, December 2021,
<https://www.rfc-editor.org/rfc/rfc9066>.
[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
February 2022, <https://www.rfc-editor.org/rfc/rfc9182>.
[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil,
S., and L. Munoz, "A YANG Network Data Model for Layer 2
VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022,
<https://www.rfc-editor.org/rfc/rfc9291>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/rfc/rfc9330>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/rfc/rfc9463>.
[RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path
Properties", RFC 9473, DOI 10.17487/RFC9473, September
2023, <https://www.rfc-editor.org/rfc/rfc9473>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/rfc/rfc9543>.
[TR-470] BBF, "5G Wireless Wireline Convergence Architecture -
Issue 2",
<https://www.broadband-forum.org/pdfs/tr-470-2-0-0.pdf>.
Boucadair, et al. Expires 11 April 2025 [Page 34]
Internet-Draft Rate-Limit Policies Discovery October 2024
[TS-23.501]
3GPP, "TS 23.501: System architecture for the 5G System
(5GS)", 2024,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TS-23.503]
3GPP, "TS 23.503: Policy and charging control framework
for the 5G System (5GS)", 2024,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3334>.
[TS-24.008]
3GPP, "Technical Specification Group Core Network and
Terminals; Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3 (Release 18)", 2024,
<https://www.3gpp.org/DynaReport/24008.htm>.
[TS-29.522]
3GPP, "TS 29.522: 5G System; Network Exposure Function
Northbound APIs", 2024,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3437>.
Appendix A. Example of Authentication, Authorization, and Accounting
(AAA)
Figure 9 provides an example of the exchanges that might occur
between a DHCP server and an Authentication, Authorization, and
Accounting (AAA) server to retrieve the per-subscriber NRLPs.
This example assumes that the Network Access Server (NAS) embeds both
Remote Authentication Dial-In User Service (RADIUS) [RFC2865] client
and DHCP server capabilities.
Boucadair, et al. Expires 11 April 2025 [Page 35]
Internet-Draft Rate-Limit Policies Discovery October 2024
.-------------. .-------------. .-------.
| Host | | NAS | | AAA |
| DHCP Client | | DHCP Server | |Server |
| | |RADIUS Client| | |
'------+------' '------+------' '---+---'
| | |
o------DHCPDISCOVER------>| |
| o----Access-Request ---->|
| | |
| |<----Access-Accept------o
| | DHCPv4-Options |
|<-----DHCPOFFER----------o (OPTION_V4_NRLP) |
| (OPTION_V4_NRLP) | |
| | |
o-----DHCPREQUEST-------->| |
| (OPTION_V4_NRLP) | |
| | |
|<-------DHCPACK----------o |
| (OPTION_V4_NRLP) | |
| | |
DHCP RADIUS
Figure 9: An Example of RADIUS NRLP Exchanges
Appendix B. Alternative/Complementary Mechanisms
In the event of bottlenecks in a network, there are other mechanisms
that provide information or help to reserve resources. These can be
used within the bottleneck network or, in some cases, across network
boundaries. The following sections give examples of such mechanisms
and provide background information.
B.1. L4S
Low Latency, Low Loss, and Scalable Throughput (L4S) is an
architecture defined in [RFC9330] to avoid queuing at bottlenecks by
capacity-seeking congestion controllers of senders. L4S support
addresses the investigated use case of this document, which considers
rate limiting, which typically involves queuing discipline at the
rate limiting bottleneck. If all involved elements (UE, network, and
service) support L4S, the use of Explicit Congestion Notification
(ECN) provides the measure used to inform the network protocol and/or
service endpoints in use of impending congestion. Congestion
detection and reaction may require a few RTTs to adjust to the
network forwarding conditions.
Boucadair, et al. Expires 11 April 2025 [Page 36]
Internet-Draft Rate-Limit Policies Discovery October 2024
As of 3GPP Rel. 18 (5G Advanced, [TS-23.501]), L4S is also defined
for the 5G system (5GS) and can be used by UE and its services, and
for external parties of the 5GS by exposure of congestion
information.
B.2. Network Slicing
One measure for guaranteeing resources in networks is network
slicing. This is achieved by configuring certain resources like
adequate QoS setup for communication streams, which are taken into
account in packet schedulers along the transport path. e.g., the RAN
air interface.
Network slicing is considered by 3GPP for 5G [TS-23.501] (an
equivalent can be achieved in 4G by configuring QFI values), by IETF
[RFC9543] for transport networks, and by BBF [TR-470] for wireline
access. A realization model in transport networks is detailed in
[I-D.ietf-teas-5g-ns-ip-mpls].
L4S Appendix B.1 can be used for the realization of a network slice.
Network slices properties (e.g., throughput) can be retrieved from an
operator network or configured by third parties via a network API
Appendix B.4 (e.g., 3GPP NEF).
B.3. 3GPP UE Route Selection Policy
UE Route Selection Policy (URSP) is a feature specified in 3GPP to
match and forward traffic based upon a selection descriptor and a
route descriptor as further detailed in [TS-23.503].
Specified traffic descriptors may be:
* Application
* IP
* Domain
* Non-IP
* DNN
* Connection Capabilities
* Connectivity Group ID
Specified route selection descriptors: must contain PDU Session Type
Selection (e.g., IPv4v6 or IPv6) and may contain the following:
Boucadair, et al. Expires 11 April 2025 [Page 37]
Internet-Draft Rate-Limit Policies Discovery October 2024
* SSC Mode
* Network Slice
* DNN
* Non-Seamless Offload indication
* Access Type preference
URSP rules that contain both descriptors can be announced from the
provider network to a UE or preconfigured in the UE, possibly
subscription-based. These rules can be used to identify services in
the UE and to provide routes with explicit characteristics. URSP
rules might also be triggered by the usage of network APIs
Appendix B.4 and combined with network slicing Appendix B.2, for
example.
B.4. Network APIs
Network APIs are the interface between the operator network and
third-party providers. With 4G, the first methods were introduced to
make network capabilities available, which has been greatly improved
with the introduction of 5G. To this end, the new Network Exposure
Function (NEF) is responsible for 5G, which is specified in
[TS-29.522], which defines a huge list of network capabilites for
monitoring and configuration for external consumption.
For integration into external services, initiatives such as the
CAMARA Alliance and GSMA Open Gateway provide abstractions of these
exposed network capabilities into service APIs for easy integration
by developers.
The CAMARA API "Network Slice Booking", which is currently under
development, would be a way for a service provider to configure the
necessary resources in the operator network. In the background, 5G
features such as network slicing Appendix B.2 , URSP Appendix B.3
and, if necessary, L4S Appendix B.1 could then ensure implementation
in the operator network.
Acknowledgments
Thanks to Tommy Pauly for the comment on PvD.
Authors' Addresses
Mohamed Boucadair
Orange
Boucadair, et al. Expires 11 April 2025 [Page 38]
Internet-Draft Rate-Limit Policies Discovery October 2024
Email: mohamed.boucadair@orange.com
Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
Email: danwing@gmail.com
Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com
Sridharan Rajagopalan
Cloud Software Group Holdings, Inc.
United States of America
Email: sridharan.girish@gmail.com
Gyan Mishra
Verizon Inc
United States of America
Email: gyan.s.mishra@verizon.com
Markus Amend
Deutsche Telekom
Germany
Email: markus.amend@telekom.de
Luis M. Contreras
Telefonica
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Boucadair, et al. Expires 11 April 2025 [Page 39]