Discovery of CIDFI-aware Network Elements

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 17 August 2024.¶

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

Senders rely on ramping up their transmission rate until they encounter packet loss or see [ECN] indicating they should level off or slow down their transmission rate. This feedback takes time and contributes to poor user experience when the sender over- or under-shoots the actual available bandwidth, especially if the sender changes fidelity of the content (e.g., improves video quality which consumes more bandwidth which then gets dropped by the network). This is also called an 'intentional management policy'.¶

Due to network constraints a network element will need to drop or even prioritize a packet ahead of other packets within the same UDP 4-tuple. The decision of which packet to drop or prioritize is improved if the network element knows the importance of the packet. By mapping packet metadata to a network-visible field in each packet, the network element is better informed and better able to improve the user experience.¶

There are also exceptional cases (crisis) where "normal" network resources cannot be used at maximum and, thus, a network would seek to reduce or offload some of the traffic during these events -- often called 'reactive traffic policy'. Network-to-host signals are useful to put in place adequate traffic distribution policies (e.g., prefer the use of alternate paths or offload a network).¶

[I-D.wing-cidfi] defines a generic framework, called CIDFI (pronounced "sid fye"), which is a system of several protocols that allows communicating about a connection from the network to a host and the host to the network. For example, this mechanism can be used by a host to signal packet importance to a network element. Overall, the following main steps are involved in CIDFI; some of them are optional:¶

• CIDFI-awareness discovery between a host and a network.¶

• Establishment of a secure association with all or a subset of CIDFI-aware networks.¶

• Negotiation of CIDFI support with remote servers.¶

• CIDFI-aware networks sharing of changes of network conditions.¶

• CIDFI-aware clients sharing of metadata with CIDFI-aware networks as hints to help processing flows.¶

• CIDFI-aware clients sharing of metadata with CIDFI-aware server to adapt to local network conditions.¶

This document focuses on the discovery step. On initial network attach topology change, the client learns if the network supports CIDFI (Section 4) and authorizes discovered network elements (Section 5) as a function of a local policy.¶

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.¶

The document makes use of the following terms:¶

CNE:

CIDFI-aware Network Element, a network element that supports this CIDFI specification. This is typically a router.¶

Differentiated service:

Refers to a differentiated processing that can be provided to a flow (or specific packets within a flow) by a network, client, or server.¶

Examples of differentiated service are: prioritization, adaptive transmission, or traffic steering.¶

3. Network Configuration to Support CIDFI

The network is configured to advertise its support for CIDFI.¶

For this step, four mechanisms are described in this document: DNS SVCB records [RFC9460], IPv6 Provisioning Domains (PvD) [RFC8801], DHCP [RFC2131][RFC8415], and 3GPP PCO. These are described in the following sub-sections.¶

• Standardizing all or some of these mechanisms is for further discussion.¶

_cidfi-aware.cidfi.arpa. 7200 IN SVCB 0 service-cidfi.example.net. (
    alpn=h3 cidfipathauth=/path-auth-query{?cidfi}
    cidfimetadata=/cidfi-metadata
    )
_cidfi-aware.cidfi.arpa. 7200 IN SVCB 0 wifi.example.com. (
    alpn=h3 cidfipathauth=/path-auth-query{?cidfi}
    cidfimetadata=/cidfi-metadata
    )

{
   "cidfi":[
      {
         "cidfinode":"service-cidfi.example.net",
         "min-ttl":3,
         "cidfipathauth":"/path-auth-query{?cidfi}",
         "cidfimetadata":"/cidfi-metadata"
      },
      {
         "cidfinode":"wi-fi.example.net",
         "min-ttl":2,
         "cidfipathauth":"/path-auth-query{?cidfi}",
         "cidfimetadata":"/cidfi-metadata"
      }
   ]
}

4. Client Learns Local Network Supports CIDFI

For this step, four mechanisms are identified: DNS SVCB records, IPv6 PvD, DHCP, or 3GPP PCO. These are described in the following sub-sections.¶

In all cases below,¶

• if the discovery succeeds (i.e., the client concludes that the local and/or ISP network support CIDFI) client processing proceeds to Section 5.¶

• if the discovery failed (i.e., the client concludes that the local network and ISP do not support CIDFI) client processing stops.¶

5. Client Authorizes CIDFI-aware Network Elements

The client authorizes each of the CNEs using a local policy. This policy is implementation-specific. An implementation example might have the users authorize their ISP's CIDFI server (e.g., allow "cidfi.example.net" if a user's ISP is configured with "example.net"). Similarly, if none of the CNEs are recognized by the client, the client might silently avoid using CIDFI on that network.¶

6. Security Considerations

TBC.¶

7. IANA Considerations

JSON key: cidfi
Description: CID Flow Indicator
Type: array of cidfi details
Example: ["cidfinode": "service.example.net", "cidfipathauth":
          "/authpath", "cidfimetadata": "/meta"]

JSON key: cidfinode
Description: FQDN of CIDFI node
Type: string
Example: service.example.net

JSON key: min-ttl
Description: The minimum TTL or Hop Limit to reach a CNE
Type: Unsigned integer
Example: 5

JSON key: cidfipathauth
Description: authentication and authorization path for CIDFI
type: string
Example: "/authpath"

JSON key: cidfimetadata
Description: metadata path for CIDFI
type: string
example: "/metadata"

Acknowledgments

Thanks to Dave Täht, Magnus Westerlund, Christian Huitema, Gorry Fairhurst, and Tom Herbert for hallway discussions and feedback at TSVWG that encouraged the authors to consider the approach described in this document. Thanks to Ben Schwartz for suggesting PvD as an alternative discovery mechanism.¶

Authors' Addresses