Internet DRAFT - draft-wing-cidfi-discovery

draft-wing-cidfi-discovery







Network Working Group                                            D. Wing
Internet-Draft                                      Cloud Software Group
Intended status: Standards Track                                T. Reddy
Expires: 17 August 2024                                            Nokia
                                                            M. Boucadair
                                                                  Orange
                                                        14 February 2024


               Discovery of CIDFI-aware Network Elements
                     draft-wing-cidfi-discovery-00

Abstract

   Host-to-network signaling and network-to-host signaling can improve
   the user experience to adapt to network's constraints and share
   expected application needs, and thus to provide differentiated
   service to a flow and to packets within a flow.  The differentiated
   service may be provided at the network (e.g., packet prioritization),
   the server (e.g., adaptive transmission), or both.  Such an approach
   is called CIDFI, for Collaborative and Interoperable Dissemination of
   Flow Indicators.

   A key component in a CIDFI system is to discover whether a network is
   CIDFI-capable, and if so discover a set of CIDFI-aware Network
   Elements (CNEs) that will be involved in the Host-to-network
   signaling and network-to-host signaling.  This document discusses a
   set of discovery methods.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://danwing.github.io/cidfi/draft-wing-cidfi.html.  Status
   information for this document may be found at
   https://datatracker.ietf.org/doc/draft-wing-cidfi-discovery/.

   Discussion of this document takes place on the TSV Area Working Group
   mailing list (mailto:tsvwg@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/tsvwg/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/tsvwg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/danwing/cidfi.






Wing, et al.             Expires 17 August 2024                 [Page 1]

Internet-Draft             CIDFI NE Discovery              February 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 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Network Configuration to Support CIDFI  . . . . . . . . . . .   4
     3.1.  DNS SVCB Records  . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Provisioning Domains  . . . . . . . . . . . . . . . . . .   5
     3.3.  DHCP or 3GPP PCO  . . . . . . . . . . . . . . . . . . . .   6
   4.  Client Learns Local Network Supports CIDFI  . . . . . . . . .   6
     4.1.  Client Learns Using DNS SVCB  . . . . . . . . . . . . . .   7
     4.2.  Client Learns Using Provisioning Domain . . . . . . . . .   7
     4.3.  Client Learns Using DHCP or 3GPP PCO  . . . . . . . . . .   7
   5.  Client Authorizes CIDFI-aware Network Elements  . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  New Well-known URI "cidfi-aware"  . . . . . . . . . . . .   7
     7.2.  New Special-use Domain Name . . . . . . . . . . . . . . .   7



Wing, et al.             Expires 17 August 2024                 [Page 2]

Internet-Draft             CIDFI NE Discovery              February 2024


     7.3.  New DNS Service Binding (SVCB)  . . . . . . . . . . . . .   8
     7.4.  New Provisioning Domain Additional Information Key  . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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.



Wing, et al.             Expires 17 August 2024                 [Page 3]

Internet-Draft             CIDFI NE Discovery              February 2024


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







Wing, et al.             Expires 17 August 2024                 [Page 4]

Internet-Draft             CIDFI NE Discovery              February 2024


3.1.  DNS SVCB Records

   This document defines a new DNS Service Binding parameter "cidfi-
   aware" in Section 7.3 and a new Special-Use Domain Name "cidfi.arpa"
   in Section 7.2.

   The local network is configured to respond to DNS SVCB [RFC9460]
   queries with ServiceMode (Section 2.4.3 of [RFC9460]) for "_cidfi-
   aware.cidfi.arpa" with the DNS names of that network's and upstream
   network's CIDFI-aware network elements (CNEs).  If upstream networks
   also support CIDFI (e.g., the ISP network) those SVCB records are
   aggregated into the local DNS server's response by the local
   network's recursive DNS resolvers.  For example, a query for "_cidfi-
   aware.cidfi.arpa" might return two answers for the two CNEs on the
   local network, one belonging to the local ISP (example.net) and the
   other belonging to the local Wi-Fi network (example.com).

   _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
       )

                     Figure 1: Example of SVCB Records

   When multihoming, the multihome-capable CPE aggregates all upstream
   networks' "_cidfi-aware.cidfi.arpa" responses into the response sent
   to its locally-connected clients.

3.2.  Provisioning Domains

   The CIDFI networks are configured to set the H-flag so clients can
   request PvD Additional Information (Section 4.1 of [RFC8801]).

   The "application/pvd+json" returned looks like what is depicted in
   Figure 2 when there are two CIDFI-aware network elements, service-
   cidfi and wi-fi.











Wing, et al.             Expires 17 August 2024                 [Page 5]

Internet-Draft             CIDFI NE Discovery              February 2024


           {
              "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"
                 }
              ]
           }

                    Figure 2: Example of PvD Information

   Multiple CIDFI-aware network elements on a network path will require
   propagating the Provisioning Domain Additional Information.  For
   example, a CIDFI-aware Wi-Fi access point connected to a CIDFI-aware
   5G network will require the information for both CIDFI networks be
   available to the client, in a single Provisioning Domain Additional
   Information request.  This means the Wi-Fi access point has to obtain
   that information so the Wi-Fi access point can provide both the 5G
   network's information and the Wi-Fi access point's information.

3.3.  DHCP or 3GPP PCO

   The network is configured to respond to DHCPv6, DHCPv4 sub-option, or
   3GPP PCO (Protocol Configuration Option) Information Element.

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.




Wing, et al.             Expires 17 August 2024                 [Page 6]

Internet-Draft             CIDFI NE Discovery              February 2024


4.1.  Client Learns Using DNS SVCB

   The client determines if the local network provides CIDFI service by
   issuing a query to the local DNS server for "_cidfi-
   aware.cidfi.arpa." with the SVCB resource record type (64) [RFC9460].

4.2.  Client Learns Using Provisioning Domain

   The client determines if the local network supports CIDFI by querying
   https://<PvD-ID>/.well-known/pvd as described in Section 4.1 of
   [RFC8801].

4.3.  Client Learns Using DHCP or 3GPP PCO

   The client determines that a local network is CIDFI-capable if the
   client receives an explicit signal from the network, e.g., via a
   dedicated DHCP option or a 3GPP PCO (Protocol Configuration Option)
   Information Element.  An example of explicit signal would be a DHCPv6
   option or DHCPv4 sub-option that that is returned as part of
   [RFC7839].

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

7.1.  New Well-known URI "cidfi-aware"

   This document requests IANA to register the new well-known URI
   "cidfi" in the "Well-Known URIs" registry available at [IANA-WKU].

7.2.  New Special-use Domain Name

   This document requests IANA to register new a special-use domain name
   cidfi.arpa for DNS SVCB discovery.






Wing, et al.             Expires 17 August 2024                 [Page 7]

Internet-Draft             CIDFI NE Discovery              February 2024


7.3.  New DNS Service Binding (SVCB)

   This document requests IANA to register the new DNS SVCB "_cidfi-
   aware" in the "DNS Service Bindings (SVCB)" registry available at
   [IANA-SVCB].

   The document also requests IANA to register the following service
   parameter in the "Service Parameter Keys (SvcParamKeys)" registry
   [IANA-SVCB]:

   Number:  TBD

   Name:  min-ttl

   Meaning: :The minimum IPv4 TTL or IPv6 Hop Limit to use for a
   connection.

   Reference:  This-Document

7.4.  New Provisioning Domain Additional Information Key

   This document requests IANA to register a new JSON key in the
   Provisioning Domains Additional Information registry at [IANA-PVD]:

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

   Additionally, this document requests creating a new registry,
   entitled "CIDFI JSON Keys" under the Provisioning Domains Additional
   Information registry group [IANA-PVD].  The policy for assigning new
   entries in this registry is Expert Review Section 4.5 of [RFC8126].
   The structure of this registry is identical to the Provisioning
   Domains Additional Information registry group.  The initial content
   of this registry is provided below:














Wing, et al.             Expires 17 August 2024                 [Page 8]

Internet-Draft             CIDFI NE Discovery              February 2024


   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"

8.  References

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2131>.

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

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/rfc/rfc8415>.




Wing, et al.             Expires 17 August 2024                 [Page 9]

Internet-Draft             CIDFI NE Discovery              February 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>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

8.2.  Informative References

   [ECN]      Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/rfc/rfc3168>.

   [I-D.wing-cidfi]
              Wing, D., Reddy.K, T., and M. Boucadair, "Framework for
              CID Flow Indicator (CIDFI)", Work in Progress, Internet-
              Draft, draft-wing-cidfi-04, 14 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-wing-cidfi-
              04>.

   [IANA-PVD] "Provisioning Domains (PvDs)", 13 August 2020,
              <https://www.iana.org/assignments/pvds/
              pvds.xhtml#additional-information-pvd-keys>.

   [IANA-SVCB]
              "DNS Service Bindings (SVCB)", 13 June 2023,
              <https://www.iana.org/assignments/dns-svcb/dns-
              svcb.xhtml>.

   [IANA-WKU] "Well-known URIs", 20 June 2023,
              <https://www.iana.org/assignments/well-known-uris/well-
              known-uris.xhtml>.

   [pathologies]
              Custura, A., Secchi, R., and G. Fairhurst, "Exploring DSCP
              modification pathologies in the Internet", May 2018,
              <https://www.sciencedirect.com/science/article/pii/
              S0140366417312835>.

   [RFC7839]  Bhandari, S., Gundavelli, S., Grayson, M., Volz, B., and
              J. Korhonen, "Access-Network-Identifier Option in DHCP",
              RFC 7839, DOI 10.17487/RFC7839, June 2016,
              <https://www.rfc-editor.org/rfc/rfc7839>.




Wing, et al.             Expires 17 August 2024                [Page 10]

Internet-Draft             CIDFI NE Discovery              February 2024


   [wifi-aggregation]
              Høiland-Jørgensen, T., Kazior, M., Täht, D., Hurtig, P.,
              and A. Brunstrom, "Ending the Anomaly: Achieving Low
              Latency and Airtime Fairness in WiFi", 22 May 2017,
              <https://www.usenix.org/conference/atc17/technical-
              sessions/presentation/hoilan-jorgesen>.

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

   Dan Wing
   Cloud Software Group Holdings, Inc.
   United States of America
   Email: danwing@gmail.com
   URI:   https://www.cloud.com


   Tirumaleswar Reddy
   Nokia
   Bangalore
   Karnataka
   India
   Email: kondtir@gmail.com


   Mohamed Boucadair
   Orange
   Rennes
   35000
   France
   Email: mohamed.boucadair@orange.com













Wing, et al.             Expires 17 August 2024                [Page 11]