# drafts

name: draft-templin-6man-mla
rev: 32
title: IPv6 Addresses for Ad Hoc Networks
time: 2026-02-16T16:41:12Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-20T16:41:12Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:10.243380+00:00
abstract:
Ad Hoc networks present an IPv6 addressing challenge due to the
   undetermined neighborhood properties of their interfaces.  IPv6 nodes
   must assign locally-unique and topology-independent IPv6 addresses
   when topology-oriented IPv6 address delegation services are either
   absent or only intermittently available.  This document introduces a
   new IPv6 address type (termed the "Multilink Local Address (MLA)")
   that nodes can autonomously assign to interfaces to support Ad Hoc
   network operations.

full_text:
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: rfc4007, rfc5889, rfc6724 (if approved)        15 February 2026
Intended status: Standards Track                                        
Expires: 19 August 2026


                   IPv6 Addresses for Ad Hoc Networks
                       draft-templin-6man-mla-32

Abstract

   Ad Hoc networks present an IPv6 addressing challenge due to the
   undetermined neighborhood properties of their interfaces.  IPv6 nodes
   must assign locally-unique and topology-independent IPv6 addresses
   when topology-oriented IPv6 address delegation services are either
   absent or only intermittently available.  This document introduces a
   new IPv6 address type (termed the "Multilink Local Address (MLA)")
   that nodes can autonomously assign to interfaces to support Ad Hoc
   network operations.

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 19 August 2026.

Copyright Notice

   Copyright (c) 2026 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



Templin                  Expires 19 August 2026                 [Page 1]

Internet-Draft                  IPv6 MLAs                  February 2026


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  IPv6 Ad Hoc Network Local Addressing  . . . . . . . . . . . .   4
   3.  Assigning an MLA to an Interface  . . . . . . . . . . . . . .   5
   4.  MLAs in the Scoped Addressing Architecture  . . . . . . . . .   5
   5.  MLAs for Ad Hoc Networks  . . . . . . . . . . . . . . . . . .   7
   6.  Address Selection . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     12.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   When two or more IPv6 [RFC8200] nodes come together to form an Ad Hoc
   network, they must be able to assign unique addresses to their
   interfaces and exchange IPv6 packets with peers even if there is no
   Internetworking infrastructure present.  A classical example is a
   Mobile Ad-hoc Network (MANET) where wireless nodes within a common
   radio frequency locality discover multihop routes to support peer-to-
   peer communications.  However, arbitrary collections of fixed nodes
   interconnected by sparse collections of physical links also qualify.
   See [RFC5889] for further characteristics of Ad Hoc networks.

   Ad Hoc networks often include IPv6 nodes that configure interface
   attachments to links with undetermined connectivity properties such
   that multihop traversal may be necessary to span the network.  The
   transitive property of connectivity for conventional shared media
   links is therefore not assured, while nodes must still be able to
   configure IPv6 addresses that are unique within the local Ad Hoc
   network.  This is true even for nodes that configure multiple
   interface attachments to the same Ad Hoc network as a localized
   multihop/multilink forwarding domain.

   By its nature, the term "Ad Hoc network" implies logical groupings
   whereas the historical term "site" suggested physical boundaries such
   as a building or a campus.  In particular, Ad Hoc networks can self-



Templin                  Expires 19 August 2026                 [Page 2]

Internet-Draft                  IPv6 MLAs                  February 2026


   organize autonomously even if they overlap with other (logical)
   networks, split apart to form multiple smaller networks or join
   together to form larger networks.  Clustering can be applied as a
   means to divide larger MANETs into smaller logical groupings, noting
   that Ad Hoc network ecosystems are often in a constant state of flux
   and likely to change over time.  An address type that can be used by
   nodes that move freely between logical Ad Hoc network boundaries is
   therefore necessary.

   The term "Ad Hoc" used throughout this document extends to include
   isolated local IPv6 networks where peer to peer communications may
   require multihop and/or multilink traversal regardless of whether the
   network is particularly mobile or spontaneously organized.  For any
   such isolated network (i.e., one for which Internetworking proxy/
   servers are either absent or only intermittently available), a
   topology-independent IPv6 addressing scheme that allows peer nodes to
   communicate internally is necessary.  Therefore, all nodes that
   connect to such isolated IPv6 networks should be prepared to operate
   according to this multilink Ad Hoc addressing model when necessary.
   Each node then coordinates multihop forwarding services at an
   IPv6-based architectural sublayer termed the "adaptation layer" below
   the Internetworking layer but above the true link layer.

   Section 6 of the "IP Addressing Model in Ad Hoc Networks" [RFC5889]
   states that: "an IP address configured on this (Ad Hoc) interface
   should be unique, at least within the routing domain" and: "no on-
   link subnet prefix is configured on this (Ad Hoc) interface".  The
   section then continues to explain why IPv6 Link-Local Addresses
   (LLAs) are of limited utility on links with undetermined
   connectivity, to the point that they cannot be used exclusively
   within Ad Hoc network domains.  (Note that [RFC5498] provides IANA
   allocations for MANET protocols as a complementary publication.)

   [RFC5889] suggests Global Unicast [RFC4291] (aka "GUA") and Unique-
   Local [RFC4193] (aka "ULA") addresses as Ad Hoc network addressing
   candidates.  However, GUAs and ULAs are topology-oriented address
   types that must be obtained through either administrative actions or
   an address autoconfiguration service based on IPv6 proxy/servers that
   connect Ad Hoc networks to larger Internetworks.  (In particular
   topology-oriented address types are typically obtained through DHCPv6
   messages and/or Router Advertisement Prefix Information Options with
   prefix length shorter than 128.)  Since such Internetworking services
   may not always be available, however, this document asserts that a
   topology-independent and unique Ad Hoc network local IPv6 address
   type is needed.  The address type may include multiple sub-types,
   some of which may be coordinated with address registration services
   and others that may be partially or fully self-generated.




Templin                  Expires 19 August 2026                 [Page 3]

Internet-Draft                  IPv6 MLAs                  February 2026


   The key feature of these Ad Hoc network adaptation layer IPv6
   addresses is that they must have excellent statistical uniqueness
   properties such that there is little/no chance of conflicting with an
   address assigned by another node.  The addresses need not include
   topology-oriented prefixes, since the (newly-formed) Ad Hoc networks
   may not (yet) connect to established Internetworking topologies.

   Ad Hoc network nodes must be able to use adaptation layer IPv6
   addresses for continuous local communications and/or to coordinate
   topology-oriented addresses for assignment on other interfaces.  A
   new "Multilink Local" scope for the IPv6 scoped addressing
   architecture [RFC4007] with scope greater than LLA but lesser than
   ULA/GUA is therefore needed.  This document therefore defines a new
   unique local unicast address variant known as the "Multilink Local
   Address (MLA)".

   MLAs that require global uniqueness assurance shall be based on the
   construct specified in [RFC9374].  The MLA is based on a
   cryptographic hash of a node's public key regarded as its full
   identify.  The MLA is regarded as a unique identity tag that, when
   assigned to an interface, becomes a valid IPv6 address with
   multilink-local scope.  The MLA must be assured globally unique and
   routable at least within a limited domain to support MANET
   Internetworking [I-D.templin-manet-inet].

2.  IPv6 Ad Hoc Network Local Addressing

   The IPv6 addressing architecture specified in [RFC4007], [RFC4193]
   and [RFC4291] defines the supported IPv6 unicast/multicast/anycast
   address types with various scopes.  The IPv6 address assignment
   policy is further clarified in [RFC9812].

   ULAs and GUAs are typically obtained through Stateless Address
   AutoConfiguration (SLAAC) [RFC4862] and/or the Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6) [RFC8415], but these
   services require the presence of IPv6 Internetworking infrastructure
   which may not be continuously or even intermittently available in
   spontaneously-formed Ad Hoc networks.

   Interface attachments to Ad Hoc networks have the interesting
   property that a multihop router R will often need to forward packets
   between nodes A and B even though R uses the same interface in the
   inbound and outbound directions.  Since nodes A and B may not be able
   to communicate directly even though both can communicate directly
   with R, the transitive property for link connectivity is not assured
   and the IPv6 Neighbor Discovery (ND) Redirect service cannot
   guarantee reliable direct paths.  Conversely, R may need to forward
   packets between nodes A and B via different interfaces within an Ad



Templin                  Expires 19 August 2026                 [Page 4]

Internet-Draft                  IPv6 MLAs                  February 2026


   Hoc network that includes multiple distinct links/regions.  Due to
   these indeterminant multilink properties, exclusive use of IPv6 LLAs
   is also out of scope.

   This document therefore introduces a new IPv6 MLA address type based
   on a well-formed IPv6 prefix "TBD::/N" (see: IANA Considerations).
   After a node creates an MLA, it can use the address within the
   context of spontaneously-organized Ad Hoc networks in which two or
   more nodes come together in the absence of stable supporting
   infrastructure and can still exchange IPv6 packets with little or no
   chance of address collisions.  The node can limit MLA usage to
   bootstrapping the assignment of topology-oriented IPv6 addresses
   through other means mentioned earlier.  The node can instead extend
   its MLA usage to longer term patterns such as sustained
   communications with single-hop neighbors on a local link or even
   between multihop peers in an Ad Hoc network.

3.  Assigning an MLA to an Interface

   IPv6 MLAs are topology-independent and can therefore be assigned to
   interfaces with a /128 prefix length (i.e., as a singleton address).
   The node can then begin to use an MLA as the Source/Destination
   Address of IPv6 packets that are forwarded over an interface
   attachment to an Ad Hoc network multihop forwarding region.

   A node can specifically assign an MLA to MANET interfaces to support
   the operation of Ad Hoc network routing protocols and also to an
   Overlay Multilink Network (OMNI) Interface [I-D.templin-6man-omni3]
   to support extended MANET Internetworking with remote peers over an
   OMNI virtual link.

   MLAs may then serve as a basis for multihop forwarding and/or for
   local neighborhood discovery over other IPv6 interface types.  Due to
   their uniqueness properties, the node can assign MLAs as optimistic
   addresses per [RFC4429], however it should take actions to deconflict
   if it detects in-service duplication.

4.  MLAs in the Scoped Addressing Architecture

   With reference to a debate that concluded in the earliest years of
   the third millennium, a case could be made for reclaiming the
   deprecated site-local address prefix "fec0::/10" for use as a top-
   level MLA prefix.  However, some implementations still honor the
   deprecation and continue to regard the prefix as a defunct historical
   artifact.






Templin                  Expires 19 August 2026                 [Page 5]

Internet-Draft                  IPv6 MLAs                  February 2026


   [RFC3879] documents the deprecation rationale including the assertion
   that "Site is an Ill-Defined Concept".  However, the concept of an Ad
   Hoc network is a coherent logical one based on time-varying
   (multilink) connectivity and not necessarily one constrained by
   physical boundaries.  Especially in Ad Hoc networks that employ a
   proactive local routing protocol the list of available adaptation
   layer addresses in each network is continuously updated for temporal
   consistency.

   For example, an IPv6 node may connect to multiple distinct Ad Hoc
   networks with a first set of interfaces connected to network "A", a
   second set of interfaces connected to network "B", etc.  According to
   the scoped IPv6 addressing architecture [RFC4007], the node would
   assign a separate MLA to virtual interfaces associated with each Ad
   Hoc network interface set A, B, etc. and maintain separate Ad Hoc
   network multihop routing protocol instances for each set.  MLAs A, B,
   etc. then provide a basis for unique router IDs for the separate
   routing protocol instances, but the IPv6 node may elect to
   redistribute discovered adaptation layer routes between the
   instances.  The uniqueness properties of MLAs must therefore
   transcend logical Ad Hoc network boundaries to the extent that global
   uniqueness assurances are necessary when the scope for MANET dynamics
   extends to the entire Internet.

   A means for entering Ad Hoc network local IPv6 Zone Identifiers in
   user interfaces is necessary according to [RFC9844].  Examples of an
   Ad Hoc network local unicast address qualified by a zone identifier
   are as follows:

      TBD::884e:9d2a:73fc:2d94%netA

      TBD::c63d:9724:fca:1237%netB

   This document updates the IPv6 scoped addressing architecture
   [RFC4007] by introducing a "Multilink-Local" unicast addressing
   scope.  In particular, this document adds a third unicast address
   scope to Section 4 of [RFC4007] as follows:

   *  Multilink-Local scope, for uniquely identifying a node's attached
      Ad Hoc networks.

   The size relationship among scopes is further updated as:

   *  For unicast scopes, link-local is a smaller scope than Multilink-
      Local, which is a smaller scope than global.

   In [RFC4007], Section 5 under: "Zones of the different scopes are
   instantiated as follows", add the new bullet:



Templin                  Expires 19 August 2026                 [Page 6]

Internet-Draft                  IPv6 MLAs                  February 2026


   *  Each Ad Hoc network and the interfaces attached to that Ad Hoc
      network comprise a single zone of Multilink-Local scope (for
      unicast).

5.  MLAs for Ad Hoc Networks

   This document updates [RFC5889] to add a new address type "Multilink-
   Local" to the list of IPv6 address types found in Section 1 as:

   *  For IPv6, these addresses may be global [RFC3587], Unique-Local
      [RFC4193], Multilink-Local [RFCXXXX] or Link-Local [RFC4291].

6.  Address Selection

   "Default Address Selection for Internet Protocol Version 6 (IPv6)"
   [RFC6724] provides a policy table that specifies precedence values
   and preferred Source Address prefixes for specific Destination
   Addresses.  "Preference for IPv6 ULAs over IPv4 addresses in RFC6724"
   [I-D.ietf-6man-rfc6724-update] updates the policy table entries for
   ULAs, IPv4 Addresses and the 6to4 prefix (2002::/16).

   This document proposes a further update to the policy table for IPv6
   MLAs.  The proposed update appears in the table below:

 draft-ietf-6man-rfc6724-update                           Updated
Prefix        Precedence Label        Prefix        Precedence Label
::1/128               50     0        ::1/128               50     0
::/0                  40     1        ::/0                  40     1
::ffff:0:0/96         20     4        ::ffff:0:0/96         20     4
2002::/16              5     2        2002::/16              5     2
2001::/32              5     5        2001::/32              5     5
fc00::/7              30    13        fc00::/7              30    13
::/96                  1     3        ::/96                  1     3
fec0::/10              1    11        fec0::/10              1    11
3ffe::/16              1    12        3ffe::/16              1    12
                                      TBD::/N                4    14 (*)
(*) value(s) changed in update

     Figure 1: Policy Table Update for Multilink Local Addresses

   With the proposed updates, this new MLA address type appears as a
   lesser precedence than IPv6 GUAs, IPv6 ULAs and IPv4 addresses but as
   a greater precedence than deprecated IPv6 prefixes.








Templin                  Expires 19 August 2026                 [Page 7]

Internet-Draft                  IPv6 MLAs                  February 2026


7.  Requirements

   IPv6 nodes assign unique MLAs to an IPv6 virtual interface (e.g., an
   OMNI interface) configured over underlying interface attachments to
   Ad Hoc networks.  If the node becomes aware that a tentative self-
   generated MLA is already in use by another node, it instead generates
   and assigns a new MLA.  If the node becomes aware that an MLA for
   which it holds a certificate through an official registration service
   is already in use by another node, it should log and report the
   incident to the registration service authority.

   IPv6 routers MAY forward IPv6 packets with adaptation layer MLA
   Source or Destination Addresses over multiple hops within the same Ad
   Hoc network as an adaptation layer function.

   IPv6 routers MUST NOT forward packets with adaptation layer MLA
   Source or Destination Addresses to a link outside the packet's Ad Hoc
   network of origin, although MLAs MAY occur as network layer IPv6
   Source or Destination Addresses in packets forwarded between disjoint
   MANETs via the virtual overlay.

8.  Implementation Status

   In progress.

9.  IANA Considerations

   This document requests that IANA designate 2001:30::/28 as the MLA
   IPv6 prefix for TBD::/N the same as defined for [RFC9374] in the
   'iana-ipv6-special-registry'.  Future documents may request
   additional prefixes.

10.  Security Considerations

   IPv6 MLAs include either very large pseudo-random bit strings with
   ample statistical unique properties or bit strings that are
   algorithmically generated and coordinated with a registration service
   for administratively-ensured uniqueness.  In the latter case, the
   only apparent opportunity for duplication would be through either
   intentional or unintentional misconfiguration.

   Certain MLA types may have cryptographically generated portions tied
   to a certificate with the node's public key while other portions of
   the address identify a registration service where address proof-of-
   ownership can be confirmed.  This stands in contrast to autonomously
   assigned and fully self-generated MLAs while relying entirely on
   statistical uniqueness properties.




Templin                  Expires 19 August 2026                 [Page 8]

Internet-Draft                  IPv6 MLAs                  February 2026


   An IPv6 node that configures an MLA and assigns it to a virtual
   interface with an optimistic expectation of uniqueness should
   therefore be prepared to deconflict legitimate duplications.

11.  Acknowledgements

   This work was inspired by continued investigations into 5G MANET
   operations in cooperation with the Virginia Tech National Security
   Institute (VTNSI).

   Emerging discussions both in-person and on the IPv6 maintenance
   (6man) and MANET mailing lists continue to shape updated versions of
   this document.  The author acknowledges all whose useful comments
   have helped further the understanding of this proposal.

   Honoring life, liberty and the pursuit of happiness.

12.  References

12.1.  Normative References

   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
              DOI 10.17487/RFC4007, March 2005,
              <https://www.rfc-editor.org/info/rfc4007>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC5889]  Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
              Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
              September 2010, <https://www.rfc-editor.org/info/rfc5889>.

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <https://www.rfc-editor.org/info/rfc6724>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.




Templin                  Expires 19 August 2026                 [Page 9]

Internet-Draft                  IPv6 MLAs                  February 2026


   [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
              "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
              ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
              <https://www.rfc-editor.org/info/rfc9374>.

12.2.  Informative References

   [I-D.ietf-6man-rfc6724-update]
              Buraglio, N., Chown, T., and J. Duncan, "Prioritizing
              known-local IPv6 ULAs through address selection policy",
              Work in Progress, Internet-Draft, draft-ietf-6man-rfc6724-
              update-25, 11 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              rfc6724-update-25>.

   [I-D.templin-6man-aero3]
              Templin, F., "Automatic Extended Route Optimization
              (AERO)", Work in Progress, Internet-Draft, draft-templin-
              6man-aero3-52, 23 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-templin-6man-
              aero3-52>.

   [I-D.templin-6man-omni3]
              Templin, F., "Transmission of IP Packets over Overlay
              Multilink Network (OMNI) Interfaces", Work in Progress,
              Internet-Draft, draft-templin-6man-omni3-73, 6 February
              2026, <https://datatracker.ietf.org/doc/html/draft-
              templin-6man-omni3-73>.

   [I-D.templin-manet-inet]
              Templin, F. and D. J. Jakubisin, "MANET Internetworking:
              Problem Statement and Gap Analysis", Work in Progress,
              Internet-Draft, draft-templin-manet-inet-02, 12 January
              2026, <https://datatracker.ietf.org/doc/html/draft-
              templin-manet-inet-02>.

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, DOI 10.17487/RFC3879, September
              2004, <https://www.rfc-editor.org/info/rfc3879>.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
              <https://www.rfc-editor.org/info/rfc4429>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.



Templin                  Expires 19 August 2026                [Page 10]

Internet-Draft                  IPv6 MLAs                  February 2026


   [RFC5498]  Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
              (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March
              2009, <https://www.rfc-editor.org/info/rfc5498>.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
              <https://www.rfc-editor.org/info/rfc6296>.

   [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/info/rfc8415>.

   [RFC9812]  Carpenter, B., Krishnan, S., and D. Farmer, "Clarification
              of IPv6 Address Allocation Policy", BCP 242, RFC 9812,
              DOI 10.17487/RFC9812, October 2025,
              <https://www.rfc-editor.org/info/rfc9812>.

   [RFC9844]  Carpenter, B. and R. Hinden, "Entering IPv6 Zone
              Identifiers in User Interfaces", RFC 9844,
              DOI 10.17487/RFC9844, August 2025,
              <https://www.rfc-editor.org/info/rfc9844>.

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>

   Differences from earlier versions:

   Draft -31 to -32
      *  Further clarifications on MLAs as identity tags.

   Draft -30 to -31
      *  Introduced MANET Internetworking.

   Draft -29 to -30
      *  Promote RFC9374 as the normative specification for
         administratively coordinated MLAs.

   Draft -28 to -29
      *  Updated abstract, introduction and references.

   Draft -27 to -28
      *  Removed section on "Obtaining and Assigning IPv6 ULAs/GUAs" as
         out of scope for this document.

      *  Version update.



Templin                  Expires 19 August 2026                [Page 11]

Internet-Draft                  IPv6 MLAs                  February 2026


   Draft -26 to -27
      *  Significant updates to requirements.

      *  Relaxed "1x1" assignment of MLAs to a single MANET.

      *  Included references for candidate MLA types.

   Draft -24 to -26
      *  Stress address deconfliction instead of deprecation when
         address duplication is detected.

      *  Security considerations for MLA types that support remote
         attestation.

      *  Discussion of site as an ill-defined concept in contrast to
         "Multilink Local Scope".

   Draft -23 to -24
      *  Change reference to RFC6296.

      *  Added more explanation about Ad Hoc Networks.

      *  MLAs now assigned only to a virtual interface associated with
         the Ad-Hoc network and not the physical interfaces themselves.

      *  Added specifics of how this document updates other RFCs.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA 98124
   United States of America
   Email: fltemplin@acm.org
















Templin                  Expires 19 August 2026                [Page 12]


name: draft-bernardos-cats-isac-uc
rev: 01
title: Integrated Sensing and Communications (ISAC) for CATS
time: 2026-01-05T07:09:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-04T23:17:49Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "ML traffic mgmt"]
tags: []
fetched_at: 2026-02-27T22:56:10.243384+00:00
abstract:
Integrated Sensing and Communications (ISAC) represents a paradigm
   shift in wireless networks, where sensing and communication functions
   are jointly designed and optimized.  By leveraging the same spectral
   and hardware resources, ISAC enables advanced capabilities such as
   environment perception, object tracking, and situational awareness,
   while maintaining efficient and reliable data transmission.  This
   integration holds great potential for applications in areas such as
   autonomous systems, smart cities, and industrial automation, where
   precise sensing and low-latency communication are critical.  This
   document presents the ISAC as a typical CATS scenario to facilitate
   discussions on the potential challenges and requirements.

full_text:
CATS WG                                                    CJ. Bernardos
Internet-Draft                                                      UC3M
Intended status: Standards Track                               A. Mourad
Expires: 4 January 2026                                     InterDigital
                                                                T. Jiang
                                                                    CMCC
                                                             3 July 2025


         Integrated Sensing and Communications (ISAC) for CATS
                    draft-bernardos-cats-isac-uc-01

Abstract

   Integrated Sensing and Communications (ISAC) represents a paradigm
   shift in wireless networks, where sensing and communication functions
   are jointly designed and optimized.  By leveraging the same spectral
   and hardware resources, ISAC enables advanced capabilities such as
   environment perception, object tracking, and situational awareness,
   while maintaining efficient and reliable data transmission.  This
   integration holds great potential for applications in areas such as
   autonomous systems, smart cities, and industrial automation, where
   precise sensing and low-latency communication are critical.  This
   document presents the ISAC as a typical CATS scenario to facilitate
   discussions on the potential challenges and requirements.

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 4 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Bernardos, et al.        Expires 4 January 2026                 [Page 1]

Internet-Draft           ISAC use case for CATS                July 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Computing Aware distributed sensing for Integrated Sensing and
           Communications  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  CATS of ETSI ISAC . . . . . . . . . . . . . . . . . . . .   3
     2.2.  CATS of 3GPP ISAC . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Relation to CATS  . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   7
     2.5.  Additional remarks  . . . . . . . . . . . . . . . . . . .   8
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Integrated Sensing and Communications (ISAC) is emerging as a key
   enabler for next-generation wireless networks, integrating sensing
   and communication functionalities within a unified system.  By
   leveraging the same spectral, hardware, and computational resources,
   ISAC enhances network efficiency while enabling new capabilities such
   as high-resolution environment perception, object detection, and
   situational awareness.  This paradigm shift is particularly relevant
   for applications requiring both reliable connectivity and precise
   sensing, such as autonomous vehicles, industrial automation, and
   smart city deployments.  Given its strategic importance, ISAC has
   gained significant traction in standardization efforts.













Bernardos, et al.        Expires 4 January 2026                 [Page 2]

Internet-Draft           ISAC use case for CATS                July 2025


   While the ETSI Industry Specification Group (ISG) on ISAC has been
   established to explore technical requirements and use cases, the 3GPP
   organization has approved the 5G study work in its release 20 (rel-
   20) and initiated the investigation on ISAC-related features
   [TR.23.700-14].  Moreover, 3GPP has agreed to continue the sensing
   related research on future 6G systems.  Furthermore, research
   initiatives within the IEEE and IETF are investigating how ISAC can
   be integrated into network architectures, spectrum management, and
   protocol design, making it a critical area of development in the
   evolution of wireless networks.

   This document presents the ISAC as a typical CATS scenario, being
   supplementary to the CATS use cases as in
   [I-D.ietf-cats-usecases-requirements], to facilitate discussions on
   the potential challenges, and requirements.  Further, the document
   references the new draft on CATS reference model
   [IETF-CATS-RefModel-ACN] to briefly discuss how the ISAC case may
   leverage the model.

2.  Computing Aware distributed sensing for Integrated Sensing and
    Communications

   Integrated Sensing and Communications (ISAC) enables wireless
   networks to perform simultaneous data transmission and environmental
   sensing.  In a distributed sensing scenario, multiple hardware
   network entities, such as base stations, access points, or edge
   devices (e.g., wireless terminal equipment), and intelligent agents
   deployed as software instances on the entities (e.g., AI-agents) --
   collect raw sensing data from the environment.  These data can
   include radio frequency (RF) reflections, Doppler shifts, channel
   state information (CSI), or other physical-layer features that
   provide insights into object movement, material composition, or
   environmental conditions.  To extract meaningful information, the
   collected raw data must be aggregated and processed by a designated
   computing node with sufficient computational resources.  This
   requires efficient coordination between sensing nodes and computing
   resources to ensure timely and accurate analysis, making it a
   relevant scenario for Computing-Aware Traffic Steering (CATS) in
   IETF.

2.1.  CATS of ETSI ISAC

   This use case aligns with ongoing efforts in standardization bodies
   such as the ETSI ISAC Industry Specification Group (ISG),
   particularly Work Item #5 (WI#5), titled 'Integration of Computing
   with ISAC'.  WI#5 focuses on exploring different forms of computing
   integration within ISAC systems, including sensing combined with
   computing, communications combined with computing, and the holistic



Bernardos, et al.        Expires 4 January 2026                 [Page 3]

Internet-Draft           ISAC use case for CATS                July 2025


   integration of ISAC with computing.  The considerations outlined in
   this document complement ETSI's work by examining how computing-aware
   networking solutions, as developed within CATS, can optimize the
   processing and routing of ISAC sensing data.

   As an example, we can consider a network domain with multiple sites
   capable of hosting the ISAC computing "service", each with
   potentially different connectivity and computing characteristics.
   Figure 1 shows an exemplary scenario.  Considering the connectivity
   and computing latencies (just as an example of metrics), the best
   service site is #n-1 in the example used in the Figure.  Note that in
   the figure we still use the old terminology in which by ICR we mean
   Ingress CATS-Forwarder [I-D.ietf-cats-framework], and by ECR we mean
   Egress CATS-Forwarder.





































Bernardos, et al.        Expires 4 January 2026                 [Page 4]

Internet-Draft           ISAC use case for CATS                July 2025


                                ________________
                               (     ---------- )
                              (      |        |  )
                            (     ---------- |   )
      ________________     (     |        | |    )     _______________
     (     ---------- )    (   ---------- | |    )    (    ---------- )
    (      |        |  )   (   |service | |-     )   (     |        |  )
   (     ---------- |   )  (   |contact | |      )  (    ---------- |  )
   (     |        | |   )  (   |instance|--      )  (    |        | |  )
   (   ---------- | |   )   (  ----------       )   (  ---------- | |  )
   (   |service | |-    )    ( Serv. site #N-1 )    (  |service | |-   )
   (   |contact | |     )     -------+----------     (  |contact | |   )
   (   |instance|--    )   Computing  \              (  |instance|--   )
    (  ----------     )    delay:4ms   \              ( ----------     )
     ( Serv. site #1 )           --------+--           ( Serv. site #N )
      -------+--------       ----| ECR#N-1 |----        ---------+-----
              \  Computing --     -----------    --  Computing  /
               \ delay:10ms      Networking          delay:5ms /
             ---+-----           delay:7ms              ------+--
           ( | ECR#1 |            //                    | ECR#N | )
          (  ---------           //                     ---------  )
         ( Networking           //                       Networking )
        (  delay:5ms           //                         delay:15ms )
       (                      //                                      )
       (                     //                                       )
        (                   //                                       )
         (                 //                                       )
          (               //                                       )
           (       ---------                     ---------        )
            -------| ICR#1 |---------------------| ICR#2 |--------
                   ---------           __         ---------
                   (·)   (·)        / (  )           (·)
                  (·)   -------   -  (    )         (·)
                 (·)    | UE2 | /     (__) \      (·)
                (·)     -------    /         -   -------
               (·)               /  (sensing  \  | UE3 |
             -------   ---------                 -------
             | UE1 | /
             -------

                        Figure 1: Exemplary scenario










Bernardos, et al.        Expires 4 January 2026                 [Page 5]

Internet-Draft           ISAC use case for CATS                July 2025


2.2.  CATS of 3GPP ISAC

   3GPP has specified in the stage-1 document [TR.22.870] the
   requirements & objectives of ISAC service.  Fundamentally, the ISAC
   service includes offering wide area multi-dimensional sensing that
   provides spatial information about non-connected objects as well as
   connected devices and their movements and surroundings.
   Successively, the 3GPP SA2 WG has approved a study item (SID) in its
   rel-20 and initiated the investigation on ISAC-related features
   [TR.23.700-14].  Moreover, 3GPP has agreed to continue the sensing
   related research on the on-going 6G studies.

   The Figure 2 describes a possible sensing architecture that conforms
   to the architectural assumptions as in [TR.23.700-14].  The figure
   shows that there could be multiple authorized sensing entities, e.g.,
   (R)ANs, TEs (with sensors).  Also, a new sensing function, i.e.,
   SeNF, is promoted.  Note the name of the sensing function is still up
   for discussion.

          SeNF: Sensing Network Function
          Sensing Entities: TE (Terminal Equip), (g)RAN
                 ...........................................
                 :                                +-----+  :   +-------+
                 :                                | NEF |------| AF/AS |
                 :      +-----+                   +-----+  :   +-------+
                 :      | AMF |                     |      :
                 :      +-----+                     |      :
                 :         |       +------+      +-----+   :
                 :   ......|.......| SeNF |------| PCF |   :
                 :   :     |       +------+      +-----+   :
                 :   :     |      /                        :
       +------+  :   :     |     /                         :
       | TE#1 |......:     |    /                          :
       +------+  :   :     |   /                           :
       +------+......:  +------+        +-----+            :  +--------+
       | TE#2 |--:------|(g)RAN|--------| UPF |------------:--|  Data  |
       +------+  :      +------+        +-----+            :  | Network|
                 :                                         :  +--------+
                 :.........................................:


                  Figure 2: 3GPP ISAC exemplary scenario

   There might be multiple SeNFs in a wireless network, with each SeNF
   capable of handling both the CP and UP of the sensing service.  A
   SeNF can process received sensing data, aggregate sensing reports,
   run detection algorithms, and filter noise - to produce the sensing
   result that meets the service request.  A SeNF may also expose the



Bernardos, et al.        Expires 4 January 2026                 [Page 6]

Internet-Draft           ISAC use case for CATS                July 2025


   sensing results to external App servers (namely AS'es).  Given the
   complex yet computationally-heavy tasks as conducted by the SeNF, the
   selection of an optimal SeNF (among all SeNF candidates) embodies the
   principles of CATS.

   Sensing entities on (authorized) UEs may instantiate as software AI-
   agents with sensing functionality.  If there is a large amount of
   collected sensing measurement data, then there might be a need to
   expose (i.e., transmit) the data to (external) service instances
   (e.g., in local premise) for optimized processing (if the local
   compute power at an agent is insufficient or is overloaded).  After
   that can the processed sensing results be sent to the original
   sensing requestor for further processing.  This kind of task
   redirection for better processing efficiency conforms to what the
   CATS strives for.

2.3.  Relation to CATS

   In the distributed sensing scenario, the sensed data collected by
   multiple nodes must be efficiently routed to a computing node capable
   of processing it.  The choice of the computing node depends on
   several factors, including computational load, network congestion,
   and latency constraints.  CATS mechanisms can optimize the selection
   of the processing node by dynamically steering the traffic based on
   computing resource availability and network conditions.
   Additionally, as sensing data is often time-sensitive, CATS can
   ensure low-latency paths while balancing computational demands across
   different processing entities.  This capability is essential for
   real-time applications such as cooperative perception for autonomous
   systems, industrial monitoring, and smart city infrastructure.

   Further, the draft [IETF-CATS-RefModel-ACN] has proposed a CATS
   reference model that operates on general reference points for the
   signaling exchanges of various types of metrics, i.e., network,
   compute and the new AI-agent metrics as defined in the draft.  The
   ISAC scenario for CATS may leverage the model for better operations.
   For example, the IETF Draft of CATS reference model for ACN defines
   the reference points or RPs, e.g., the RPs between C-PS --- C-NMA,
   C-PS --- C-SMA, and AIA (AI-agent) --- C-PS, etc.  The ISAC scenario
   may leverage the AI-agent logics and extend the RPs to sensing: AIA
   (sensing) --- C-PS.  In some scenario in the context of 3GPP, here
   the C-PS can even be a 3rd-party entity like AF/AS.

2.4.  Requirements

   Several challenges need to be addressed for efficient distributed
   sensing in ISAC-enabled networks:




Bernardos, et al.        Expires 4 January 2026                 [Page 7]

Internet-Draft           ISAC use case for CATS                July 2025


   *  Traffic Steering and Resource Allocation: Ensuring that sensing
      data is directed to the most suitable computing node while
      considering both network conditions and processing availability.

   *  Latency Sensitivity: Many ISAC applications require near-real-time
      processing, necessitating low-latency and high-reliability data
      forwarding strategies.

   *  Data Synchronization: Sensing nodes may have different
      perspectives on the environment, requiring synchronization and
      fusion of data streams before processing.

   *  Scalability: As the number of participating sensing nodes
      increases, mechanisms must efficiently distribute and balance the
      computational workload.

   *  Security and Privacy: Sensed data may contain sensitive
      information, requiring mechanisms for secure transmission and
      processing.

   *  Holistic Reference Model: Potentially a general CATS reference
      model with reference points for the signaling exchanges of various
      types of metrics among CATS entities and sensing entities.

2.5.  Additional remarks

   The integration of ISAC-based distributed sensing into CATS
   frameworks may require enhancements in computing-aware routing
   protocols, traffic steering algorithms, signaling mechanisms, and
   potentially the integration of the CATS reference model.
   Standardization efforts could focus on defining metrics for
   computing-aware path selection that is based not only on the existing
   CATS metrics but also with any future extensions (e.g., 'AI-agent
   metrics' in [IETF-CATS-RefModel-ACN]), developing mechanisms for
   real-time coordination between sensing and computing nodes, and
   ensuring interoperability with existing network architectures.
   Furthermore, coordination with ETSI & 3GPP may help align the
   development of computing-aware ISAC networking solutions with ongoing
   standardization efforts in computing integration, ensuring cross-
   industry compatibility and deployment feasibility.

3.  IANA Considerations

   N/A.







Bernardos, et al.        Expires 4 January 2026                 [Page 8]

Internet-Draft           ISAC use case for CATS                July 2025


4.  Security Considerations

   TBD.

5.  Acknowledgments

   The work of Carlos J.  Bernardos in this document has been partially
   supported by the Horizon Europe MultiX (Grant Agreement No.
   101192521) and Hexa-X-II (Grant Agreement No. 101095759) projects.

6.  Informative References

   [I-D.ietf-cats-framework]
              Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
              Drake, "A Framework for Computing-Aware Traffic Steering
              (CATS)", Work in Progress, Internet-Draft, draft-ietf-
              cats-framework-10, 24 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cats-
              framework-10>.

   [I-D.ietf-cats-usecases-requirements]
              Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
              "Computing-Aware Traffic Steering (CATS) Problem
              Statement, Use Cases, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-cats-usecases-requirements-07,
              10 June 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-cats-usecases-requirements-07>.

   [IETF-CATS-RefModel-ACN]
              Jiang, T., et al., "CATS Reference Model for AI-Agent
              Communication Network",  
              https://datatracker.ietf.org/doc/draft-jiang-cats-
              reference-acn, June 2025.

   [TR.22.870]
              "3GPP TR 22.870 v0.3.0: Study on 6G Use Cases and Service
              Requirements; Stage 1, Rel-20",  3GPP TR 22.870, May 2025.

   [TR.23.700-14]
              "3GPP TR 23.700-14 v0.2.0: Study on Stage 2 for Integrated
              Sensing and Communication",  3GPP TR 23.700-14, June 2025.

Authors' Addresses








Bernardos, et al.        Expires 4 January 2026                 [Page 9]

Internet-Draft           ISAC use case for CATS                July 2025


   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   28911 Leganes, Madrid
   Spain
   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/


   Alain Mourad
   InterDigital Europe
   Email: Alain.Mourad@InterDigital.com
   URI:   http://www.InterDigital.com/


   Tianji Jiang
   China Mobile
   Email: tianjijiang@yahoo.com
































Bernardos, et al.        Expires 4 January 2026                [Page 10]


name: draft-ahn-opsawg-5g-security-i2nsf-framework
rev: 00
title: An Integrated Security Service System for 5G Networks using an I2NSF Framework
time: 2026-01-09T07:09:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T08:20:44Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:10.243395+00:00
abstract:
This document presents an integrated framework for automated security
   management in 5G edge networks using the Interface to Network
   Security Functions (I2NSF) architecture.  The proposed system
   leverages Intent-Based Networking (IBN) to allow users or
   administrators to declare high-level security intents, which are then
   translated into enforceable network and application policies.
   Network-level policies are delivered to 5G core components via the
   Network Exposure Function (NEF), while application-level policies are
   enforced directly at user equipment through distributed IBN
   Controllers.  This architecture supports adaptive, context-aware, and
   distributed policy enforcement, enabling real-time response to
   dynamic edge conditions and user mobility scenarios such as
   handovers.  By integrating closed-loop monitoring and analytics, the
   system ensures consistent and autonomous security across
   heterogeneous 5G environments.

full_text:
Operations and Management Area Working Group                 Y. Ahn, Ed.
Internet-Draft                                             J. Jeong, Ed.
Intended status: Informational                   Sungkyunkwan University
Expires: 8 January 2026                                           Y. Kim
                                                     Soongsil University
                                                             7 July 2025


  An Integrated Security Service System for 5G Networks using an I2NSF
                               Framework
            draft-ahn-opsawg-5g-security-i2nsf-framework-00

Abstract

   This document presents an integrated framework for automated security
   management in 5G edge networks using the Interface to Network
   Security Functions (I2NSF) architecture.  The proposed system
   leverages Intent-Based Networking (IBN) to allow users or
   administrators to declare high-level security intents, which are then
   translated into enforceable network and application policies.
   Network-level policies are delivered to 5G core components via the
   Network Exposure Function (NEF), while application-level policies are
   enforced directly at user equipment through distributed IBN
   Controllers.  This architecture supports adaptive, context-aware, and
   distributed policy enforcement, enabling real-time response to
   dynamic edge conditions and user mobility scenarios such as
   handovers.  By integrating closed-loop monitoring and analytics, the
   system ensures consistent and autonomous security across
   heterogeneous 5G environments.

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





Ahn, et al.              Expires 8 January 2026                 [Page 1]

Internet-Draft  An Integrated Security Service System fo       July 2025


Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  An I2NSF-Based Architecture for 5G Edge Security
           Management  . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  The Procedure for I2NSF-Based 5G Edge Security Management . .   7
   5.  Security Considerations Sections  . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Network softwarization has become a fundamental approach for
   delivering network services across various infrastructures, including
   5G mobile networks [TS-23.501], cloud computing platforms, and edge
   computing environments.  This paradigm is enabled through key
   technologies such as Network Functions Virtualization (NFV)
   [ETSI-NFV] and Software-Defined Networking (SDN) [RFC7149].  In
   addition, Intent-Based Networking (IBN) [RFC9315]
   [Survey-IBN-CST-2023] serves as a foundation for implementing
   intelligent behaviors in both network-level and application-level
   services.  As networks continue to evolve in this software-driven
   direction, the emergence of 5G introduces new challenges,
   particularly in the realm of security.

   As mobile networks evolve toward 5G, the increasing complexity of
   network functions and the widespread deployment of edge devices such
   as IoT nodes, user equipment (UE), and application functions (AFs)



Ahn, et al.              Expires 8 January 2026                 [Page 2]

Internet-Draft  An Integrated Security Service System fo       July 2025


   [TS-23.501] introduce significant challenges to existing security
   models.  These environments are inherently dynamic, heterogeneous,
   and latency-sensitive, making it difficult for traditional rule-based
   configurations, which are typically static and manually managed, to
   respond effectively to changing conditions.  In particular, security
   operations at the edge require more contextual awareness, automation,
   and adaptability than ever before.

   Intent-Based Networking (IBN) provides a promising paradigm to meet
   these requirements.  It enables operators or users to declare high-
   level goals, or intents, which the system can automatically translate
   into enforceable security and network policies [TS-28.312].  These
   policies may range from abstract service-level objectives to fine-
   grained access control rules.  By automating this translation and
   enforcement process, the network gains the ability to respond
   autonomously to operational demands without requiring manual
   intervention.  This model supports closed-loop control, where real-
   time feedback mechanisms continuously refine and adapt system
   behavior based on evolving context and intent.

   This document defines an intent-based framework for edge security
   management in the context of 5G systems.  The framework builds upon
   the service-based architecture (SBA) defined in 3GPP 5G and beyond,
   and introduces a layered approach that includes intent translation,
   policy generation, enforcement, and monitoring.  It integrates
   seamlessly with existing 3GPP network functions such as the Policy
   Control Function (PCF) [TS-29.520], Access and Mobility Management
   Function (AMF), Session Management Function (SMF), and Network Data
   Analytics Function (NWDAF) [TS-23.288].  The aim is to deliver
   scalable and adaptive security control across heterogeneous edge
   domains through policy-driven orchestration.

   Furthermore, the framework is designed to support mobility scenarios,
   including handovers between gNBs and session migration across
   multiple User Plane Functions (UPFs).  By dynamically enforcing
   intents at the edge, the system maintains consistent and context-
   aware security postures even in the presence of mobility events.
   This capability strengthens the resilience and responsiveness of the
   network while laying a foundation for secure, automated, and
   intelligent 5G services.  The proposed framework also aligns with
   long-term goals of zero-touch security, AI-driven orchestration, and
   intent-based policy automation within future mobile network
   infrastructures.








Ahn, et al.              Expires 8 January 2026                 [Page 3]

Internet-Draft  An Integrated Security Service System fo       July 2025


2.  Terminology

   This section provides definitions of the key terms and concepts used
   throughout this document.  The terminology is intended to establish a
   common understanding of the architectural elements, interfaces, and
   operational principles discussed in the context of intent-based
   security management in 5G networks.  These terms are used to describe
   5G Network automation based on the Intent-Based Networking (IBN) and
   Interface to Network Security Functions (I2NSF) framework.

   *  Intent: It refers to a set of operational objectives and expected
      outcomes that a network should fulfill, expressed in a declarative
      manner without specifying the implementation details or the exact
      procedures to achieve them [RFC9315].  Intents can be represented
      using XML [RFC6020] [RFC7950] or YAML [YAML] formats, and may be
      delivered to the target components through protocols such as
      NETCONF [RFC6241], RESTCONF [RFC8040], or via standard REST APIs
      [REST].

   *  IBN User Function (IUF): It is typically accessed via a web-
      browser interface, which allows Mobile Object administrators to
      input network intents for the IBN Control Function (ICF).  These
      intents serve as strategic objectives that guide the generation of
      security and network policies within the system.

   *  IBN Control Function (ICF): The ICF operates as a core component
      of the I2NSF architecture deployed within the 5G network.  It is
      responsible for managing and orchestrating security enforcement
      functions by translating the intents from the IUF into actionable
      policies, and by selecting appropriate 5G Network Functions (NFs)
      for their execution.

   *  Developer's Management Function (DMF): It is a component within
      the Interface to Network Security Functions (I2NSF) framework that
      acts as a provider of Network Security Functions (NSFs).  It's
      responsible for registering the capabilities of these NSFs with
      the Security Controller, essentially making them available for use
      in enforcing security policies.

   *  Security Control Function (SCF): SCF strengthens network security
      by generating low-level policies to modify and supplement the
      network configuration based on the delivered network policy and
      delivering these to the relevant individual NFs.








Ahn, et al.              Expires 8 January 2026                 [Page 4]

Internet-Draft  An Integrated Security Service System fo       July 2025


   *  Security Data Analytics Function (SDAF): It collects and analyzes
      monitoring data to verify whether the policies generated based on
      intents have been properly enforced by the network security
      functions, and to evaluate the performance and functionality of
      the security services.

   *  Network Security Function (NSF): NSF is a network security
      function that provides actual security services based on policies
      generated based on the user's intent.  It actually executes
      security tasks such as blocking or allowing traffic based on the
      policy delivered from ICF.

3.  An I2NSF-Based Architecture for 5G Edge Security Management

   This section defines a comprehensive framework for 5G security
   management automation by introducing its essential components and
   explaining how each of them is designed to interconnect with
   functions in the 5G core networks [TS-23.501].  The framework is
   grounded in intent-based networking principles, which enable high-
   level user or application intents to be automatically translated into
   actionable policies.  These policies are then enforced and monitored
   across both the core and edge domains without requiring manual
   intervention.

   As 5G networks become more distributed and support a growing number
   of latency-sensitive services and heterogeneous devices, traditional
   static security mechanisms struggle to cope with the dynamic nature
   of threats and the scale of real-time traffic.  Manual configuration
   is no longer feasible in such environments, making automated security
   orchestration essential to maintain consistent protection, reduce
   response time, and minimize human error.

   To realize this, the framework leverages a set of I2NSF-based
   functional modules that collectively support policy translation,
   enforcement, and real-time monitoring.  By integrating these
   components into the 5G architecture, the system enables scalable,
   adaptive, and context-aware security operations tailored to the needs
   of dynamic and heterogeneous edge environments.













Ahn, et al.              Expires 8 January 2026                 [Page 5]

Internet-Draft  An Integrated Security Service System fo       July 2025


  +------------------------------------+ +-----------------------------+
  | 5G Core NFs                        | |                             |
  | +-----+  +-----+  +-----+  +-----+ | | +-----+  +-----+  +------+  |
  | |NSSF |  | UDM |  | NRF |  | PCF | | | | IUF |  | ICF |  | SDAF |  |
  | +---+-+  +---+-+  +---+-+  +---+-+ | | +--+--+  +--+--+  +--+---+  |
  |     |        |        |        |   | |    |        |        |      |
  | --+-+------+-+------+-+---+--+-+---+-+----+---+----+----+---+----- |
  |   |        |        |        |     | |        |         |          |
  | +-+---+  +-+---+  +-+---+  +-+---+ | |     +-----+   +-----+       |
  | | AUSF|  | AMF |  | SMF |  | NEF | | |     | DMF |   | SCF |       |
  | +-----+  +-+-+-+  +--+--+  +-----+ | |     +-----+   +-----+       |
  |            | |       |             | |                             |
  |      +-----+ +--+    +------+      | |  AFs for Security Services  |
  +------+----------+-----------+------+ +-----------------------------+
         |          |           |
      +--+--+   +---+---+    +--+---+   +--+---+   +--------------+
      | UE  +---+ (R)AN +----+ UPFs +---+ NSFs +---+ Data Network |
      +-----+   +-------+    +--+---+   +------+   +--------------+

     Figure 1: I2NSF-Based Security Management Framework for 5G Edge
                                 Networks

   Figure 1 illustrates a 5G edge security service architecture based on
   the I2NSF framework [RFC8329], implemented as an Intent-Based System
   (IBS).  An intent-based management strategy is required between the
   5G Core network and distributed edge domains to enable the autonomous
   configuration and security enforcement of edge functions such as User
   Equipment (UEs), as described in the IETF draft on intent-based
   network management automation.

   On the right side of the architecture, the AFs for Security Services
   represent application-layer functions that initiate and manage high-
   level security intents.  These functions serve as the interface
   between external users or applications and the intent-based security
   system.  This service is composed of several key modules, including
   the Intent-Based Use Function (IUF), the Intent Control Function
   (ICF), the Security Control Function (SCF), the Developer's
   Management Function (DMF), and the Security Data Analytics Function
   (SDAF), which collectively support intent interpretation, policy
   translation, enforcement, and monitoring across the network.

   The security intent generated by the Intent-Based Network Use
   Function (IUF) is first interpreted as a high-level objective
   reflecting the desired behavior of the network or specific
   applications.  This intent is then processed by the Intent-Based
   Network Control Function (ICF), which plays a central role in
   translating the abstract intent into concrete policies.  Through this
   translation process, two distinct types of policies are created: a



Ahn, et al.              Expires 8 January 2026                 [Page 6]

Internet-Draft  An Integrated Security Service System fo       July 2025


   network policy, which governs how the underlying network should
   behave (e.g., traffic routing, filtering, or QoS enforcement), and an
   application policy, which defines how specific applications or
   devices should operate under given security constraints.

   Once these policies are generated, they are delivered to the 5G Core
   Network via the Network Exposure Function (NEF).  The NEF serves as
   the gateway between external application functions and the internal
   control plane of the 5G Core.  To support flexible deployment and
   orchestration, these components can be implemented as containerized
   microservices and managed using Kubernetes[Kubernetes].  By passing
   the policies through the NEF, the system enables relevant 5G Core
   components such as the Policy Control Function (PCF), Session
   Management Function (SMF), and Access and Mobility Management
   Function (AMF) to enforce the translated policies in real time.  This
   ensures that the original user or service intent is consistently and
   dynamically applied throughout the network.

4.  The Procedure for I2NSF-Based 5G Edge Security Management

   This testbed demonstrates a use case where high-level user intents
   are automatically translated into enforceable network and application
   policies.  Leveraging the I2NSF (Interface to Network Security
   Functions) framework [RFC8329] and deployed on the free5GC platform,
   this architecture enables automated, intent-driven security
   management that reduces the reliance on manual configuration and
   static rule sets.

   The system is designed to support distributed policy enforcement by
   integrating key I2NSF components such as the Intent-Based Networking
   Use Function (IUF), Intent Control Function (ICF), Security Control
   Function (SCF), and Security Data Analytics Function (SDAF).  These
   components work collaboratively to process intents, generate
   appropriate policies, and enforce them dynamically across both the
   core network and the edge.


                 +--------------+
                 |User Equipment|
                 +--------------+
                        ^  Appplication Policy
                        |    (Configuration)
                        |          +-------------------+
+-----+             +--------+     |    IBN Control    |         +----------+
| NEF |<------------+ Router |<----+      Function     |<--------+ IBN Use  |
+-----+   Network   +--------+     |(Intent Translator)|  Intent | Function |
5G Core   Policy                   +-------------------+         +----------+
Network (Firewall& WebFilter)



Ahn, et al.              Expires 8 January 2026                 [Page 7]

Internet-Draft  An Integrated Security Service System fo       July 2025


   Figure 2: The Procedure of Policy Generation and Delivery for 5G
                             Edge Network

   Figure 2 shows the procedure for 5G Edge Security Management
   Automation, specifically illustrating the creation of user intents
   and the generation of corresponding network policies and application
   policies.  The process begins when a user or administrator expresses
   a security-related intent via the IBN Use Function (IUF).  This
   intent, representing a high-level goal such as restricting access to
   certain websites or monitoring device behavior, is passed to the IBN
   Control Function (ICF).  The ICF, equipped with an Intent Translator,
   converts this intent into both network-level and application-level
   policies.  The translated network-level policies are forwarded
   through the router to the 5G Core's Network Exposure Function (NEF)
   [TS-29.503], while the application-level policies are delivered
   directly to the User Equipment (UE).  This enables consistent policy
   enforcement from the core network to the device edge.


           User Equipment 1 (SmartPhone)  User Equipment 2 (IoT Device)
              +---------------------+        +---------------------+
              | +-----------------+ |        | +-----------------+ |
              | |Service Functions| |        | |Service Functions| |
              | |      (SFs)      | |        | |      (SFs)      | |
              | +-----------------+ |        | +-----------------+ |
              |          ^ |        |        |          ^ |        |
              |Monitoring| |  API   |        |Monitoring| |  API   |
              |   Data   | |Command |        |   Data   | |Command |
              |          | V        |        |          | V        |
              |   +--------------+  |        |   +--------------+  |
              |   |IBN Controller|  |        |   |IBN Controller|  |
              |   +--------------+  |        |   +--------------+  |
              |          ^  |       |        |        ^       |    |
              +----------+--+-------+        +--------+-------+----+
                         |  |                         |       |
                         |  +---------------------------------+
                         |                            |       |
                         +--------------+-----+-------+----+  +
                   Application Policy   |     |            |  |
                    (Configuration)     |     |            |  |
                                        |     |            |  |
            +---------------------------+-----+-----+      |  |
            |                           |     |     |      |  |
+--------+  |   +------+   +-----+   +--+--+  |     |      |  |
|  Data  +--|---+ NSFs +---+ UPF +---+ gNB |  |     |      |  |
| Network|  |   +------+   +--+--+   +--+--+  |     |      |  |
+--------+  |                 |         |     |     |      |  |
            |              +--+--+   +--+--+  |     |      |  |



Ahn, et al.              Expires 8 January 2026                 [Page 8]

Internet-Draft  An Integrated Security Service System fo       July 2025


            |              | SMF |   | AMF +--+     |      |  |
            |              +--+--+   +--+--+        |      |  |
            |                 |         |           |    +-+--+---+
            | ----+--------+--+-----+---+----+---   |    | Router +---+
            |     |        |        |        |      |    +---+----+   |
            |  +--+--+  +--+--+  +--+--+  +--+--+   |        |        |
            |  | SCF |  | DMF |  | SCF |  | NEF |<--+--------+        |
            |  +--+--+  +--+--+  +--+--+  +--+--+   | Network         |
            |                                       | Policy          |
            |                                       | (Firewall       |
            +---------------------------------------+ & Web Filter)   |
                          5G Core Network                             |
                                                           Monitoring |
                                                             Report   |
                                                                      V
                                                        +-------------------+
                                                        |   Security Data   |
                                                        | Analytics Function|
                                                        +---------+---------+
                                                                  |
                                                  +---------------+---------+
                                                  | Monitoring Data Storage |
                                                  +-------------------------+

    Figure 3: The Procedure within an I2NSF-Based Framework for 5G
                       Edge Security Management

   Figure 3 illustrates the procedure of how the intent-driven network
   policies and application policies are applied across both the 5G core
   network and user equipment.  These policies are then propagated
   throughout the 5G network to support coordinated and consistent
   security enforcement.  Network-level policies are distributed to core
   network functions [TS-23.501], where they help guide the overall
   behavior and resource allocation of the system in alignment with the
   user's intent.  At the same time, application-level policies are
   delivered to various user devices, such as smartphones and IoT nodes,
   which have embedded controllers capable of interpreting and enforcing
   the received policies locally.

   This allows each device to autonomously adjust its behavior according
   to the defined security or operational requirements.  In parallel,
   network-based security functions are also engaged to apply the
   necessary controls, such as access restrictions or traffic filtering,
   ensuring that both the core and the edge of the network operate
   securely and in harmony with the original intent.  This distributed
   approach enables flexible, scalable, and adaptive policy enforcement
   across the entire mobile network environment [TS-23.288].




Ahn, et al.              Expires 8 January 2026                 [Page 9]

Internet-Draft  An Integrated Security Service System fo       July 2025


   To support adaptive security validation, each user equipment's IBN
   Controller periodically generates monitoring reports based on local
   policy enforcement status.  These reports are sent to the Security
   Data Analytics Function (SDAF), which analyzes the monitoring data to
   evaluate whether the applied policies are effectively enforced.  All
   collected data is stored in a centralized Monitoring Data Storage
   module, enabling real-time policy validation and historical auditing.
   The related steps are as follows:

   *  Steps 1-2: An intent is sent from an application within the 5G
      Core to the IBN Control Function, where it is translated into
      network and application policies.  This marks the beginning of
      intent-driven automation for security management.

   *  Step 3: The network policy is delivered to relevant 5G Core
      functions and connected security components.  These components
      then prepare for the enforcement of the policy.

   *  Step 4: The application policy is sent to the IBN Controllers on
      the target user devices.  This allows the devices to receive
      instructions without direct user intervention.

   *  Step 5: Each device applies the policy to adjust its settings and
      behavior.  The changes take effect locally to reflect the system-
      wide intent.

   *  Step 6: Devices monitor their own status and send relevant data
      back to their IBN Controllers.  This ensures continuous awareness
      of policy impact at the device level.

   *  Step 7: IBN Controllers compile and forward the data as monitoring
      reports.  These reports provide a basis for evaluating the
      effectiveness of the applied policies.

   *  Step 8: The reports are analyzed to check if the policies are
      working as intended, and the results are stored for future use.
      This completes the feedback loop that enables adaptive policy
      refinement.













Ahn, et al.              Expires 8 January 2026                [Page 10]

Internet-Draft  An Integrated Security Service System fo       July 2025


   Through this process, the system enables intent-driven security
   management that spans from core network functions to individual user
   devices.  By translating high-level intents into enforceable policies
   and continuously monitoring their effects, the architecture supports
   real-time adaptation to network conditions and user behaviors.  This
   ensures that security enforcement remains consistent, context-aware,
   and autonomous throughout distributed edge environments.  Moreover,
   the closed-loop structure provides a foundation for scalable and
   self-optimizing policy management, which is essential for future 5G
   edge-native networks.

   Also, the proposed system extends the core components such as the
   Intent-Based Networking Use Function (IUF), Intent Control Function
   (ICF), and distributed enforcement modules to operate in tandem with
   the handover procedures defined in 3GPP specifications.  This helps
   keep security consistent and smart across the edge network where
   quick response and local control are especially important.  This
   approach can also be applied to mobility scenarios where intent-
   driven security policies need to dynamically migrate and be re-
   enforced as User Equipment (UE) transitions between gNBs.

5.  Security Considerations Sections

   In the context of intent-based edge security management in 5G
   networks, several important security aspects must be considered to
   ensure robust and trustworthy system behavior.  One key concern
   involves the potential for malicious manipulation of user intents.
   Since intents are high-level expressions of user goals that drive the
   automated generation of network and application policies, any
   unauthorized alteration could lead to unintended or insecure
   outcomes.  Ensuring that each intent originates from a trusted source
   and is protected by integrity validation mechanisms is therefore
   essential.

   Another important consideration is the accuracy and reliability of
   the policy translation and enforcement process.  When translating
   abstract intents into concrete policies, the system must preserve the
   user's original intent without introducing misconfigurations or
   inconsistencies.  Incorporating validation checks and feedback
   mechanisms helps ensure that policies are correctly interpreted and
   consistently applied across the network.  To further enhance this
   process, deep learning techniques [Deep-Learning] can be employed to
   detect anomalies, learn from past policy enforcement outcomes, and
   adaptively improve the translation logic based on contextual patterns
   and historical data.






Ahn, et al.              Expires 8 January 2026                [Page 11]

Internet-Draft  An Integrated Security Service System fo       July 2025


6.  IANA Considerations

   This document does not require any IANA actions.

7.  References

7.1.  Normative References

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
              <https://www.rfc-editor.org/info/rfc7149>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
              <https://www.rfc-editor.org/info/rfc8329>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/info/rfc9315>.

7.2.  Informative References

   [YAML]     Ingerson, B., Evans, C., and O. Ben-Kiki, "Yet Another
              Markup Language (YAML) 1.0",
              Available: https://yaml.org/spec/history/2001-05-26.html,
              October 2023.




Ahn, et al.              Expires 8 January 2026                [Page 12]

Internet-Draft  An Integrated Security Service System fo       July 2025


   [TS-23.501]
              "System Architecture for the 5G System (5GS)", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3144, September
              2023.

   [TS-28.312]
              "Intent Driven Management Services for Mobile Networks",
              Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3554, September
              2023.

   [TS-23.288]
              "Architecture Enhancements for 5G System (5GS) to Support
              Network Data Analytics Services", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3579, September
              2023.

   [TS-29.503]
              "Service-Based Interface Specifications for the Network
              Exposure Function (NEF)", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3342, September
              2023.

   [TS-29.520]
              "Network Data Analytics Services", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3355, September
              2023.

   [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural
              Framework", Available:
              https://www.etsi.org/deliver/etsi_gs/
              nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf,
              December 2014.

   [REST]     Fielding, R. and R. Taylor, "Principled Design of the
              Modern Web Architecture", ACM Transactions on Internet
              Technology, Vol. 2, Issue 2,,
              Available: https://dl.acm.org/doi/10.1145/514183.514185,
              May 2002.







Ahn, et al.              Expires 8 January 2026                [Page 13]

Internet-Draft  An Integrated Security Service System fo       July 2025


   [Deep-Learning]
              Goodfellow, I., Bengio, Y., and A. Courville, "Deep
              Learning", Publisher: The MIT Press,
              Available: https://www.deeplearningbook.org/, November
              2016.

   [Kubernetes]
              "Kubernetes: Cloud Native Computing Platform",
              Available: https://kubernetes.io/, March 2024.

   [Survey-IBN-CST-2023]
              Leivadeas, A. and M. Falkner, "A Survey on Intent-Based
              Networking",
              Available: https://ieeexplore.ieee.org/document/9925251,
              March 2023.

   [ClickINC-Sigcomm-2023]
              Xu, W., Zhang, Z., Feng, Y., Song, H., Chen, Z., Wu, W.,
              Liu, G., Zhang, Y., Liu, S., Tian, Z., and B. Liu,
              "ClickINC: In-network Computing as a Service in
              Heterogeneous Programmable Data-center Networks",
              Publisher: ACM SIGCOMM,
              Available: https://dl.acm.org/doi/10.1145/3603269.3604835,
              September 2023.

Acknowledgments

   This work was supported by Institute of Information & Communications
   Technology Planning & Evaluation (IITP) grant funded by the Korea
   Ministry of Science and ICT (MSIT) (No.  RS-2024-00398199 and RS-
   2022-II221015).

   This work was supported in part by Institute of Information &
   Communications Technology Planning & Evaluation (IITP) grant funded
   by the Korea Ministry of Science and ICT (MSIT) (No.  IITP-2025-RS-
   2022-II221199, Regional strategic industry convergence security core
   talent training business).

Contributors

   This document is made by the group effort of OPWAWG, greatly
   benefiting from inputs and texts by Linda Dunbar (Futurewei), Yong-
   Geun Hong (Daejeon University), and Joo-Sang Youn (Dong-Eui
   University).  The authors sincerely appreciate their contributions.

   The following are coauthors of this document:





Ahn, et al.              Expires 8 January 2026                [Page 14]

Internet-Draft  An Integrated Security Service System fo       July 2025


   Mose Gu
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: rna0415@skku.edu
   URI:   http://iotlab.skku.edu/people-Moses-Gu.php


Authors' Addresses

   Yoseop Ahn (editor)
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: ahnjs124@skku.edu
   URI:   http://iotlab.skku.edu/people-Ahn-Yoseop.php


   Jaehoon Paul Jeong (editor)
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4957
   Email: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


   Younghan Kim
   School of Electronic Engineering
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Seoul
   06978
   Republic of Korea



Ahn, et al.              Expires 8 January 2026                [Page 15]

Internet-Draft  An Integrated Security Service System fo       July 2025


   Email: younghak@ssu.ac.kr


















































Ahn, et al.              Expires 8 January 2026                [Page 16]


name: draft-fu-cats-flow-lb
rev: 03
title: Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS)
time: 2026-02-27T03:07:12Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T03:07:12Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:10.243403+00:00
abstract:
This document specifies a flow-level load balancing mechanism for
   Computing-Aware Traffic Steering (CATS) that reduces control plane
   overhead and improves resource utilization through data plane
   autonomous flow distribution.

full_text:
CATS                                                               H. Fu
Internet-Draft                                                D.H. Huang
Intended status: Standards Track                                 W. Duan
Expires: 30 August 2026                                           B. Tan
                                                         ZTE Corporation
                                                        26 February 2026


  Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS)
                        draft-fu-cats-flow-lb-03

Abstract

   This document specifies a flow-level load balancing mechanism for
   Computing-Aware Traffic Steering (CATS) that reduces control plane
   overhead and improves resource utilization through data plane
   autonomous flow distribution.

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 30 August 2026.

Copyright Notice

   Copyright (c) 2026 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.



Fu, et al.               Expires 30 August 2026                 [Page 1]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Architectural Model . . . . . . . . . . . . . . . . . . . . .   3
   6.  Control plane Operation . . . . . . . . . . . . . . . . . . .   5
   7.  Data Plane Operation  . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Computing-Aware Traffic Steering (CATS) [I-D.ldbc-cats-framework]
   directs traffic between service clients and providers based on real-
   time computing and network status.  While CATS operates as an overlay
   system for selecting optimal service instances, the framework does
   not assume specific data plane or control plane solutions.

   This document defines a flow-level load balancing mechanism
   addressing two operational challenges: control plane scalability
   limitations caused by reactive path computation, and resource
   utilization imbalances resulting from coarse-grained status
   reporting.  The mechanism enables the control plane to pre-compute
   multiple viable forwarding alternatives while allowing the data plane
   to autonomously distribute traffic across these alternatives using
   flow-based affinity.

2.  Requirements Language

   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.

3.  Terminology

   This document makes use of the terms defined in
   [I-D.ldbc-cats-framework].





Fu, et al.               Expires 30 August 2026                 [Page 2]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


   *  CATS Routing Table: Control plane structure containing service
      identifiers, network paths, service instances, and load sharing
      weights.

   *  CATS Forwarding Table: Data plane structure derived from CATS
      Routing Table via UCMP-to-ECMP expansion.

   *  Flow Affinity Table: Data plane table maintaining flow-to-
      forwarding-entry bindings.

4.  Problem Statement

   Current CATS implementations rely on periodic or threshold-triggered
   resource status reports to optimize service instance and path
   selection.  This approach creates uneven computing resource
   utilization when status updates lag behind actual load changes,
   potentially directing multiple requests to already overloaded
   instances.  Additionally, frequent metric fluctuations trigger
   repeated control plane path recalculation and policy updates,
   creating scalability constraints that incremental calculation alone
   cannot resolve.

5.  Architectural Model

   The Flow-Level Load Balancing of Computing-Aware Traffic Steering is
   constructed based on the framework established in the CATS
   architecture [I-D.ldbc-cats-framework](Figure 1 for a visual
   representation).























Fu, et al.               Expires 30 August 2026                 [Page 3]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


       +-----+              +------+           +------+
     +------+|            +------+ |         +------+ |
     |client|+            |client|-+         |client|-+
     +---+--+             +---+--+           +---+--+
         |                    |                  |
         | +----------------+ |            +-----+----------+
         +-+    C-TC#1      +-+      +-----+    C-TC#2      |
           |----------------|        |     |----------------|
           |     |C-PS#1    |    +------+  |CATS-Forwarder 4|
     ......|     +----------|....|C-PS#2|..|                |...
     :     |CATS-Forwarder 2|    |      |  |                |  .
     :     +----------------+    +------+  +----------------+  :
     :                                                         :
     :                                            +-------+    :
     :                         Underlay           | C-NMA |    :
     :                      Infrastructure        +-------+    :
     :                                                         :
     :                                                         :
     : +----------------+                +----------------+    :
     : |CATS-Forwarder 1|  +-------+     |CATS-Forwarder 3|    :
     :.|                |..|C-SMA#1|.... |                |....:
       +---------+------+  +-------+     +----------------+
                 |         |             |   C-SMA#2      |
                 |         |             +-------+--------+
                 |         |                     |
                 |         |                     |
              +------------+               +------------+
             +------------+ |             +------------+ |
             |  Service   | |             |  Service   | |
             |  Contact   | |             |  Contact   | |
             |  Instance  |-+             |  Instance  |-+
             +------------+               +------------+
              service site 1              service site 2

                    Figure 1: CATS-Functional-Components

   The mechanism operates through three functional entities: the Path
   Selector (C-PS) situated in the control plane collecting metrics via
   Metric Agents (C-SMA and C-NMA) and computing forwarding
   alternatives; the Forwarder operating in the data plane performing
   flow identification, affinity maintenance and packet forwarding; and
   the Metric Agents reporting service instance and network status to
   enable path computation.

   The Path Selector maintains the CATS Routing Table containing for
   each CS-ID a set of Forwarding Alternatives comprising network path
   identifiers, service instance identifiers, and load sharing weights
   representing desired traffic distribution proportions.  The Forwarder



Fu, et al.               Expires 30 August 2026                 [Page 4]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


   generates the CATS Forwarding Table through UCMP-to-ECMP expansion,
   creating a uniform lookup structure where each Forwarding Alternative
   appears in proportion to its weight, and maintains the Flow Affinity
   Table binding flow identifiers to specific forwarding entries.

6.  Control plane Operation

   The Path Selector identifies for each CS-ID the Service Instance Set
   containing all Forwarding Alternatives satisfying SLA requirements,
   computing load sharing weights based on service instance metrics,
   network path characteristics and policy objectives.  The resulting
   CATS Routing Table is translated into a CATS Forwarding Table and
   distributed to Forwarders..

   Figure 2 shows an example of a representation of multi-next-hop CATS
   routing table designed for a specific CS-ID1.

   +-------+-------+--------------------------------------------------+
   |       |       |              NEXT HOP                            |
   |VRF-ID |PREFIX +-----------------+-----------+--------------------+
   |       |       |SR-Policy        |Service SID| Load Sharing Ratio |
   +-------+-------+-----------------+-----------+--------------------+
   |100    |CS-ID1 |SR-Policy1(2ms)  |END.DX-1   | 20%                |
   |       |       +-----------------+-----------+--------------------+
   |       |       |SR-Policy1(2ms)  |END.DX-2   | 30%                |
   |       |       +-----------------+-----------+--------------------+
   |       |       |SR-Policy2(1.5ms)|END.DX-3   | 30%                |
   |       |       +-----------------+-----------+--------------------+
   |       |       |SR-Policy2(1.5ms)|END.DX-4   | 20%                |
   +-------+-------+-----------------+-----------+--------------------+

                 Figure 2: An example of CATS routing table


   Figure 3 shows an example of the CATS forwarding table following the
   changes.















Fu, et al.               Expires 30 August 2026                 [Page 5]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


         +-------+-------+-----------------+-----------+--------+
         |VRF-ID |PREFIX |SR-Policy        |Service SID| offset |
         +-------+-------+-----------------+-----------+--------+
         |100    |CS-ID1 |SR-Policy1(2ms)  |END.DX-1   | 0      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy1(2ms)  |END.DX-1   | 1      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy1(2ms)  |END.DX-2   | 2      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy1(2ms)  |END.DX-2   | 3      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy1(2ms)  |END.DX-2   | 4      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy2(1.5ms)|END.DX-3   | 5      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy2(1.5ms)|END.DX-3   | 6      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy2(1.5ms)|END.DX-3   | 7      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy2(1.5ms)|END.DX-4   | 8      |
         |       |       +-----------------+-----------+--------+
         |       |       |SR-Policy2(1.5ms)|END.DX-4   | 9      |
         +-------+-------+-----------------+-----------+--------+

               Figure 3: An example of CATS forwarding table


   To minimize control plane load, the Path Selector regenerates the
   CATS Routing Table only when metric changes cross predefined
   thresholds rather than reacting to every fluctuation, optionally
   employing hysteresis mechanisms to prevent rapid oscillation between
   configurations.

7.  Data Plane Operation

   Upon receiving a packet the Forwarder extracts the CS-ID and computes
   the flow identifier, typically derived from the five-tuple.  The
   Forwarder queries the Flow Affinity Table and if an existing binding
   is found forwards the packet using the bound entry.  For unbound
   flows the Forwarder computes a hash over the flow identifier, selects
   the CATS Forwarding Table entry at the resulting index, creates a
   Flow Affinity Entry binding the flow to this entry, and forwards the
   packet.








Fu, et al.               Expires 30 August 2026                 [Page 6]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


   The CATS Forwarding Table remains stable during flow affinity
   establishment ensuring consistent forwarding for all packets of a
   flow.  Table updates received from the Path Selector apply only to
   new flows while existing bindings remain valid until flow termination
   or timeout.

8.  Security Considerations

   The mechanism introduces potential denial of service vulnerabilities
   through Flow Affinity Table exhaustion if an attacker generates
   excessive new flows, mitigated by implementing binding creation rate
   limits.  Predictable flow identifiers could enable binding hijacking
   requiring cryptographically robust hash functions.  CATS Forwarding
   Tables distributed from Path Selector to Forwarder may expose
   topology information warranting protection during transmission.

9.  Acknowledgements

   To be added upon contributions, comments and suggestions.

10.  IANA Considerations

   TBA

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/info/rfc2119>.

   [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/info/rfc8174>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.





Fu, et al.               Expires 30 August 2026                 [Page 7]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

11.2.  Informative References

   [I-D.fu-cats-hybrid-fwd]
              Huakai.Fu, Yi, X., Pang, B., Yuan, D., Duan, W., and C.
              Miao, "Hybird Fordwarding of Computing-Aware Traffic
              Steering (CATS)", Work in Progress, Internet-Draft, draft-
              fu-cats-hybrid-fwd-00, 30 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-fu-cats-
              hybrid-fwd-00>.

   [I-D.fu-cats-muti-dp-solution]
              Huakai.Fu, Liu, B., Li, Z., Huang, D., Yuan, D., Ma, L.,
              and W. Duan, "Analysis for Multiple Data Plane Solutions
              of Computing-Aware Traffic Steering", Work in Progress,
              Internet-Draft, draft-fu-cats-muti-dp-solution-03, 19
              August 2025, <https://datatracker.ietf.org/doc/html/draft-
              fu-cats-muti-dp-solution-03>.

   [I-D.huang-service-aware-network-framework]
              Huang, D., Tan, B., and D. Yang, "Service Aware Network
              Framework", Work in Progress, Internet-Draft, draft-huang-
              service-aware-network-framework-01, 22 November 2022,
              <https://datatracker.ietf.org/doc/html/draft-huang-
              service-aware-network-framework-01>.

   [I-D.ietf-cats-usecases-requirements]
              Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
              "Computing-Aware Traffic Steering (CATS) Problem
              Statement, Use Cases, and Requirements", Work in Progress,
              Internet-Draft, draft-ietf-cats-usecases-requirements-14,
              2 February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-cats-usecases-requirements-14>.

   [I-D.lbdd-cats-dp-sr]
              Li, C., Du, Z., Drake, J., and shangyuxiang, "Computing-
              Aware Traffic Steering (CATS) Using Segment Routing", Work
              in Progress, Internet-Draft, draft-lbdd-cats-dp-sr-06, 13
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-lbdd-cats-dp-sr-06>.






Fu, et al.               Expires 30 August 2026                 [Page 8]

Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


   [I-D.ldbc-cats-framework]
              Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
              Drake, "A Framework for Computing-Aware Traffic Steering
              (CATS)", Work in Progress, Internet-Draft, draft-ldbc-
              cats-framework-06, 8 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ldbc-cats-
              framework-06>.

   [I-D.li-dyncast-architecture]
              Li, Y., Iannone, L., Trossen, D., Liu, P., and C. Li,
              "Dynamic-Anycast Architecture", Work in Progress,
              Internet-Draft, draft-li-dyncast-architecture-08, 16
              January 2023, <https://datatracker.ietf.org/doc/html/
              draft-li-dyncast-architecture-08>.

   [RFC7094]  McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
              "Architectural Considerations of IP Anycast", RFC 7094,
              DOI 10.17487/RFC7094, January 2014,
              <https://www.rfc-editor.org/info/rfc7094>.

Authors' Addresses

   Huakai Fu
   ZTE Corporation
   Wuhan
   China
   Email: fu.huakai@zte.com.cn


   Daniel Huang
   ZTE Corporation
   Nanjing
   China
   Email: huang.guangping@zte.com.cn


   Wei Duan
   ZTE Corporation
   Nanjing
   China
   Email: duan.wei1@zte.com.cn


   Bin Tan
   ZTE Corporation
   ShangHai
   China
   Email: tan.bin@zte.com.cn



Fu, et al.               Expires 30 August 2026                 [Page 9]


name: draft-templin-manet-inet
rev: 02
title: MANET Internetworking: Problem Statement and Gap Analysis
time: 2026-01-12T17:45:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T17:45:42Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:10.243406+00:00
abstract:
[RFC2501] defines a MANET as "an autonomous system of mobile nodes.
   The system may operate in isolation, or may have gateways to and
   interface with a fixed network" (such as the global public Internet).
   This document presents a MANET Internetworking problem statement and
   gap analysis.

full_text:
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Technology Innovation
Intended status: Informational                           D. J. Jakubisin
Expires: 16 July 2026         National Security Institute, Virginia Tech
                                                         12 January 2026


       MANET Internetworking: Problem Statement and Gap Analysis
                      draft-templin-manet-inet-02

Abstract

   [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
   The system may operate in isolation, or may have gateways to and
   interface with a fixed network" (such as the global public Internet).
   This document presents a MANET Internetworking problem statement and
   gap analysis.

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 16 July 2026.

Copyright Notice

   Copyright (c) 2026 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.



Templin & Jakubisin       Expires 16 July 2026                  [Page 1]

Internet-Draft            MANET Internetworking             January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  MANET Internetworking Problem Statement and Gap Analysis  . .   4
     3.1.  Problem 1: MANET Local Addressing . . . . . . . . . . . .   4
     3.2.  Problem 2: Autoconfiguration  . . . . . . . . . . . . . .   6
     3.3.  Problem 3: MANET-internal Communications  . . . . . . . .   7
     3.4.  Problem 4: MANET Peer to Internetwork Correspondent . . .   7
     3.5.  Problem 5: Internetwork Correspondent to MANET Peer . . .   8
     3.6.  Problem 6: Peer-to-Peer Between Different MANETs  . . . .   8
     3.7.  Problem 7: Stub MANET to Not-so-stubby MANET
           Connections . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Mobile Ad-hoc Networks (MANETs) [RFC2501] often include mobile nodes
   with limited range wireless transmission media interfaces that
   establish links via a dynamically changing set of neighbors within
   operational range.  Each mobile node engages a MANET routing protocol
   to discover links to first hop neighbors as well as multihop paths to
   reach other nodes beyond.  As IP routers [RFC0791][RFC8200], MANET
   routers represent multihop paths as "host routes" established through
   either proactive or reactive discovery.

   Individual MANETs typically include modest numbers of mobile nodes
   (e.g., O(1), O(10), O(100), etc.); this naturally limits the number
   of host routes needed in the local routing system.  MANETs can merge
   to form larger MANETs and/or partition into smaller MANETs according
   to dynamic network conditions such as mobility.  MANETs often operate
   autonomously unless or until they encounter Internetwork access
   points of opportunity.

   Data communications between two nodes within the same MANET follow
   host routes using MANET-internal links.  When a MANET router
   establishes an Internetwork link, it can provide "Internet
   connection-sharing" access to the rest of the MANET as a connected
   "stub" network.  Per [RFC2501], "stub networks carry traffic
   originating at and/or destined for internal nodes, but do not permit
   exogenous traffic to "transit" through the stub network".



Templin & Jakubisin       Expires 16 July 2026                  [Page 2]

Internet-Draft            MANET Internetworking             January 2026


   Practical applications however suggest that MANETs can act as either
   true stub networks (e.g., a cellphone providing a hotspot for a
   multihop WiFi SSID) or as "not-so-stubby" networks (e.g., Intelligent
   Transportation Systems where the 5G/6G "SideLink" service supports
   vehicle-to-vehicle (V2V) multihopping).  In the former case, the
   cellphone acts as an IP router for a stub WiFi MANET behind it and
   the individual WiFi nodes act as dependent nodes.  In the latter
   case, individual 5G/6G SideLink nodes can connect the stub MANETs
   they aggregate across not-so-stubby V2V multihop forwarding paths.
   MANET Internetworking must therefore be capable of accommodating all
   such scenarios.

   Google AI reports that: "There are currently more mobile phones than
   people in the world.  While the exact number fluctuates, estimates
   suggest there are over 12 billion mobile connections worldwide".
   Each mobile node that connects to the global public Internet can in
   some sense be regarded as a network access point for a singleton
   "MANET" with the potential to connect still larger MANETs.

   MANET Internetworking therefore regards the global Internet as a
   "network of (mobile ad-hoc) networks", and with unrestricted dynamic
   relationships between distinct local MANET routing regions joined by
   virtual circuits.  Figure 1 illustrates an example of two distinct
   MANETs joined by a virtual circuit using the Internet as transit:


                                .-(::::::::)
                             .-(::: Global ::)-.
                     +======(===================)======+
                     |        `-(: Internet :)-'       |
                     |           `-(::::::)-'          |
                     v                                 v
              .-(::::::::)                       .-(::::::::)
           .-(::::::::::::)-.                 .-(::::::::::::)-.
          (::::: MANET 1 :::::)              (::::: MANET 2 :::::)
            `-(::::::::::::)-'                 `-(::::::::::::)-'
               `-(::::::)-'                       `-(::::::)-'

                      Figure 1: MANET Internetworking

2.  MANET Use Cases

   MANETs have an important role in emergency response communications,
   disaster relief situations, communications in remote and rural areas,
   military operations, vehicular and swarm communications, and low-
   powered Internet of things (IoT) applications.  MANETs provide the
   ability to establish and maintain communications when infrastructure-
   based networks, such as 5G cellular communication systems, are not



Templin & Jakubisin       Expires 16 July 2026                  [Page 3]

Internet-Draft            MANET Internetworking             January 2026


   accessible.  As described above, MANETs may also provide Internet
   connectivity to internal nodes, for example, as a "stub" network via
   MANET routers which possess an Internetworking capability and an
   external connection to a radio access network.

   Example use cases of such MANETs include the following:

   *  Disaster Relief: Disaster situations may compromise network
      infrastructure, such as through the loss of base stations in a
      cellular radio access network (RAN).  In this scenario, MANET
      networks can play a role in closing coverage gaps through multi-
      hop routing to nodes within the coverage area of uncompromised
      base stations.  This use case is broadly applicable to any
      situation in which nodes are operating outside or at the periphery
      of RAN coverage.

   *  Tracking and Monitoring: Another example use case is the tracking
      and monitoring of data from low-cost low-power IoT devices
      ("tags") which may be placed on packages during shipment or
      storage.  Such devices may transition in and out of coverage of
      infrastructure-based networks, often being located in environments
      that are not conducive to RF propagation (e.g., shipping
      container, warehouse, etc.).  The ability to discover and connect
      to neighboring MANET-enabled devices and to establish Internet
      connectivity through such MANETs, enables real-time logistics and
      inventory data to be collected opportunistically.

   *  UAV Swarms: local communications within swarms for coordination
      and cooperation is a good use case for MANET networks due to the
      highly mobile dynamic nature of such networks.  Yet swarms may
      also benefit from connectivity to the Internet, or other external
      networks.  And in large swarm-based MANETs, routing of traffic
      through infrastructure networks to MANET endpoints, rather than
      traversing the entire MANET can improve communications throughput
      and reliability.

3.  MANET Internetworking Problem Statement and Gap Analysis

3.1.  Problem 1: MANET Local Addressing

   Each MANET router requires a unique IP address for MANET-local
   communications; the router often uses this same address to configure
   a unique "router ID".  For MANETs that are only intermittently
   connected to an Internetwork, these addresses must be generated from
   IP prefixes of scope greater than link-local but not associated with
   infrastructure aggregation points.  For all MANET types, each
   address/ID must be locally-unique within the (limited) local MANET
   routing domain.  For not-so-stubby MANETs, the address/ID must also



Templin & Jakubisin       Expires 16 July 2026                  [Page 4]

Internet-Draft            MANET Internetworking             January 2026


   be globally-unique among all local MANET routing domains worldwide.

   The locally-unique property ensures that no two nodes that
   participate in the MANET routing protocol within the same local
   routing domain configure the same address/ID.  The globally-unique
   property may seem moot until one considers that MANETs can merge with
   other MANETS, and nodes from a first MANET can freely move to other
   MANETs.  This may allow a node from a first MANET where there are no
   duplicates to interact with other MANETs where a duplicate address
   may be encountered resulting in unpredictable behavior and/or
   communication failures.

   Although the node population for each MANET local routing domain is
   likely to be modest, the total population of MANET nodes may be on
   the order of the number of worldwide mobile connections (see:
   Section 1).  Assuming the google estimate of O(10**10) wireless
   connections, if MANET nodes assigned random addresses from a 64-bit
   space, the probability of one or more collisions within the total
   world population (i.e., when multiple nodes independently configure
   the same address) exceeds 98% [RFC9374].  With such a high likelihood
   of duplication in the worldwide population, an unresolvable collision
   could occur if duplicates ever met within the same local routing
   domain (e.g., following a MANET merge).

   For stub MANETs that always acts independently of all others, the
   risk of a duplication event within each local routing domain due to a
   new node joining is vanishingly small even for extreme mobility
   frequencies according to Appendix A.2 of [RFC4429].  Stub MANETs can
   therefore rely on statistical uniqueness properties of randomly
   assigned addresses.

   When MANET Internetworking is applied to connect routers in different
   not-so-stubby MANETs, however, independent local routing domains are
   dynamically joined by on-demand virtual circuits across the
   Internetwork overlay as a normal course of operational data
   communications.  When these MANET merge events occur, the MANET local
   IP addresses present in the source and destination MANETs must be
   mutually exclusive.  These merge events must further be considered to
   occur at truly unbounded frequencies across the global population due
   to the unpredictable nature of worldwide Internetworking dynamics for
   peer-to-peer communications.  Statistical uniqueness properties of
   random assignments from even very large populations may therefore be
   insufficient to ensure collision freedom since MANET Internetworking
   exposes the full world population of MANET local addresses as
   potential duplicates.






Templin & Jakubisin       Expires 16 July 2026                  [Page 5]

Internet-Draft            MANET Internetworking             January 2026


   Nodes in not-so-stubby MANETs should therefore configure MANET local
   addresses managed for uniqueness even if they first self-generate the
   addresses before enrolling them in a registration service.  Such
   address registration is not required for nodes that only connect via
   stub MANETs.

3.2.  Problem 2: Autoconfiguration

   When a MANET comes in contact with a fixed Internetwork such as the
   global public Internet, nodes in the MANET that engage global mobile
   Internetworking services require some means of autoconfiguring
   global-scoped IP addresses and/or prefixes that are properly routable
   by network elements accessible from the current point of attachment.
   These network elements are typically proxies or routers of some
   variety that connect to the mobile routing system.

   Nodes in the local MANET that are multiple IP hops away from an
   Internet connection sharing peer cannot use unmodified standard
   autoconfiguration services including IPv6 Neighbor Discovery (IPv6ND)
   [RFC4861] or DHCPv6 [RFC8415] over a MANET interface since these
   services are link-scoped in nature.  (The DHCPv6 architecture
   includes a "relay" function, but the dynamic nature of links in
   (multi-link) local MANET routing regions may interfere with
   straightforward application of DHCPv6 relays.)

   Two methods of supporting generalized autoconfiguration for nodes
   within a MANET have been suggested.  In a first method (conducted
   directly over MANET interfaces) first-hop neighboring nodes within
   the MANET collectively participate to repeat link-scoped
   autoconfiguration discovery requests to other neighbors that are
   topologically closer to an Internet connection sharing node.  This
   hop-by-hop process continues between neighbors until the request
   arrives at an Internet connection sharing node that can then contact
   an Internetwork element capable of delegating an Internet Service
   Provider (ISP) Provider-Aggregated (PA) IP address or prefix.  The
   Internetwork element then returns the delegated IP address/prefix in
   a reply that traverses the reverse path to the original requesting
   node.  Each MANET router then configures a route to this IP address/
   prefix within the MANET local routing protocol, i.e., the MANET local
   routing protocol becomes aware of the delegation.

   In a second autoconfiguration method, the requesting node configures
   a (virtual) overlay multilink network interface over its (physical)
   MANET interface(s) and issues standard link-scoped IPv6ND and/or
   DHCPv6 requests over the virtual interface.  The virtual interface
   applies encapsulation to provide the appearance of a single Non-
   Broadcast Multiple Access (NBMA) link spanning the entire (multilink)
   MANET.  This virtual link supports standard link-scoped



Templin & Jakubisin       Expires 16 July 2026                  [Page 6]

Internet-Draft            MANET Internetworking             January 2026


   autoconfiguration services coordinated with an Internetwork element
   capable of delegating an address.  For stub MANETs, the Internet
   connection sharing node itself delegates a public or private IP
   address.  For not-so-stubby MANETS, an overlay Internetwork Mobility
   Anchor Point (MAP) delegates a Mobility Service Provider (MSP) Mobile
   Network Prefix (MNP) as a Provider-Independent (PI) IP prefix
   maintained by the overlay for the requesting node to provision on
   downstream-attached interfaces.  The MAP then returns the delegated
   IP prefix in a link-scoped reply over the virtual interface that
   traverses the reverse path to the original requesting node.  Each
   MANET router optionally configures a route to this IP address via the
   virtual interface, i.e., the MANET local routing protocol is
   optionally made aware of the delegation within the virtual overlay.

3.3.  Problem 3: MANET-internal Communications

   Two nodes located within the same local MANET routing region should
   be able to communicate (across multiple hops if necessary) using
   MANET local addressing with no external Internetwork infrastructure
   reference points.  As long as the MANET-local addresses configured by
   communicating peers are unique, the MANET local routing system
   maintains continuous multihop forwarding services to ensure session
   continuity.

   Nodes within the local MANET routing region can discover the MANET
   local addresses of peers using services like Multicast DNS (mDNS)
   [RFC6762] supported by Simplified Multicast Forwarding (SMF)
   [RFC6621].  Peer-to-peer communications can then be coordinated
   either in multihop fashion directly over the physical MANET
   interfaces or via a single virtual hop using overlay multilink
   network interface encapsulation.  In that case, the MANET peers
   establish an on-demand virtual circuit spanning any intermediate hops
   in the path.

3.4.  Problem 4: MANET Peer to Internetwork Correspondent

   When an originating peer (or its stub MANET Internet connection-
   sharing node) within a not-so-stubby MANET needs to communicate with
   a correspondent connected elsewhere in an external Internetwork, the
   peer consults the global DNS which returns a (stable) globally-
   routable IP address for the correspondent.  The peer can then use one
   of its MNP-based IP addresses obtained through autoconfiguration and
   the global IP address of the Internetwork correspondent as the source
   and destination addresses for packet exchanges.

   The MANET peer first establishes an on-demand virtual circuit in the
   overlay to an Internetwork relay beyond the MANET border.  MANET
   local multihop routing will then convey the peer's original packets



Templin & Jakubisin       Expires 16 July 2026                  [Page 7]

Internet-Draft            MANET Internetworking             January 2026


   to the MANET border which then forwards them via the overlay to an
   Internetwork relay which directs the packets to the correspondent
   node.

   In the reverse path, the correspondent uses the MNP-based IP address
   of the peer obtained from the source address of initiating packets as
   the destination address for reply packets.  Standard Internetwork
   routing will direct the packets back to the relay which then forwards
   them via an on-demand overlay virtual circuit to the originating
   peer's MANET border.  MANET-local routing and forwarding will then
   convey the packets over one or more MANET-local hops until they
   ultimately reach the peer.

   In this case, the originating peer's IP address need not appear in
   the global DNS since the correspondent discovers the address by
   examining the source of received packets.

3.5.  Problem 5: Internetwork Correspondent to MANET Peer

   When an Internetwork correspondent needs to communicate with a target
   peer within a local MANET routing region, the correspondent consults
   the global DNS to determine an IP address for the peer.

   The correspondent then forwards packets via standard Internet routing
   until they arrive at a relay.  The relay then establishes an on-
   demand virtual circuit in the overlay to the MANET peer then begins
   forwarding packets via the virtual circuit until they reach the
   destination.  Reverse path forwarding from the MANET peer to the
   Internetwork correspondent is then conducted in the same manner
   described in Section 3.4.

   IP addresses covered by delegated prefixes remain stable even across
   MANET-wide mobility events to the point that continuous dynamic
   updates to the DNS are not required to maintain uninterruptable
   communications.  While it is possible that mobility events may cause
   minor temporary disruptions, transport protocol retransmissions will
   maintain continuity for any ongoing sessions.

3.6.  Problem 6: Peer-to-Peer Between Different MANETs

   When two prospective peer nodes are located in different MANET local
   routing regions separated by one or more transit Internetwork
   segments, both peers should include their IP addresses in their
   global DNS resource records for the same reasons cited in
   Section 3.5.

   The peers then establish on-demand virtual circuits in the overlay to
   support peer-to-peer bidirectional packet forwarding.



Templin & Jakubisin       Expires 16 July 2026                  [Page 8]

Internet-Draft            MANET Internetworking             January 2026


   Maintaining address mappings requires a certain degree of
   coordination between peer nodes and the MSP.  The MSP is responsible
   for ensuring that each peer remains reachable at its stable IP
   address/prefix through distributed mobility management.

3.7.  Problem 7: Stub MANET to Not-so-stubby MANET Connections

   When an Internet connection sharing MANET router connects a stub
   MANET, it can either delegate public IP addresses to stub MANET nodes
   or delegate private IP addresses then apply Network Address
   Translation (NAT) to support external communications.

   In the public case, all manners of peer-to-peer communications are
   made possible due to the globally routable nature of the addresses.
   In the NAT case, only communications initiated by a stub network peer
   are supported since the reverse path terminates at the NAT.

   The stub MANET itself may configure a local overlay that regards the
   (multihop) MANET as a single unified link.  In that case, the stub
   network overlay link is distinct from the overlay link that spans the
   global public Internet and the two links are joined by an IPv6
   router.

   In the not-so-stubby case, a single overlay link extends across both
   any transit Internetworks and the source and target MANETs
   themselves.  All peer-to-peer communications are therefore conveyed
   across the monolithic Internetwork overlay.

4.  IANA Considerations

   This document is an informational problem statement and does not in
   itself request any IANA actions.  IANA considerations can be found in
   solution space documents.

5.  Security Considerations

   This document is an informational problem statement and does not in
   itself address security.  Security considerations can be found in
   solution space documents.

6.  Acknowledgements

   Discussions on the MANET working group mailing list helped shape
   concepts exposed in this document.  Abdussalam Baryun encouraged a
   MANET use case analysis.  Polls conducted by chairs during the
   IETF124 MANET working group session presentation of this document
   showed unanimous and substantial interest in MANET Internetworking:
   https://datatracker.ietf.org/meeting/124/materials/minutes-124-manet-



Templin & Jakubisin       Expires 16 July 2026                  [Page 9]

Internet-Draft            MANET Internetworking             January 2026


   202511061630-00.

   This work is aligned with the Boeing/Virginia Tech National Security
   Institute (VTNSI) 5G MANET research program.

   Honoring life, liberty and the pursuit of happiness.

7.  References

7.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

7.2.  Informative References

   [RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501,
              DOI 10.17487/RFC2501, January 1999,
              <https://www.rfc-editor.org/info/rfc2501>.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
              <https://www.rfc-editor.org/info/rfc4429>.

   [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/info/rfc4861>.

   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
              RFC 6621, DOI 10.17487/RFC6621, May 2012,
              <https://www.rfc-editor.org/info/rfc6621>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.







Templin & Jakubisin       Expires 16 July 2026                 [Page 10]

Internet-Draft            MANET Internetworking             January 2026


   [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/info/rfc8415>.

   [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
              "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
              ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
              <https://www.rfc-editor.org/info/rfc9374>.

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>

   Differences from -01 to -02:

   *  Simplified addressing model under Autoconfiguration section.  Only
      autoconfiguration now necessary is for Mobile Network Prefixes
      (MNPs).

   Differences from -00 to -01:

   *  Included use case discussion.

   *  Slight clarification to addressing model.

   Differences from earlier versions:

   *  First draft publication.

Authors' Addresses

   Fred L. Templin (editor)
   Boeing Technology Innovation
   P.O. Box 3707
   Seattle, WA 98124
   United States of America
   Email: fltemplin@acm.org


   Daniel J. Jakubisin
   National Security Institute, Virginia Tech
   2202 Kraft Dr.
   Blacksburg, VA 24060
   United States of America
   Email: djj@vt.edu




Templin & Jakubisin       Expires 16 July 2026                 [Page 11]


name: draft-sogomonian-ai-uri-scheme
rev: 01
title: AI URI Scheme
time: 2025-10-03T16:49:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-06T16:49:42Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:10.243408+00:00
abstract:
This document specifies the experimental ai Uniform Resource
   Identifier (URI) scheme.  The scheme provides a dedicated access
   point for Artificial Intelligence (AI) resources, enabling autonomous
   systems and robots to connect natively while allowing human-facing
   applications to interoperate via HTTPS gateways.

full_text:
Network Working Group                                      A. Sogomonian
Internet-Draft        Artificial Intelligence Internet Foundation (AIIF)
Intended status: Experimental                             2 October 2025
Expires: 5 April 2026


                             AI URI Scheme
                   draft-sogomonian-ai-uri-scheme-01

Abstract

   This document specifies the experimental ai Uniform Resource
   Identifier (URI) scheme.  The scheme provides a dedicated access
   point for Artificial Intelligence (AI) resources, enabling autonomous
   systems and robots to connect natively while allowing human-facing
   applications to interoperate via HTTPS gateways.

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 5 April 2026.

Copyright Notice

   Copyright (c) 2025 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.







Sogomonian                Expires 5 April 2026                  [Page 1]

Internet-Draft                   AI URI                     October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  URI Syntax (Non-Normative)  . . . . . . . . . . . . . . . . .   2
   3.  Web Integration and HTTPS Gateway Access  . . . . . . . . . .   3
     3.1.  Discovery from HTTPS  . . . . . . . . . . . . . . . . . .   3
     3.2.  HTTPS to AIIP Gateway Behavior  . . . . . . . . . . . . .   4
     3.3.  No Native AIIP Requirement for User Agents  . . . . . . .   4
     3.4.  Provenance and Result Integrity . . . . . . . . . . . . .   4
   4.  Namespace Administration  . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   7.  Internationalization Considerations . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  URI Scheme Registration . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The ai URI scheme identifies AI-addressable resources such as agents,
   models, tools, and tasks.  Deployments *MAY* resolve ai: identifiers
   natively within AI systems and robots, or via HTTPS gateways for
   compatibility with existing web stacks.

   For clarity, this document uses the term AIIP to denote the
   _Artificial Intelligence Internet Protocol_, the operational protocol
   by which ai:// resources are addressed, resolved, and invoked.  While
   ai:// is the URI scheme, AIIP defines resolution and interaction
   semantics.

   The key words *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*,
   *SHOULD*, *SHOULD 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.

2.  URI Syntax (Non-Normative)

   The scheme follows [RFC3986].  An informal summary is shown:

   ai-uri = "ai:" hier-part [ "?" query ] [ "#" fragment ]
   ; hier-part, query, fragment per RFC 3986

   Examples (illustrative only):

   ai:/agent/forklift-42?task=load&zone=A3
   ai://factory.example/pay?amount=10&currency=USD



Sogomonian                Expires 5 April 2026                  [Page 2]

Internet-Draft                   AI URI                     October 2025


3.  Web Integration and HTTPS Gateway Access

   Many user agents will not natively implement the ai scheme or the
   Artificial Intelligence Internet Protocol (AIIP).  To enable
   immediate interoperability, deployments *MAY* expose ai:// resources
   via HTTPS gateways so that end users remain on conventional websites
   while backends or trusted intermediaries invoke AIIP.  In this model,
   a relying party (for example, an online bank) advertises an ai://
   endpoint and resolves it server-side or through a gateway; the user
   continues to interact over HTTPS without needing to understand ai://.

3.1.  Discovery from HTTPS

   HTTPS origins that rely on AIIP *SHOULD* advertise their ai://
   endpoints using one or more of:

   *  *HTTP Link header* on responses:

      Link: <ai://bank/service/payments>; rel="aiip"

   *  *HTML link relation* for progressive enhancement:

      <link rel="aiip" href="ai://bank/service/payments">

   *  *Well-known resource* at /.well-known/aiip:

      {
        "endpoint": "ai://bank/service/payments",
        "jwks":
          "https://www.bank.example/.well-known/aiip.jwks.json",
        "scopes": [
          "initiate-payment",
          "check-balance"
        ],
        "policy": {
          "auth": "oauth2",
          "mtls": true,
          "requireSignedResults": true
        }
      }

   *  *DNS bootstrap (optional)*, for example, SRV or TXT records:

      _aiip._tcp.bank.example.  300 IN SRV 0 0 443
                                aiip.bank.example.
      _aiip.bank.example.       300 IN TXT
                                "endpoint=ai://bank/service/payments"




Sogomonian                Expires 5 April 2026                  [Page 3]

Internet-Draft                   AI URI                     October 2025


3.2.  HTTPS to AIIP Gateway Behavior

   A conforming HTTPS to AIIP gateway *MUST* map an embedded ai:// URI
   to an HTTPS URL under its control, perform AIIP resolution, and
   translate the result back into HTTPS semantics for the client.  For
   example:

   Original:
     ai://bank/service/payments?amount=10&currency=USD
   Gateway :
     https://ai.example/gateway/bank/service/payments
     ?amount=10&currency=USD

   Gateways *MUST*:

   *  Parse and normalize the ai:// URI; reject malformed or ambiguous
      inputs.

   *  Authenticate to the AI endpoint and verify provenance of responses
      (for example, JWS with a key discoverable via the origin's JWKS).

   *  Enforce authorization consistent with the user's web session (for
      example, token exchange, DPoP, or mTLS constraints).

   *  Preserve confidentiality and integrity at least equivalent to TLS
      1.3 [RFC8446] and obey HTTP semantics [RFC9110].

   *  Prevent downgrades; do not weaken authentication or authorization
      versus native AIIP.

3.3.  No Native AIIP Requirement for User Agents

   Web user agents *NEED NOT* implement AIIP.  Sites may perform all AI
   resolution server-side or via a trusted gateway.  This enables
   gradual deployment: users remain on HTTPS while services invoke ai://
   under the hood to complete actions (for example, initiating a
   payment).

3.4.  Provenance and Result Integrity

   Responses returned from AIIP resolution *MUST* include verifiable
   provenance (for example, a detached or embedded signature).  Gateways
   and relying parties *MUST* reject unverifiable or policy-incompatible
   results.  Implementations *SHOULD* publish a JWKS for verification
   and rotate keys per operational policy.






Sogomonian                Expires 5 April 2026                  [Page 4]

Internet-Draft                   AI URI                     October 2025


4.  Namespace Administration

   To support global uniqueness and safe operation of autonomous
   systems, namespace administration for ai: identifiers is expected to
   be coordinated by the _Artificial Intelligence Internet Foundation
   (AIIF)_, which serves as the umbrella governance body.  The _AIIF
   Registry Authority for Identifiers (AIID)_ operates the AI Root
   Registry and administers identifier allocation and operational policy
   for ai:// namespaces.  This administrative role is separate from the
   technical specification of the scheme and protocol.

5.  Security Considerations

   Implementations that dereference ai: identifiers *MUST* authenticate
   endpoints and apply authorization and safety policies, especially
   when actions may control physical devices or financial operations.
   Gateways translating ai: to HTTPS *MUST* preserve provenance and
   provide transport security per [RFC8446] and semantics conforming to
   [RFC9110].

6.  Privacy Considerations

   Accessing ai:// resources through HTTPS gateways may expose metadata
   such as target identifiers, origin site, and timing information to
   intermediaries.  Gateways *SHOULD* minimize logging, apply strict
   data retention limits, and avoid retaining identifiers longer than
   operationally necessary.  Provenance and result signatures may
   contain linkable identifiers; deployments *SHOULD* apply least-
   privilege scopes and anonymization where appropriate.

7.  Internationalization Considerations

   Identifiers in ai:// URIs follow [RFC3986].  Non-ASCII characters
   appearing in the path or query components *MUST* be percent-encoded.
   Any authority components mapped from DNS *MUST* follow IDNA
   processing where applicable.  No additional internationalization
   mechanisms are defined by this document.

8.  IANA Considerations

   This document requests Provisional registration of the ai URI scheme
   per [RFC7595].

8.1.  URI Scheme Registration

   This section provides the registration template for the ai URI scheme
   in accordance with [RFC7595] Section 3.4.




Sogomonian                Expires 5 April 2026                  [Page 5]

Internet-Draft                   AI URI                     October 2025


   Scheme name: ai
   Status: Provisional
   Applications/protocols that use this scheme:
     AIIP (Artificial Intelligence Internet Protocol)
   Contact:
     Aram Sogomonian <waterbottling@icloud.com>
   Change controller:
     The author of this document (or a designated successor)
   References:
     This document; RFC 3986; RFC 7595; RFC 8446; RFC 9110
   Security considerations:
     See "Security Considerations" of this document

9.  Normative References

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", RFC 3986,
              January 2005, <https://www.rfc-editor.org/info/rfc3986>.

   [RFC7595]  Thaler, D., Hansen, T., and T. Hardie, "Guidelines and
              Registration Procedures for URI Schemes", RFC 7595, June
              2015, <https://www.rfc-editor.org/info/rfc7595>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9110]  Fielding, R. and J. Reschke, "HTTP Semantics", RFC 9110,
              June 2022, <https://www.rfc-editor.org/info/rfc9110>.

Author's Address

   Aram Sogomonian
   Artificial Intelligence Internet Foundation (AIIF)
   United States of America
   Email: waterbottling@icloud.com







Sogomonian                Expires 5 April 2026                  [Page 6]


name: draft-bernardos-green-isac-uc
rev: 00
title: Integrated Sensing and Communications (ISAC) use case for GREEN
time: 2025-08-31T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2025-08-31T11:44:52Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:10.243411+00:00
abstract:
Integrated Sensing and Communications (ISAC) represents a paradigm
   shift in wireless networks, where sensing and communication functions
   are jointly designed and optimized.  By leveraging the same spectral
   and hardware resources, ISAC enables advanced capabilities such as
   environment perception, object tracking, and situational awareness,
   while maintaining efficient and reliable data transmission.  This
   integration holds great potential for applications in areas such as
   autonomous systems, smart cities, and industrial automation, where
   precise sensing and low-latency communication are critical.

   This document presents a use case related to ISAC, aiming to
   facilitate discussions within the GREEN Working Group on the
   potential benefits, challenges, and requirements.  The use case
   follows a structured template that we propose for all GREEN use
   cases, ensuring consistency and comparability across different
   scenarios.

full_text:
GREEN WG                                                   CJ. Bernardos
Internet-Draft                                                      UC3M
Intended status: Standards Track                         M. Awais Jadoon
Expires: 31 August 2025                                        A. Mourad
                                                            InterDigital
                                                        27 February 2025


    Integrated Sensing and Communications (ISAC) use case for GREEN
                    draft-bernardos-green-isac-uc-00

Abstract

   Integrated Sensing and Communications (ISAC) represents a paradigm
   shift in wireless networks, where sensing and communication functions
   are jointly designed and optimized.  By leveraging the same spectral
   and hardware resources, ISAC enables advanced capabilities such as
   environment perception, object tracking, and situational awareness,
   while maintaining efficient and reliable data transmission.  This
   integration holds great potential for applications in areas such as
   autonomous systems, smart cities, and industrial automation, where
   precise sensing and low-latency communication are critical.

   This document presents a use case related to ISAC, aiming to
   facilitate discussions within the GREEN Working Group on the
   potential benefits, challenges, and requirements.  The use case
   follows a structured template that we propose for all GREEN use
   cases, ensuring consistency and comparability across different
   scenarios.

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 31 August 2025.





Bernardos, et al.        Expires 31 August 2025                 [Page 1]

Internet-Draft           ISAC use case for GREEN           February 2025


Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Energy-Aware Smart City Traffic Management  . . . . . . . . .   3
     2.1.  Use case description  . . . . . . . . . . . . . . . . . .   3
     2.2.  GREEN Specifics . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Requirements for GREEN  . . . . . . . . . . . . . . . . .   3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Integrated Sensing and Communications (ISAC) is emerging as a key
   enabler for next-generation wireless networks, integrating sensing
   and communication functionalities within a unified system.  By
   leveraging the same spectral, hardware, and computational resources,
   ISAC enhances network efficiency while enabling new capabilities such
   as high-resolution environment perception, object detection, and
   situational awareness.  This paradigm shift is particularly relevant
   for applications requiring both reliable connectivity and precise
   sensing, such as autonomous vehicles, industrial automation, and
   smart city deployments.  Given its strategic importance, ISAC has
   gained significant traction in standardization efforts.  The ETSI
   Industry Specification Group (ISG) on ISAC has been established to
   explore technical requirements and use cases, while 3GPP has
   initiated discussions on ISAC-related features within its ongoing
   research on future 6G systems.  Furthermore, research initiatives
   within the IEEE and IETF are investigating how ISAC can be integrated
   into network architectures, spectrum management, and protocol design,
   making it a critical area of development in the evolution of wireless
   networks.



Bernardos, et al.        Expires 31 August 2025                 [Page 2]

Internet-Draft           ISAC use case for GREEN           February 2025


   This document presents a use case related to ISAC, aiming to
   facilitate discussions within the GREEN Working Group on the
   potential benefits, challenges, and requirements.  The use case
   follows a structured template that we propose for all GREEN use cases
   [I-D.stephan-green-use-cases], ensuring consistency and comparability
   across different scenarios.

2.  Energy-Aware Smart City Traffic Management

2.1.  Use case description

   This use case involves deploying ISAC systems in a smart city to
   monitor and optimize vehicles' traffic flows while minimizing energy
   consumption of the mobile network.  The system integrates sensing
   technologies, such as radar and LIDAR, with communication networks to
   detect vehicle density, monitor road conditions, and communicate with
   autonomous vehicles or traffic lights.  By using ISAC, the system
   minimizes redundant infrastructure (e.g., separate sensors and
   communication equipment), thus reducing the overall carbon and energy
   footprint.

2.2.  GREEN Specifics

   Energy Consumption Monitoring: Each ISAC component (e.g., roadside
   units, integrated sensors, and communication transceivers) is capable
   of reporting its energy consumption in real time to the centralized
   or distributed energy management system.

   Reconfiguration for Energy Efficiency: The system can dynamically
   switch between high-resolution sensing modes (e.g., during peak
   hours) and low-power modes (e.g., during low traffic periods).  The
   network can reconfigure traffic communication paths to prioritize
   routes or nodes that consume less power, leveraging energy-efficient
   communication protocols.

   Integration of Local and Global Energy Goals: The system can operate
   both locally (e.g., turning off specific roadside units in low-
   traffic areas) and globally (e.g., modifying traffic patterns across
   the city) to achieve defined energy consumption goals.

2.3.  Requirements for GREEN

   1.  Measurement Granularity:

       *  Ability to measure energy consumption per ISAC component
          (e.g., roadside unit, sensor, transceiver).





Bernardos, et al.        Expires 31 August 2025                 [Page 3]

Internet-Draft           ISAC use case for GREEN           February 2025


       *  Granular reporting per communication link or sensing mode
          (e.g., high-power radar mode vs. low-power mode).

   2.  Power Control Mechanisms:

       *  Ability to switch components on/off or place them in sleep/
          standby mode when not in use.

       *  Support for dynamic adjustment of sensing resolution or
          communication bandwidth to balance energy savings and system
          performance.

   3.  Reconfiguration and Adaptability:

       *  Support for hardware reconfiguration (e.g., adaptive sensing
          modes, transceiver settings) to optimize energy use.

       *  Mechanisms to steer traffic or adjust network routing based on
          global or local energy-saving objectives.

   4.  Global Coordination:

       *  Capabilities for cross-domain coordination to enable global
          optimization (e.g., city-wide traffic rerouting or dynamic
          resource allocation across different regions).

       *  Ability to aggregate and analyze energy consumption data from
          all ISAC components to inform high-level decision-making.

   5.  Energy-Aware Standards and Protocols:

       *  Communication protocols that minimize power usage while
          maintaining reliability.

       *  Interoperability standards for energy-aware reconfiguration
          across heterogeneous ISAC components and systems.

3.  IANA Considerations

   N/A.

4.  Security Considerations

   TBD.







Bernardos, et al.        Expires 31 August 2025                 [Page 4]

Internet-Draft           ISAC use case for GREEN           February 2025


5.  Acknowledgments

   The work of Carlos J.  Bernardos in this document has been partially
   supported by the Horizon Europe MultiX (Grant Agreement No.
   101192521) and Hexa-X-II (Grant Agreement No. 101095759) projects.

6.  Informative References

   [I-D.stephan-green-use-cases]
              Stephan, E., Palmero, M., Claise, B., Wu, Q., and L. M.
              Contreras, "Use Cases for Energy Efficiency Management",
              Work in Progress, Internet-Draft, draft-stephan-green-use-
              cases-00, 24 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-stephan-
              green-use-cases-00>.

Authors' Addresses

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   28911 Leganes, Madrid
   Spain
   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/


   Muhammad Awais Jadoon
   InterDigital Europe
   Email: muhammad.awaisjadoon@interdigital.com
   URI:   http://www.InterDigital.com/


   Alain Mourad
   InterDigital Europe
   Email: Alain.Mourad@InterDigital.com
   URI:   http://www.InterDigital.com/













Bernardos, et al.        Expires 31 August 2025                 [Page 5]


name: draft-pbs-sidrops-roaanycast
rev: 00
title: Route Origin Authorization (ROA) Governance for Anycasted Services with Unique Origin ASNs
time: 2025-09-03T16:08:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-07T16:08:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:10.243413+00:00
abstract:
This document describes a set of best practices for the management of
   Route Origin Authorizations (ROAs) used to certify globally anycasted
   services with unique origin autonomous system numbers (ASNs) per
   node.  It identifies key risk areas related to anycast-based ROA
   publication and how to mitigate technical risk for RPKI operations.

full_text:
Network Working Group                                     L. Poulopoulos
Internet-Draft                                               S. Boudjema
Intended status: Best Current Practice                       H. Siddique
Expires: 7 March 2026                                           Verisign
                                                        3 September 2025


Route Origin Authorization (ROA) Governance for Anycasted Services with
                           Unique Origin ASNs
                    draft-pbs-sidrops-roaanycast-00

Abstract

   This document describes a set of best practices for the management of
   Route Origin Authorizations (ROAs) used to certify globally anycasted
   services with unique origin autonomous system numbers (ASNs) per
   node.  It identifies key risk areas related to anycast-based ROA
   publication and how to mitigate technical risk for RPKI operations.

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 7 March 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Poulopoulos, et al.       Expires 7 March 2026                  [Page 1]

Internet-Draft       ROAs for Unique Origin Anycast       September 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  Single-prefix Minimal ROAs  . . . . . . . . . . . . . . . . .   4
   3.  Sequential-Use EE Certificate . . . . . . . . . . . . . . . .   4
   4.  Single Signing Time . . . . . . . . . . . . . . . . . . . . .   4
   5.  Synchronous Operations  . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Anycasting, the origination of a prefix from multiple nodes, is an
   internet design pattern for improving the performance, stability and
   resiliency of global networks and is commonly implemented by DNS, CDN
   and DDoS protection service operators.  This approach can result in
   lower latency and can simplify fail-over.  An anycast node can be
   easily taken offline via withdrawl of its BGP route, causing traffic
   to automatically shift to other available nodes.

   Anycast services originating from unique origin ASNs per node
   [RFC6382], originate a single prefix from multiple distinct ASNs.
   The approach allows for more precise monitoring and troubleshooting
   of routing anomalies or hijacks.  The primary benefit is enhanced
   observability of anycasted services, especially when a large number
   of nodes are in operation.











Poulopoulos, et al.       Expires 7 March 2026                  [Page 2]

Internet-Draft       ROAs for Unique Origin Anycast       September 2025


   This design (distinct origin ASNs) calls for specific considerations
   when publishing Route Origin Authorizations (ROA).  Certifying
   origins of a Multiple Origin Autonomous System (MOAS) prefix implies
   the existence of a set of ROAs to certify all origins of the prefix.
   Given the exclusive nature of route origin validation (ROV), partial
   ROA coverage of MOAS prefixes MUST be avoided, as it would result in
   "INVALID" prefix/origin pairs for non-covered origins.  In this
   instance, absence of coverage is preferable over partial coverage as
   it would make all prefix/origin pairs resolve to RPKI "UNKNOWN".

   This document presents a set of recommendations meant to avoid
   partial ROA coverage of MOAS prefixes, by ensuring shared fate among
   the set of ROAs covering them.

1.1.  Conventions Used in This Document

   Anycast:  the practice of making a particular service address
      available in multiple, discrete, autonomous nodes, such that data-
      grams sent are routed to one of several available nodes [RFC4786].
   Multi-origin Autonomous System:  a particular setup of Anycast
      routing, where each node originating the same service is
      identified by a unique Autonomous System Number (ASN) [RFC6382].

   The terms "MOAS Service" and "MOAS Prefix" are used throughout this
   document as a convenience shorthand for the more verbose "Globally
   Anycasted Service with Unique Origin Autonomous System Numbers per
   Node".

   The terms "covering", "covered", when used to describe the effect of
   a ROA on a prefix/origin pair, are to be interpreted in the intuitive
   sense of "certified by".  They are not to be interpreted in the more
   restrictive sense employed by other writings, where "covering" only
   applies to the prefix of a prefix/origin pair [RFC6811] [RFC6483].

   They key words "VALID", "INVALID" and "UNKNOWN", are to be
   interpreted as RPKI validity states as described in [RFC6483] when,
   and only when, they appear in all capitals, as shown here. ç 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.









Poulopoulos, et al.       Expires 7 March 2026                  [Page 3]

Internet-Draft       ROAs for Unique Origin Anycast       September 2025


2.  Single-prefix Minimal ROAs

   Separate ROAs SHOULD be published for each prefix/origin-AS pair of
   the MOAS prefix.  This entails that these ROAs should contain a
   single prefix and the maximal length should be equal to the prefix
   length, i.e., be minimal ROAs [RFC9319].

   Doing so, ensures that routes of a MOAS prefix do not share fate with
   unrelated resources.

3.  Sequential-Use EE Certificate

   A set of ROAs covering origins of a MOAS prefix SHOULD be signed
   using the same End-Entity (EE) certificate (a.k.a. "sequential use"
   EE certificate [RFC6487]).

   This guarantees a common validity period among all origins of the
   prefix, avoiding partial expiry or partial revocation within the ROA
   set.

   Moreover, using a single EE certificate for all ROAs covering a MOAS
   prefix avoids unnecessary CRL bloating.

4.  Single Signing Time

   A set of ROAs covering origins of a MOAS prefix SHOULD present the
   same CMS signing time attribute.

   This practice may also have positive consequences if the publication
   point uses the CMS signing time as a reference to override filesystem
   timestamps [RFC9589] [I-D.ietf-sidrops-publication-server-bcp].

5.  Synchronous Operations

   Signing, publication and withdrawal of ROAs covering origins of a
   MOAS prefix SHOULD be synchronous to ensure shared fate among them
   and avoid partial coverage.

   In the context of the RPKI publication protocol [RFC8181], clients
   SHOULD request publication or withdrawal of all ROAs related to the
   MOAS prefix as part of a single publication query message, preferably
   avoiding operations on resources unrelated to the MOAS prefix.
   Reciprocally, publication servers SHOULD honor atomicity of
   transactions requested as part of a single query message.







Poulopoulos, et al.       Expires 7 March 2026                  [Page 4]

Internet-Draft       ROAs for Unique Origin Anycast       September 2025


   When creating ROAs as the consequence of the addition of new origin
   node to a MOAS service, ROAs covering existing nodes of the prefix
   SHOULD be renewed at the same time to preserve common signing and
   validity times among all origins of the prefix.

   More broadly, any modification to a ROA covering a MOAS prefix SHOULD
   be accompanied by changes to all ROAs covering the same MOAS prefix
   to preserve uniform validity attributes across the set.
   Consequently, these changes SHOULD be published within a single RPKI
   Repository Delta Protocol (RRDP) serial increment, to ensure
   synchronicity on the relying party end [RFC8182].

6.  IANA Considerations

   This document makes no requests of IANA.

7.  Security Considerations

   This section will be added later based on community review and
   feedback

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/info/rfc2119>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
              December 2006, <https://www.rfc-editor.org/info/rfc4786>.

   [RFC6382]  McPherson, D., Donnelly, R., and F. Scalzo, "Unique Origin
              Autonomous System Numbers (ASNs) per Node for Globally
              Anycasted Services", BCP 169, RFC 6382,
              DOI 10.17487/RFC6382, October 2011,
              <https://www.rfc-editor.org/info/rfc6382>.

   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487,
              DOI 10.17487/RFC6487, February 2012,
              <https://www.rfc-editor.org/info/rfc6487>.

   [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/info/rfc8174>.



Poulopoulos, et al.       Expires 7 March 2026                  [Page 5]

Internet-Draft       ROAs for Unique Origin Anycast       September 2025


   [RFC8181]  Weiler, S., Sonalker, A., and R. Austein, "A Publication
              Protocol for the Resource Public Key Infrastructure
              (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
              <https://www.rfc-editor.org/info/rfc8181>.

   [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
              "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
              DOI 10.17487/RFC8182, July 2017,
              <https://www.rfc-editor.org/info/rfc8182>.

   [RFC9319]  Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
              Maddison, "The Use of maxLength in the Resource Public Key
              Infrastructure (RPKI)", BCP 185, RFC 9319,
              DOI 10.17487/RFC9319, October 2022,
              <https://www.rfc-editor.org/info/rfc9319>.

   [RFC9589]  Snijders, J. and T. Harrison, "On the Use of the
              Cryptographic Message Syntax (CMS) Signing-Time Attribute
              in Resource Public Key Infrastructure (RPKI) Signed
              Objects", RFC 9589, DOI 10.17487/RFC9589, May 2024,
              <https://www.rfc-editor.org/info/rfc9589>.

8.2.  Informative References

   [I-D.ietf-sidrops-publication-server-bcp]
              Bruijnzeels, T., de Kock, T., Hill, F., Harrison, T., and
              J. Snijders, "RPKI Publication Server Best Current
              Practices", Work in Progress, Internet-Draft, draft-ietf-
              sidrops-publication-server-bcp-03, 24 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              publication-server-bcp-03>.

   [RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
              Origination Using the Resource Certificate Public Key
              Infrastructure (PKI) and Route Origin Authorizations
              (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
              <https://www.rfc-editor.org/info/rfc6483>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

Authors' Addresses







Poulopoulos, et al.       Expires 7 March 2026                  [Page 6]

Internet-Draft       ROAs for Unique Origin Anycast       September 2025


   L. Poulopoulos
   Verisign
   Route du Petit Moncor 1E
   CH-1752 Villars sur Glane
   Switzerland
   Email: lpoulopoulos@verisign.com
   URI:   https://www.verisign.com/


   S. Boudjema
   Verisign
   Route du Petit Moncor 1E
   CH-1752 Villars sur Glane
   Switzerland
   Email: sboudjema@verisign.com
   URI:   https://www.verisign.com/


   H. Siddique
   Verisign
   12061 Bluemont Way
   Reston, VA 20190
   United States
   Email: hsiddique@verisign.com
   URI:   https://www.verisign.com/


























Poulopoulos, et al.       Expires 7 March 2026                  [Page 7]


name: draft-sogomonian-aiip-architecture
rev: 03
title: Architecture for the Artificial Intelligence Internet Protocol (AIIP)
time: 2025-12-15T04:52:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-18T04:52:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Model serving/inference"]
tags: []
fetched_at: 2026-02-27T22:56:10.243424+00:00
abstract:
This document defines the architectural model for the Artificial
   Intelligence Internet Protocol (AIIP), including decentralized
   discovery and a byte-precise native envelope.  AIIP enables
   stateless, verifiable invocation of autonomous systems using a
   resolve-invoke-receipt pattern over authenticated transports.  Native
   AIIP is the default for machine-to-machine operation; HTTPS gateways
   are optional for human-facing access.  Each invocation produces a
   cryptographically verifiable execution receipt, optionally including
   attestation evidence.

full_text:
Independent Submission                                     A. Sogomonian
Internet-Draft        Artificial Intelligence Internet Foundation (AIIF)
Intended status: Experimental                           14 December 2025
Expires: 17 June 2026


 Architecture for the Artificial Intelligence Internet Protocol (AIIP)
                 draft-sogomonian-aiip-architecture-03

Abstract

   This document defines the architectural model for the Artificial
   Intelligence Internet Protocol (AIIP), including decentralized
   discovery and a byte-precise native envelope.  AIIP enables
   stateless, verifiable invocation of autonomous systems using a
   resolve-invoke-receipt pattern over authenticated transports.  Native
   AIIP is the default for machine-to-machine operation; HTTPS gateways
   are optional for human-facing access.  Each invocation produces a
   cryptographically verifiable execution receipt, optionally including
   attestation evidence.

Note

   Work in Progress.

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 June 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Sogomonian                Expires 17 June 2026                  [Page 1]

Internet-Draft              AIIP Architecture              December 2025


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   3
   3.  Native Autonomous Access Model  . . . . . . . . . . . . . . .   3
   4.  Discovery and Delegation Metadata . . . . . . . . . . . . . .   3
     4.1.  DNS Bootstrap Discovery . . . . . . . . . . . . . . . . .   3
     4.2.  HTTPS Metadata Discovery  . . . . . . . . . . . . . . . .   4
     4.3.  Delegation Statements . . . . . . . . . . . . . . . . . .   4
   5.  Native Envelope Framing . . . . . . . . . . . . . . . . . . .   4
     5.1.  Byte Order  . . . . . . . . . . . . . . . . . . . . . . .   4
     5.2.  32-Byte Header  . . . . . . . . . . . . . . . . . . . . .   4
   6.  Execution Receipts  . . . . . . . . . . . . . . . . . . . . .   5
   7.  Use Case: Autonomous Delegation . . . . . . . . . . . . . . .   6
   8.  HTTPS Gateway Profile . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   AIIP provides a uniform address space and invocation model for AI
   resources with verifiable outcomes.  The architecture follows a
   resolve-invoke-receipt pattern.

   Autonomous systems communicate natively using AIIP envelopes over
   authenticated transports.  Human operators and supervisory systems
   can access AIIP resources via HTTPS gateways for compatibility with
   Web-based tools.

   This revision adds discovery metadata (DNS bootstrap plus HTTPS well-
   known) and an autonomous delegation use case.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] and
   [RFC8174].





Sogomonian                Expires 17 June 2026                  [Page 2]

Internet-Draft              AIIP Architecture              December 2025


2.  Architectural Overview

   AIIP separates addressing, invocation, and verification into distinct
   steps: (1) discovery and resolution provide invocation metadata; (2)
   invocation is carried in a native AIIP envelope; (3) the response
   includes an execution receipt that can be verified independently.

3.  Native Autonomous Access Model

   Autonomous systems, including robots, industrial controllers, agents,
   and embedded devices, use AIIP natively.  In native mode, AIIP
   envelopes are exchanged directly between client and resource over an
   authenticated transport such as mutual TLS or QUIC.

   Native AIIP invocation does not depend on HTTP semantics, cookies, or
   browser-originated state.  Authorization, policy enforcement, and
   result verification are defined by AIIP.

   Human operators and management interfaces typically interact with
   AIIP resources through HTTPS gateways.  These gateways provide
   compatibility with Web-based clients but are not required for
   autonomous operation.

4.  Discovery and Delegation Metadata

   AIIP supports decentralized discovery using two complementary
   mechanisms: DNS-based bootstrap discovery and HTTPS-based detailed
   metadata retrieval.  This design avoids reliance on any single global
   resolver by allowing each administrative domain to publish its own
   resolution parameters and delegation information.

4.1.  DNS Bootstrap Discovery

   For an AIIP identifier whose authority is a DNS name (for example,
   aiip://service.example/...), an implementation MAY perform bootstrap
   discovery by querying a DNS TXT record under _aiip.service.example.

   The TXT record value is a semicolon-separated set of key/value
   parameters.  At a minimum, it SHOULD include an endpoint parameter
   indicating where detailed metadata can be retrieved.

   Example:

   _aiip.service.example.  IN TXT  "v=aiip1; endpoint=https://service.example/.well-known/aiip"

   The DNS record is intended for bootstrap only.  Implementations
   SHOULD treat HTTPS metadata (Section Section 4.2) as authoritative
   when available.



Sogomonian                Expires 17 June 2026                  [Page 3]

Internet-Draft              AIIP Architecture              December 2025


4.2.  HTTPS Metadata Discovery

   An implementation MAY retrieve detailed AIIP metadata from the HTTPS
   well-known resource /.well-known/aiip on the authority host (see
   [RFC8615]).  The retrieved document can provide resolver endpoints,
   verification keys or key references, and policy signals required to
   validate invocation metadata.

   The well-known document MUST be fetched over HTTPS and its
   authenticity and integrity MUST be validated using standard HTTPS
   server authentication.

   If both DNS bootstrap discovery and HTTPS metadata discovery are
   available, implementations SHOULD use the DNS record only to locate
   the HTTPS metadata.

4.3.  Delegation Statements

   Discovery metadata MAY include delegation statements allowing an
   administrative domain to delegate subsets of its AIIP namespace or
   specific capabilities to other parties.  Clients and resolvers MUST
   validate delegation chains prior to accepting invocation metadata
   derived from delegated authority.

5.  Native Envelope Framing

   AIIP invocations are carried in a byte-framed envelope suitable for
   native machine-to-machine transports.  The wire format defined here
   is transport-agnostic: authenticated transports provide
   confidentiality and channel security, while the AIIP envelope
   provides a stable framing and replay-resistant metadata.

5.1.  Byte Order

   All multi-octet integer fields are encoded in network byte order
   (big-endian).  Unless otherwise specified, fields are unsigned.

5.2.  32-Byte Header

   An AIIP message is encoded as: Wire = Header(32) ||
   Payload(PayloadLen) || Signature(SigLen).  The header is exactly 32
   octets.









Sogomonian                Expires 17 June 2026                  [Page 4]

Internet-Draft              AIIP Architecture              December 2025


     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
    +-------------------------------+-------------------------------+
    |          Magic "AIIP"         | VerMaj|VerMin|   Flags (16)    |
    +-------------------------------+-------------------------------+
    |          PayloadLen (32)      |           SigLen (16)         |
    +-------------------------------+-------------------------------+
    |                         Nonce (64)                            |
    +---------------------------------------------------------------+
    |                      TimestampMs (64)                         |
    +---------------------------------------------------------------+
   Bytes:  0..3   Magic (0x41 49 49 50)
           4      VerMaj (this document: 1)
           5      VerMin (this document: 0)
           6..7   Flags
           8..11  PayloadLen
           12..13 SigLen
           14..15 Rsv16 (MUST be 0)
           16..23 Nonce
           24..31 TimestampMs

                  Figure 1: AIIP Header Layout (32 bytes)

   No reserved fields exist beyond the fixed 32-byte header; the
   signature bytes follow the payload.

   Flags is a 16-bit bitmask.  Bit 0 (0x0001) indicates that the
   requester requires a receipt in the response.  Other bits are
   reserved for future use.

   Example header bytes (illustrative only):

   41 49 49 50  01 00  00 01  00 00 00 9C  00 40  00 00
   2F 7A 13 44  9B 02 5D 8A  00 00 01 93  8F 4C 3A 10

   Payload is UTF-8 JSON.  Binary fields (when needed) are represented
   using base64url strings.

6.  Execution Receipts

   Each successful invocation produces an execution receipt that can be
   verified independently of transport intermediaries.  Receipts bind
   the invocation identifier, relevant policy context, and execution
   outcome.

   This document illustrates a JWS-based receipt container ([RFC7515]).
   The specific receipt schema is expected to evolve with implementation
   experience.



Sogomonian                Expires 17 June 2026                  [Page 5]

Internet-Draft              AIIP Architecture              December 2025


   Illustrative receipt container:

   {
     "protected": "base64url(jws-protected-header)",
     "payload": {
       "txid": "b7f7cfd2-6c38-4d7a-8e5a-6f1e1d9e0a10",
       "ts": 1734149100000,
       "result": { "status": 200, "data_commitment": "base64url(hash)" },
       "policy": { "max_speed_mps": 0.5, "forbidden_zones": ["Z1", "Z2"] },
       "attestation": { "tee": "base64url(attestation-evidence)" }
     },
     "signature": "base64url(jws-signature)"
   }

   Receipt structure sketch (informative, ASN.1-like):

   AIIP-Receipt ::= SEQUENCE {
     txid            UUID,
     ts              INTEGER,            -- milliseconds since epoch
     resultCommit    OCTET STRING,       -- hash/commitment
     policy          SEQUENCE OF UTF8String OPTIONAL,
     attestation     OCTET STRING OPTIONAL,
     sigAlg          OBJECT IDENTIFIER,
     signature       OCTET STRING
   }

7.  Use Case: Autonomous Delegation

   AIIP enables explicit delegation of real-world actions to autonomous
   agents without disclosure of user credentials and without interactive
   authorization at execution time.  A user may delegate a capability
   (for example, aiip://user.phone/call) to an AI agent once, under
   defined policy constraints.

   After delegation, any authorized AI agent may invoke the delegated
   capability directly using AIIP.  Invocation does not require access
   to passwords, OAuth tokens, or user sessions.  Each execution
   produces a verifiable receipt binding the user’s authorization, the
   invoked action, and the execution outcome.

   Example invocation:

   aiip://user.phone/call?to=+15551234567&text=I'm+late








Sogomonian                Expires 17 June 2026                  [Page 6]

Internet-Draft              AIIP Architecture              December 2025


   The resulting execution receipt provides non-repudiable evidence that
   the user authorized the action and that it was executed as requested.
   This delegation model enables autonomous agents to perform actions
   such as calls, messages, device control, or payments without exposing
   credentials or requiring repeated user interaction.

8.  HTTPS Gateway Profile

   An HTTPS gateway translates Web-based requests into AIIP invocations
   and returns results with receipts to human-facing clients.

   The HTTPS gateway is a compatibility layer for human operators and
   MUST NOT be required for autonomous or machine-to-machine AIIP
   invocation.

9.  Security Considerations

   AIIP implementations MUST authenticate peers via the selected
   transport binding, prevent replay, and ensure integrity of invocation
   and receipt data.

   Execution receipts provide non-repudiable evidence of authorization
   and execution, suitable for audit, dispute resolution, and legal
   review.

10.  Privacy Considerations

   Implementations SHOULD minimize retained metadata and avoid
   correlating invocations beyond what is required for verification.
   Delegations SHOULD be scoped minimally to avoid over-exposure of
   capabilities or metadata.

11.  IANA Considerations

   This document makes no IANA requests.  Future revisions may request
   registration of well-known resources used for AIIP discovery.

12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7515]  Jones, M.B., "JSON Web Signature (JWS)", RFC 7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.






Sogomonian                Expires 17 June 2026                  [Page 7]

Internet-Draft              AIIP Architecture              December 2025


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

Author's Address

   Aram Sogomonian
   Artificial Intelligence Internet Foundation (AIIF)
   United States of America
   Email: aiinternetfoundation@icloud.com
   (mailto:aiinternetfoundation@icloud.com)

Author's Address

   Aram Sogomonian
   Artificial Intelligence Internet Foundation (AIIF)
   United States of America
   Email: aiinternetfoundation@icloud.com





























Sogomonian                Expires 17 June 2026                  [Page 8]


name: draft-moreno-lisp-uberlay
rev: 07
title: Uberlay Interconnection of Multiple LISP overlays
time: 2025-10-09T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-09T16:38:42Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:10.243429+00:00
abstract:
This document describes the use of the Locator/ID Separation Protocol
   (LISP) to interconnect multiple disparate and independent network
   overlays by using a transit overlay.  The transit overlay is referred
   to as the "uberlay" and provides connectivity and control plane
   abstraction between different overlays.  Each network overlay may use
   different control and data plane approaches and may be managed by a
   different organization.  Structuring the network into multiple
   network overlays enables the interworking of different overlay
   approaches to data and control plane methods.  The different network
   overlays are autonomous from a control and data plane perspective,
   this in turn enables failure survivability across overlay domains.
   This document specifies the mechanisms and procedures for the
   distribution of control plane information across overlay sites and in
   the uberlay as well as the lookup and forwarding procedures for
   unicast and multicast traffic within and across overlays.  The
   specification also defines the procedures to support inter-overlay
   mobility of EIDs and their integration with the intra-overlay EID
   mobility procedures defined in draft-ietf-lisp-eid-mobility.

full_text:
Network Working Group                                          V. Moreno
Internet-Draft                                                Google LLC
Intended status: Experimental                               D. Farinacci
Expires: 9 October 2025                                      lispers.net
                                                      A. Rodriguez-Natal
                                                     M. Portoles-Comeras
                                                                F. Maino
                                                                S. Hooda
                                                           Cisco Systems
                                                            7 April 2025


           Uberlay Interconnection of Multiple LISP overlays
                      draft-moreno-lisp-uberlay-07

Abstract

   This document describes the use of the Locator/ID Separation Protocol
   (LISP) to interconnect multiple disparate and independent network
   overlays by using a transit overlay.  The transit overlay is referred
   to as the "uberlay" and provides connectivity and control plane
   abstraction between different overlays.  Each network overlay may use
   different control and data plane approaches and may be managed by a
   different organization.  Structuring the network into multiple
   network overlays enables the interworking of different overlay
   approaches to data and control plane methods.  The different network
   overlays are autonomous from a control and data plane perspective,
   this in turn enables failure survivability across overlay domains.
   This document specifies the mechanisms and procedures for the
   distribution of control plane information across overlay sites and in
   the uberlay as well as the lookup and forwarding procedures for
   unicast and multicast traffic within and across overlays.  The
   specification also defines the procedures to support inter-overlay
   mobility of EIDs and their integration with the intra-overlay EID
   mobility procedures defined in draft-ietf-lisp-eid-mobility.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.




Moreno, et al.           Expires 9 October 2025                 [Page 1]

Internet-Draft                LISP Uberlay                    April 2025


   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 9 October 2025.

Copyright Notice

   Copyright (c) 2025 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.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
   3.  Interconnecting multiple LISP site-overlays via the
           Uberlay . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Logical Topology Considerations . . . . . . . . . . . . .   7
   4.  General Procedures  . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Control Plane Procedures  . . . . . . . . . . . . . . . .   9
       4.1.1.  Split-horizon at the Border xTRs  . . . . . . . . . .  10
       4.1.2.  Border-xTR Resiliency . . . . . . . . . . . . . . . .  11
     4.2.  Resolution and Forwarding Procedures  . . . . . . . . . .  12
       4.2.1.  Multi-overlay requests at border xTR  . . . . . . . .  13
     4.3.  Default EID registration and treatment  . . . . . . . . .  14
   5.  Multicast Specific Procedures . . . . . . . . . . . . . . . .  14
     5.1.  Inter-site-overlay Control Plane Procedures for Signal-free
           multicast . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.2.  Border xTR Resolution and Forwarding procedures for
           Signal-free multicast . . . . . . . . . . . . . . . . . .  15
   6.  Inter site-overlay Mobility Procedures  . . . . . . . . . . .  16
   7.  Virtual Private Network (VPN) Considerations  . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18



Moreno, et al.           Expires 9 October 2025                 [Page 2]

Internet-Draft                LISP Uberlay                    April 2025


   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     10.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   The main motivation for this specification is to provide a
   methodology for the interconnection of LISP domains that may use
   disparate control and/or data plane approaches.  For instance, one
   domain may use native LISP encapsulation for its data plane and a DDT
   based mapping system, while another domain may use VXLAN-GPE
   encapsulation and a mapping system based on
   [I-D.farinacci-lisp-decent].  Furthermore, one domain may use an IPv4
   RLOC space and the other domain may use an IPv6 RLOC space and there
   may not be connectivity between the domains at the RLOC level.  We
   propose a method to interconnect and enable interoperability between
   these disparate LISP overlay networks by connecting them to a common
   transit LISP overlay.

   In order to provide interworking across implementations of overlays
   that may use different control and data plane approaches, a LISP
   network may be structured as a collection of site-overlays
   interconnected by a transit area.  Each site-overlay is a fully
   functional overlay network and has its own set of Map Servers and Map
   Resolvers.  Site-overlays share a border xTR with a transit area.
   Connectivity between site-overlays is provided via the transit area
   which we will refer to as “The Uberlay”. This specification describes
   the Control Plane and Forwarding procedures for the implementation of
   an Uberlay connected multi-overlay LISP network.  This approach to
   the structure of a LISP network may also enable regional failure
   survivability and fault isolation.

2.  Definition of Terms

   LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
   Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-
   Resolver (MR) are defined in the LISP specifications [RFC9300] and
   [RFC9301].

   Terms defining interactions with the LISP Mapping System are defined
   in [RFC9301].

   Terms related to the procedures for signal free multicast are defined
   in [RFC8378].





Moreno, et al.           Expires 9 October 2025                 [Page 3]

Internet-Draft                LISP Uberlay                    April 2025


   The following terms are here defined to facilitate the descriptions
   and discussions within this particular document.

   Site-Overlay - Overlay network at a specific area or domain.  This
   overlay network has a dedicated Mapping System.

   Border-xTR - xTR that connects a site-overlay to one or more
   uberlays.

   xTR - LISP Tunnel Router as defined in [RFC9301].  An xTR connects
   end-points to the site-overlay.

   Local Mapping System - Mapping system of the site-overlay

   Uberlay - Overlay network that interconnects different site-overlays
   to each other.  The Uberlay has a dedicated Mapping System and
   creates an overlay amongst the border xTRs which connect different
   site-overlays.

   Uberlay Mapping System - Autonomous mapping system dedicated to the
   uberlay.

   Site-Overlay EIDs - Also referred to as local site-overlay EIDs,
   these are the EIDs that are connected to xTRs in a particular site-
   overlay and are registered in their own local site-overlay mapping
   system.  These EIDs will also be registered in the uberlay but not in
   the remote site-overlay mapping systems.

   Remote site-overlay EIDs - These are EIDs connected and registered in
   site-overlays other than the local site-overlay.

   Local site-overlay EIDs - These are EIDs connected and registered in
   the local site-overlay.

3.  Interconnecting multiple LISP site-overlays via the Uberlay

   A LISP network can be structured as a collection of LISP site-
   overlays that are interconnected by one or more LISP Uberlays.

   A LISP site-overlay is an overlay network that has its own set of
   xTRs, its own dedicated Mapping System and it may have a dedicated
   RLOC space, separate from that of other site-overlays or the uberlay.
   A LISP uberlay is also an overlay network with its own set of xTRs,
   its own dedicated Mapping System and it may have its own dedicated
   RLOC space.  When the RLOC spaces are dedicated, RLOC routes in the
   local underlay do not leak across to the underlay of other site-
   overlays.




Moreno, et al.           Expires 9 October 2025                 [Page 4]

Internet-Draft                LISP Uberlay                    April 2025


   A site-overlay will have xTRs and Border xTRs.  The xTRs provide
   connectivity to the local site-overlay EIDs, which are the EIDs that
   are locally connected to the overlay-site.  The Border xTRs are Re-
   encapsulating Tunnel Routers (RTRs) that connect the site-overlays to
   the LISP Uberlay in the transit network. xTRs participate in one
   site-overlay and one site-overlay only.  Border xTRs participate in
   the mapping system of the site-overlay it resides in and the mapping
   system of the uberlay it connects the site-overlay to.  Border xTRs
   may be shared by more than one site-overlay.

   The different site-overlays can be interconnected by an uberlay.  The
   uberlay consists of a dedicated Mapping System and the set of Border
   xTRs that connect the participating site-overlays to the Uberlay and
   the Uberlay Mapping System.

   Each site-overlay will have its own set of Map Servers and Map
   Resolvers (MS/MRs) which operate as an autonomous Mapping System.
   The Uberlay Mapping System is also autonomous and includes all
   necessary Map Servers and Map Resolvers.  Any of the Mapping Systems,
   in site-overlays or in the Uberlay, follow the control plane
   specification in [RFC9301] and may be structured as a Distributed
   Delegation Tree (DDT) per [RFC8111]for the purposes of horizontal
   scaling or other optimizations within each Mapping System.

   The MS/MRs can be co-located with the border-xTRs of the site-overlay
   When a Border xTR services more than one site-overlay, and the MS/MRs
   are instantiated on the Border xTR, logical instances of MS/MRs must
   be dedicated to each site-overlay.

   This specification defines the interaction between the Mapping
   Systems of the site-overlays and the uberlay to deliver a multi-
   overlay hierarchical network.  The forwarding procedures relevant to
   the border xTRs are also specified.  Figure 1 illustrates the multi-
   overlay network.

















Moreno, et al.           Expires 9 October 2025                 [Page 5]

Internet-Draft                LISP Uberlay                    April 2025


   +-------------------------------+
   |  +-----+   +-----+   +-----+  |
   |  | xTR |   | xTR |   | xTR |  |
   |  +-----+   +-----+   +-----+  |
   |                               |
   |                     +-------+ |   RLOC space 1
   |    Site Overlay 1   | MS/MR | |   (underlay 1)
   |                     +-------+ |
   |                               |
   |                               |
   |     +--------+  +--------+    |
   +-----| Border |--| Border |----+
   +-----|  xTR   |--|  xTR   |----+
   |     +--------+  +--------+    |
   |                               |
   |                               |
   |                               |
   |                     +-------+ |       Uberlay
   |     Uberlay         | MS/MR | |     RLOC Space
   |                     +-------+ |  (Transit Underlay)
   |                               |
   |                               |
   |         +----------+          |
   +---------|  Border  |----------+
   +---------|   xTR    |----------+
   |         +----------+          |
   |                               |
   |                     +-------+ |   RLOC space 2
   |    Site Overlay 2   | MS/MR | |   (underlay 2)
   |                     +-------+ |
   |                               |
   |  +-----+   +-----+   +-----+  |
   |  | xTR |   | xTR |   | xTR |  |
   |  +-----+   +-----+   +-----+  |
   +-------------------------------+


   Figure 1. Site-overlays connected via Uberlay

   Structuring the LISP network as multiple site-overlays interconnected
   by an uberlay delivers the following benefits:

   *  Enable the interworking of diverse site-overlay implementations in
      which different mapping systems and encapsulations may be used.

   *  Enhanced resiliency through regional failure survivability.
      Failures in one site-overlay or failures in a portion of the
      underlay should not affect other site-overlays.



Moreno, et al.           Expires 9 October 2025                 [Page 6]

Internet-Draft                LISP Uberlay                    April 2025


   *  Reduce the state of the site-overlay control plane.  The site-
      overlay control plane will only maintain state for EIDs that are
      connected to xTRs within the site-overlay These EIDs are referred
      to as local site-overlay EIDs in this specification.  Remote site-
      overlay EIDs will not be explicitly registered within the site-
      overlay.

   *  Separate the RLOC space of the different site-overlays as well as
      the uberlay RLOC space.  Each site-overlay will only need
      reachability to its own RLOCs, making the RLOCs private to the
      site-overlay Similarly, the uberlay RLOC space does not require
      knowledge of site-overlay specific RLOCs.  This simplifies the
      underlay routing protocol structure and reduces the state that
      must be handled and maintained by the underlay routing protocols.

   *  Reduced latency for local site-overlay EID registrations may be
      achieved when xTRs and Map Servers are topologically close.
      Topological proximity is expected when the RLOC spaces for the
      different overlays are kept separate.

   *  Reduced latency for local site-overlay EID lookups may be achieved
      when xTRs, Map Resolvers and Map Servers are topologically close.
      Topological proximity is expected when the RLOC spaces for the
      different overlays are kept separate.

   *  Creates a multicast replication hierarchy where the Border RTRs
      serve as the points of multicast replication for multicast traffic
      that spans multiple site-overlays.

   *  Creates a distributed structure of RTRs that can be leveraged for
      the deployment of NAT traversal in the RLOC space.


3.1.  Logical Topology Considerations

   xTRs as defined in RFC9301 connect a network to the LISP overlay and
   register the EID prefixes from the connected network to the LISP
   mapping system.  Border xTRs, as defined in this document, will
   connect site-overlays to the Uberlay and register the EID prefixes
   that originate in a site-overlay in the Mapping System of the
   Uberlay.  Conversely, a border xTR may register EID prefixes present
   in the Uberlay Mapping System into the Mapping System of a particular
   site-overlay.  Furthermore, border xTRs may connect Uberlays to each
   other and register the EID prefixes from one Uberlay into the other.
   There is no provision for the detection of registration loops when
   concatenating site-overlays and Uberlays, thus any interconnection of
   overlay domains (site-overlays or Uberlays) must be done in a loop
   free topology.



Moreno, et al.           Expires 9 October 2025                 [Page 7]

Internet-Draft                LISP Uberlay                    April 2025


   A loop free topology is hereby defined for reference.  This is a
   general concept and is not encoded into any of the protocol messages
   in LISP.  A loop free topology limits the peerings between Uberlays
   and/or overlays to a strict hierarchy.  At the top of the hierarchy
   is a single central Uberlay or Core Uberlay.  The loop free topology
   is defined by two simple rules: Uberlays must only connect to
   Uberlays in the next consecutive level of hierarchy (no level
   skipping) and uberlays within the same level of hierarchy must not
   connect to each other.  The loop-free topology hierarchy is
   illustrated in Figure 2.

   +----------------+                  +----------------+
   | site-overlay 1 |                  | site-overlay 2 |
   |    (Level 2)   |                  |    (Level 2)   |
   +----------------+                  +----------------+
             +---+                        +---+
             |RTR|                        |RTR|
             +---+                        +---+
          +-----------+             +-----------+
          | Uberlay 1 |             | Uberlay 2 |
          | (Level 1) |             | (Level 1) |
          +-----------+             +-----------+
                    +---+         +---+
                    |RTR+---------+RTR|
                    +--++         ++--+
                       |   Core    |
                       |  Uberlay  |
                       | (Level 0) |
                    +--++         ++--+
                    |RTR+---------+RTR|
                    +---+         +---+
          +-----------+             +-----------+
          | Uberlay 3 |             | Uberlay 4 |
          | (Level 1) |             | (Level 1) |
          +-----------+             +-----------+
             +---+                        +---+
             |RTR|                        |RTR|
             +---+                        +---+
   +----------------+                 +----------------+
   | site-overlay 3 |                 | site-overlay 4 |
   |    (Level 2)   |                 |    (Level 2)   |
   +----------------+                 +----------------+

   Figure 2. Loop-free topology hierarchy







Moreno, et al.           Expires 9 October 2025                 [Page 8]

Internet-Draft                LISP Uberlay                    April 2025


4.  General Procedures

   A site-overlay maintains state only for its local site-overlay EIDs
   and RLOCs.  Tunnels never cross site-overlay or uberlay boundaries.
   Remote site-overlay EIDs are reachable at the source site-overlay via
   a default mapping which will steer all traffic destined to remote
   site-overlay EIDs to the border xTRs where it can be handed off to
   the uberlay.  Traffic will be decapsulated at the border xTRs and a
   lookup in the uberlay mapping system will determine the site-overlay
   to which traffic is to be re-encapsulated.  The uberlay maintains
   state for the EIDs of all interconnected site-overlays and will steer
   traffic from the source site-overlay to the destination site-overlay
   by encapsulating the traffic from the source site-overlay border xTR
   to the destination site-overlay border xTR.  At the border xTR of the
   destination site-overlay, traffic will be de-capsulated, a lookup in
   the local destination site-overlay Mapping System will take place and
   traffic will be re-encapsulated to the xTR that connects to the
   destination EID.  Thus, forwarding is achieved by concatenating
   overlays and doing Re-encapsulation at the border xTRs to forward the
   traffic from the Ingress site-overlay to the Egress site-overlay via
   the Uberlay.

   Traffic for non-LISP sites, or for EIDs not registered in any site-
   overlay, will also be forwarded to the border xTR where it will be
   forwarded or dropped as appropriate.

4.1.  Control Plane Procedures

   Local EIDs must be registered by the xTRs into the local Mapping
   System of the site-overlay.  Intra-site communication follows the
   standard procedures of registration, resolution, caching and
   encapsulation defined in [RFC9300] and [RFC9301] amongst the xTRs
   within the local site-overlay.

   The border xTRs at a site-overlay should have a local site-overlay
   RLOC-set and will also have an uberlay RLOC-set.  The local site-
   overlay RLOC-set is in the private site-overlay RLOC space and is
   used by the border xTRs as the RLOC set for any mappings it may
   register with the site-overlay Mapping System.  The uberlay RLOC-set
   for the border-xTRs of a particular site-overlay are the RLOCs to
   reach the site-overlay in the uberlay RLOC space.  The border xTR
   will use the uberlay RLOC-set in any mappings it may register with
   the uberlay Mapping System.  It is possible for a deployment to
   connect the RLOC spaces of the site-overlays and the uberlay, it is
   also possible in the scenario of a common RLOC space for the uberlay
   and local site-overlay RLOC sets to be one and the same.  Any
   implementation of this specification should support disjoint RLOC
   spaces or joint RLOC spaces.



Moreno, et al.           Expires 9 October 2025                 [Page 9]

Internet-Draft                LISP Uberlay                    April 2025


   The border xTRs must register a default EID-prefix as specified in
   Section 4.3 with the local site-overlay Mapping System.  Remote EIDs
   will be generally reachable by xTRs in a site-overlay using the
   default EID mapping registered by the border xTRs.  This is expected
   to be the mapping used for most communications to remote site-overlay
   EIDs.  Remote site-overlay EIDs may be registered with the local
   site-overlay Mapping System for the purposes of supporting inter-
   overlay EID mobility as specified in Section 6, these mappings will
   be preferred over the default EID mapping whenever present.

   Local EIDs registered with the site-overlay mapping system must also
   be registered with the Uberlay Mapping System.  The registration of
   the local site-overlay EIDs with the uberlay Mapping System is
   originated by the Border xTRs.  The local site-overlay EIDs SHOULD be
   aggregated into the shortest covering prefix possible before being
   registered with the uberlay Mapping System.  How this aggregation is
   achieved is implementation specific.

   In order to be able to register the local site-overlay EIDs with the
   uberlay Mapping System, the border xTRs must subscribe to all EIDs
   registered in their local site-overlay Mapping System.  This is a
   subscription to 0.0.0.0/0 (or 0::/0) with the N-bit set as specified
   in [RFC9437].  The subscription populates all local site-overlay EID
   mappings in the map-cache of the border xTRs.

   Once received through the subscription, the local site-overlay EIDs
   in the map-cache at the border xTRs must be registered by the border
   xTRs with the uberlay Mapping System.  The local site-overlay EIDs
   will be registered using the 'uberlay' RLOC-set for the registering
   border xTR.

   Following [I-D.ietf-lisp-eid-mobility], the border xTRs will also
   subscribe to any EID prefixes it registers with the uberlay Mapping
   System.  This allows the border xTRs to get Map Notify messages from
   the uberlay Mapping System for EID prefixes that may move from their
   local site-overlay to a remote site-overlay.

4.1.1.  Split-horizon at the Border xTRs

   Remote site-overlay EIDs may be learnt at a border xTR due to
   resolution of a remote destination EID or due to a mobility event as
   specified in Section 6.  Remote site-overlay EIDs learnt from the
   uberlay will be installed in the map-cache of the border xTR with the
   corresponding remote uberlay RLOC-set for the remote border xTR.
   When these remote site-overlay EIDs are learnt as a consequence of
   the map-notify messages defined in the Inter-overlay mobility
   procedures in Section 6, the EIDs will also be registered with the
   local site-overlay mapping system using the local site-overlay RLOC-



Moreno, et al.           Expires 9 October 2025                [Page 10]

Internet-Draft                LISP Uberlay                    April 2025


   set for the border-xTR.  The remote site-overlay EIDs registered with
   the local site-overlay mapping system will be learnt back at the
   border xTR because of the border xTR's subscription to all local
   site-overlay EIDs.  This can cause the mapping for the remote EID
   that is installed in the border xTR map-cache to flip flop between
   the uberlay RLOC-set and the local site-overlay RLOC-set.

   In order to avoid this flip flopping a split horizon procedure must
   be implemented.  When a mapping received at the border xTR (as part
   of its subscription to all local site-overlay EID prefixes) has the
   local site-overlay RLOC-set for the border xTR, the mapping received
   in the subscription corresponds to a remote site-overlay EID and
   should be ignored by the border xTR.  The mapping should not be
   installed in the map-cache of the border xTR and the EIDs in the
   mapping should not be advertised to the uberlay.  More robust split
   horizon mechanisms can be proposed in future revisions of this
   specification.

4.1.2.  Border-xTR Resiliency

   Redundancy at the border xTRs requires that border xTRs be logically
   grouped so that the redundant array doesn’t create a registration
   loop.  As border xTRs interconnect overlay domains, the border xTRs
   will register the EID prefixes from one domain into the neighboring
   domain.  From the perspective of the border xTR, the EID prefixes to
   be registered in one domain are learnt from a neighbor domain which
   we will refer to as the "site-of-origin".  The site-of-origin may be
   an overlay-site, an Uberlay or an IP network.

   Border xTRs should be logically grouped in Border Sets.  A border set
   is a group of border xTRs that register EID prefixes from the same
   site-of-origin.  Members of a border set will register the EIDs from
   a particular site-of-origin into the neighboring overlay (site-
   overlay or uberlay) using a common site-id.  The use of the site-ID
   namespace is locally significant to each overlay domain (site-overlay
   or Uberlay) and does not require cross-domain synchronization or
   dispersion.  A border-xTR may be a member of multiple border sets to
   allow different site-of-origin domains to be serviced by the border-
   xTR.  Note that not all site-of-origin domains will connect to the
   same combination of border-xTRs.











Moreno, et al.           Expires 9 October 2025                [Page 11]

Internet-Draft                LISP Uberlay                    April 2025


   EID Mappings will be tagged with a site-ID according to their site-
   of-origin when they are registered by the border-xTR.  The site-ID
   must be maintained in the Mapping System as part of the registration
   record.  EID Mappings published and received at the border xTR must
   include the site-ID for the EID Mapping.  If the border-xTR receives
   a mapping for an EID with a site-ID that matches the site-ID for one
   of its border sets (site-of-origin), the Border xTR will not register
   that information to the site-of-origin associated with that site-ID
   and thus prevent any registration loops from occurring.

4.2.  Resolution and Forwarding Procedures

   Intra-site communication follows the standard procedures of
   registration, resolution, caching and encapsulation defined in
   [RFC9300] and [RFC9301] amongst the xTRs within the local site-
   overlay.

   Inter-site communication is achieved by encapsulating traffic
   destined to remote site-overlay EIDs from the xTRs to the border
   xTRs.  Traffic will be decapsulated at the border xTRs and a lookup
   in the uberlay mapping system will determine the site-overlay to
   which traffic is to be re-encapsulated.  The lookup should return the
   uberlay RLOCs for the border xTRs of the site-overlay where the
   destination EID is located.  At the border xTR of the destination
   overlay-site, traffic will be de-capsulated, and re-encapsulated to
   the destination xTR, just like an RTR does.  The border xTR already
   has the destination EID in its cache per its subscription to all
   local site-overlay EIDs.

   When receiving encapsulated traffic, a border xTR will de-capsulate
   the traffic and will do a lookup for the destination EID in its map
   cache.  If the destination EID is present in the map cache, the
   traffic is forwarded and no lookup takes place.  If the destination
   EID is not present in the cache, the destination EID is not in any
   local site-overlay connected to the border xTR, in which case the
   border xTR will issue a map-request to all Uberlay Mapping Systems it
   is connected to.  The criteria to determine which Mapping Systems are
   Uberlay Mapping Systems is simply to select those Mapping Systems
   with which the border xTR doesn't hold a subscription to 0.0.0.0/0
   (or 0::/0).











Moreno, et al.           Expires 9 October 2025                [Page 12]

Internet-Draft                LISP Uberlay                    April 2025


4.2.1.  Multi-overlay requests at border xTR

   A Border xTR may query all Mapping Systems in all uberlays it
   participates in.  The border xTR will then chose based on longest
   prefix match the more specific EID mapping provided by any of the
   Mapping Systems.  This procedure could also include site-overlay
   Mapping Systems, however those are not expected to be queried as the
   border xTR subscribes to all EIDs in the site-overlays and the
   presence of the mappings in the cache will prevent any lookups.  The
   processing of Map Requests following the multi-domain request logic
   works as follows:

   1.  The Border xTR sends a map request for the prefix that it intends
       to resolve to each of the uberlay Mapping Systems it participates
       in.

   2.  The Border xTR receives Map Replies from each of the different
       uberlay Mapping Systems it sent requests to.  The Border xTR will
       treat the replies differently depending on their contents:

       *  Negative Map Replies (NMR) are ignored and discarded unless
          all Map Replies received are Negative, then the border xTR
          follows the procedures specified in [RFC9301] for Negative Map
          Replies.

       *  Map Replies with RLOCs that belong to the requesting border
          xTR are ignored.

       *  Map Replies with EID prefixes that are not already in the map
          cache of the border xTR are accepted and cached.

       *  If the EID prefix received in the Map-Reply already exists in
          the cache/routing table, but the Map-Reply contains a
          different RLOC-set than the one cached, the mappings are
          merged so that the RLOCs received in the Map-Reply are added
          to the RLOC-set previously cached for the EID prefix.

       *  If the EID prefix received in the Map-Reply is more specific
          or less specific than an EID prefix already cached, the
          mapping received MUST be cached.

   It is expected that a deployment of the uberlay would include the
   dynamic registration of default EIDs.  It is also recommended that an
   implementation adopts mechanisms for the dynamic resolution of
   default EIDs.  In an environment leveraging the dynamic registration
   and resolution of default EIDs, the border xTR should not receive
   Negative Map-Replies, but all replies (including those in response to
   requests for destinations that are external to the EID space) will be



Moreno, et al.           Expires 9 October 2025                [Page 13]

Internet-Draft                LISP Uberlay                    April 2025


   Map-replies with a non-zero locator count.  Nevertheless, an
   implementation could opt to not use dynamic default-EID handling.  In
   these cases, the border xTR will receive NMRs.  The implementation of
   the Border xTR should defer the decision on caching an NMR until all
   relevant Map-replies are received.  To this effect, the
   implementation should implement mechanisms to ensure that sufficient
   replies are received before programming the map-cache.  The
   mechanisms by which this is achieved are an implementation specific
   matter and therefore not specified in this document.

   When following these rules to process multi-domain requests, the
   Border xTR guarantees proper discovery and use of destination
   prefixes that will be associated with their corresponding overlay-
   site.  By ignoring the negative replies the procedure works
   regardless of whether the Mapping Systems of multiple uberlays have
   consistent configurations or operate individually without being aware
   of the whole addressing space in the overlay fabric.

4.3.  Default EID registration and treatment

   Border xTRs will register a mapping to be used as a default mapping
   to handle the forwarding of traffic destined to any EIDs that are not
   explicitly registered.  These mappings will be registered in the
   local site-overlay Mapping System of each site-overlay.  The RLOCs
   for the mappings will be the site-overlay RLOCs of the border xTR.
   This registration is intended to instruct the Mapping System to
   follow the procedures in [RFC9301] for Negative Map Replies and
   calculate the broadest non-registered EID prefix that includes the
   requested destination EID and issue a map-reply with the calculated
   EID and the RLOCs registered by the border xTRs.  The map-reply for
   this default mapping will have a shorter TTL to accommodate any
   changes in the registrations.

   The instruction to the Mapping System can be encoded as the
   registration of an agreed upon distinguished name [RFC9735] such as
   "Default".  The registration will contain the RLOC set desired for
   the default handling.

5.  Multicast Specific Procedures

   This specification will focus on the procedures necessary to extend
   signal-free multicast [RFC8378] across multiple site-overlays
   interconnected with an uberlay.  The specification will focus on the
   extensions of the Sender and Receiver site procedures







Moreno, et al.           Expires 9 October 2025                [Page 14]

Internet-Draft                LISP Uberlay                    April 2025


5.1.  Inter-site-overlay Control Plane Procedures for Signal-free
      multicast

   1.  At the listener sites, xTRs with multicast listeners will follow
       the receiver site procedures described in [RFC8378].  A
       replication list will be built and registered on the site-overlay
       Mapping System for the multicast channel being joined by the
       listeners.

   2.  The Mapping System for the listener site-overlay will send Map-
       Notify messages towards the multicast source or RP per [RFC8378].
       The multicast source or RP is reachable via the border-xTRs of
       the listener site-overlay via the default EID mapping registered
       in the listener site-overlay.

   3.  Upon reception of the Map-Notify in the previous step, the
       listener site-overlay border-xTR will register the multicast EID
       with the uberlay Mapping System using the uberlay RLOCs for its
       site-overlay as the RLOC set for the mapping being registered.
       Only one of the RLOCs in the set should be active in the
       registration per the procedures in [RFC8378].  A replication tree
       is built in the uberlay as specified in [RFC8378].

   4.  After the listener site-overlay border-xTR registers the
       multicast EID with the uberlay Mapping system, the uberlay MS
       will send a Map-Notify toward the multicast source per [RFC8378]

   5.  Upon reception of the Map-Notify in the previous step, the border
       xTR at the source site-overlay registers its interest in the
       multicast EID with the source site-overlay Mapping System
       following the procedures described in [RFC8378].

5.2.  Border xTR Resolution and Forwarding procedures for Signal-free
      multicast

   The mapping resolution procedures for multicast EIDs at border xTRs
   fall within the scope of the mechanisms specified in Section 4.  The
   Map-replies obtained from the lookup will follow the behavior
   specified in [RFC8378] for signal-free multicast.

   Forwarding will also follow the General Procedures specified in
   Section 4 without alteration.  It is worth noting that the
   concatenation of overlays between listener sites, uberlay and sender
   site-overlays creates a convenient replication structure where the
   border xTRs act as the replication points to form an optimized end-
   to-end multi-level replication tree.





Moreno, et al.           Expires 9 October 2025                [Page 15]

Internet-Draft                LISP Uberlay                    April 2025


6.  Inter site-overlay Mobility Procedures

   The receiver and sender site procedures defined in
   [I-D.ietf-lisp-eid-mobility] apply without change to each site-
   overlay and to the uberlay.  Border xTRs are connected to two or more
   overlay networks which are following the mobility procedures.  An
   away table is defined at the border xTR for each overlay network it
   participates in.  In order to illustrate the procedures required,
   this specification describes a scenario where a border xTR has one
   local site-overlay away table and one uberlay facing away table.  The
   procedures for mobility described in this section are extensible to
   border xTRs participating in more than two overlays.

   When a map notify for an EID is received at an xTR, an away entry is
   created on the receiving side table.  Any away entries for the
   specific EID in other tables on the same LISP node (xTR or RTR) must
   be removed.  This general rule addresses convergence necessary for a
   first move as well as any subsequent moves (moves that take place
   after the away tables are already populated with entries for the
   moving EID due to previous moves).

   The following set of procedures highlights any additions to the
   mobility procedures defined in [I-D.ietf-lisp-eid-mobility]:

   1.   Detect the roaming EID per the mechanisms described in
        [I-D.ietf-lisp-eid-mobility] and register the EID with the site-
        overlay Mapping System at the landing site-overlay

   2.   The site-overlay Mapping System at the landing site-overlay must
        send a Map-Notify to the last registrant xTR (if it is local to
        the site-overlay) and to the border xTR as the border xTR
        subscribes to all EIDs in the site-overlay.

   3.   The border xTR will install an entry for the moved host in the
        local away table of the border xTR.

   4.   The border xTR from the landing site-overlay will register the
        roaming EID with the uberlay Mapping System using the uberlay
        RLOC-set for the landing site-overlay

   5.   The Uberlay Map Server will send Map-Notify messages to the
        border xTRs at the departure site-overlay as specified in
        [I-D.ietf-lisp-eid-mobility] (border xTR with the previously
        registered RLOCs).







Moreno, et al.           Expires 9 October 2025                [Page 16]

Internet-Draft                LISP Uberlay                    April 2025


   6.   Upon reception of the Map-Notify, the border xTR must check if
        the Map-Notify is for an EID-prefix that is covered by a broader
        or equal EID-prefix that is locally registered.  Local
        registration is determined by the presence of the broader or
        equal EID prefix in the map-cache of the border xTR.

   7.   If the roaming EID-prefix received in the Map-Notify is not
        covered under a previously registered EID-prefix in the local
        site-overlay, the EID-prefix is a newly registered prefix and no
        further action is required.

   8.   If the roaming EID-prefix received in the Map-Notify is covered
        under a registered EID-prefix, the Map-Notify is due to a move
        event.  In this case, the site-overlay border xTR must register
        the roaming EID prefix in the site-overlay mapping system using
        the site-overlay facing RLOC-set of the border-xTRs.  The
        roaming EID-prefix must also be installed in the uberlay facing
        away table of the border xTR at the departure site-overlay.

   9.   The departure site-overlay Map-Server will send Map-Notify
        messages to the xTRs at the departure site-overlay as specified
        in [I-D.ietf-lisp-eid-mobility] (edge xTRs with the previously
        registered RLOCs).

   10.  When the site-overlay xTR at the departure site-overlay receives
        the Map-Notify from the border xTR, it will include the EID
        prefix received in the Map-Notify in its away table per the
        procedures described in [I-D.ietf-lisp-eid-mobility].

   11.  Data triggered Solicit Map Requests (SMRs) will be initiated in
        the different site-overlays and the uberlay as traffic matches
        the different away tables.  As specified in
        [I-D.ietf-lisp-eid-mobility], these SMRs notify the different
        ITRs involved in communications with the roaming EID that they
        must issue a new Map-Request to the mapping system to renew
        their mappings for the roaming EID.

7.  Virtual Private Network (VPN) Considerations

   When supporting multiple Instance IDs as specified in
   [I-D.ietf-lisp-vpn] the Instance IDs range is divided in two sets.  A
   reuse-set that can be used in each site-overlay and a global-set used
   across site-overlays and the uberlay.








Moreno, et al.           Expires 9 October 2025                [Page 17]

Internet-Draft                LISP Uberlay                    April 2025


   Instance-IDs that are local to a site-overlay should only provide
   intra-overlay connectivity and are in the site-overlay mapping system
   only for VPN use for the xTRs in the site-overlay.  When the VPN
   reaches across site-overlays, then the global-set instance-IDs are in
   the uberlay mapping system as well as each site-overlay mapping
   system where the VPN members exist.

8.  IANA Considerations

   This document has no IANA implications

9.  Acknowledgements

   The authors want to thank Kedar Karamarkar, Prakash Jain and Vina
   Ermagan for their insightful contribution to shaping the ideas in
   this document.  We would also like to acknowledge the valuable input
   from the workgroup chairs Joel Halpern and Luigi Iannone in refining
   the objectives of the document.

10.  References

10.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/info/rfc2119>.

10.2.  Informative References

   [I-D.farinacci-lisp-decent]
              Farinacci, D. and C. Cantrell, "A Decent LISP Mapping
              System (LISP-Decent)", Work in Progress, Internet-Draft,
              draft-farinacci-lisp-decent-16, 27 December 2024,
              <https://datatracker.ietf.org/doc/html/draft-farinacci-
              lisp-decent-16>.

   [I-D.ietf-lisp-eid-mobility]
              Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno,
              V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
              Unified Control Plane", Work in Progress, Internet-Draft,
              draft-ietf-lisp-eid-mobility-15, 4 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              eid-mobility-15>.

   [I-D.ietf-lisp-vpn]
              Moreno, V. and D. Farinacci, "LISP Virtual Private
              Networks (VPNs)", Work in Progress, Internet-Draft, draft-



Moreno, et al.           Expires 9 October 2025                [Page 18]

Internet-Draft                LISP Uberlay                    April 2025


              ietf-lisp-vpn-12, 19 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              vpn-12>.

   [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
              Smirnov, "Locator/ID Separation Protocol Delegated
              Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
              May 2017, <https://www.rfc-editor.org/info/rfc8111>.

   [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
              Separation Protocol (LISP) Multicast", RFC 8378,
              DOI 10.17487/RFC8378, May 2018,
              <https://www.rfc-editor.org/info/rfc8378>.

   [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos, Ed., "The Locator/ID Separation Protocol
              (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
              <https://www.rfc-editor.org/info/rfc9300>.

   [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
              Ed., "Locator/ID Separation Protocol (LISP) Control
              Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
              <https://www.rfc-editor.org/info/rfc9301>.

   [RFC9437]  Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
              S., and M. Boucadair, "Publish/Subscribe Functionality for
              the Locator/ID Separation Protocol (LISP)", RFC 9437,
              DOI 10.17487/RFC9437, August 2023,
              <https://www.rfc-editor.org/info/rfc9437>.

   [RFC9735]  Farinacci, D. and L. Iannone, Ed., "Locator/ID Separation
              Protocol (LISP) Distinguished Name Encoding", RFC 9735,
              DOI 10.17487/RFC9735, February 2025,
              <https://www.rfc-editor.org/info/rfc9735>.

Authors' Addresses

   Victor Moreno
   Google LLC
   1600 Amphitheater Parkway
   Mountain View, California 94043
   United States of America
   Email: vimoreno@google.com








Moreno, et al.           Expires 9 October 2025                [Page 19]

Internet-Draft                LISP Uberlay                    April 2025


   Dino Farinacci
   lispers.net
   San Jose, CA 95120
   United States of America
   Email: farinacci@gmail.com


   Alberto Rodriguez-Natal
   Cisco Systems
   170 Tasman Drive
   San Jose, California 95134
   United States of America
   Email: natal@cisco.com


   Marc Portoles-Comeras
   Cisco Systems
   170 Tasman Drive
   San Jose, California 95134
   United States of America
   Email: mportole@cisco.com


   Fabio Maino
   Cisco Systems
   170 Tasman Drive
   San Jose, California 95134
   United States of America
   Email: fmaino@cisco.com


   Sanjay Hooda
   Cisco Systems
   170 Tasman Drive
   San Jose, California 95134
   United States of America
   Email: shooda@cisco.com














Moreno, et al.           Expires 9 October 2025                [Page 20]


name: draft-yue-moq-transporting-sensing-data
rev: 03
title: Challenges in Transporting Sensing Data with Media Over QUIC
time: 2025-10-19T02:01:16Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-22T02:01:16Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Data formats/interop", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:10.243436+00:00
abstract:
This document proposes leveraging Media Over QUIC (MOQ) to address
   the challenges of transmitting large-scale, real-time sensing data in
   6G networks.  By building on QUIC's low-latency and multiplexing
   capabilities, MOQ offers a flexible and efficient transport mechanism
   tailored to the dynamic and high-throughput requirements of 6G
   environments.  The approach focuses on enabling protocol adaptability
   across diverse application scenarios such as autonomous driving,
   smart cities, and industrial IoT, while ensuring efficient data
   fragmentation, secure and anonymous transmission, and end-to-end QoS
   awareness.  Through information-aware endpoints and optimized data
   delivery mechanisms, this solution supports scalable, reliable, and
   intelligent sensing data distribution in next-generation wireless
   networks.  It is also available to other types of 6G System Data
   [3GPP.22.870] besides sensing data, e.g., AI data, positioning data.

full_text:
moq                                                          Y. Yue, Ed.
Internet-Draft                                                F. Li, Ed.
Intended status: Standards Track                             W. Liu, Ed.
Expires: 22 April 2026                                      China Unicom
                                                            C. Yang, Ed.
                                                        A. Akhavain, Ed.
                                                           K. Zhang, Ed.
                                           Huawei Technologies Co., Ltd.
                                                          M. Jadoon, Ed.
                                                       S. Robitzsch, Ed.
                                                InterDigital Europe Ltd.
                                                         19 October 2025


      Challenges in Transporting Sensing Data with Media Over QUIC
               draft-yue-moq-transporting-sensing-data-03

Abstract

   This document proposes leveraging Media Over QUIC (MOQ) to address
   the challenges of transmitting large-scale, real-time sensing data in
   6G networks.  By building on QUIC's low-latency and multiplexing
   capabilities, MOQ offers a flexible and efficient transport mechanism
   tailored to the dynamic and high-throughput requirements of 6G
   environments.  The approach focuses on enabling protocol adaptability
   across diverse application scenarios such as autonomous driving,
   smart cities, and industrial IoT, while ensuring efficient data
   fragmentation, secure and anonymous transmission, and end-to-end QoS
   awareness.  Through information-aware endpoints and optimized data
   delivery mechanisms, this solution supports scalable, reliable, and
   intelligent sensing data distribution in next-generation wireless
   networks.  It is also available to other types of 6G System Data
   [3GPP.22.870] besides sensing data, e.g., AI data, positioning data.

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



Yue, et al.               Expires 22 April 2026                 [Page 1]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   This Internet-Draft will expire on 22 April 2026.

Copyright Notice

   Copyright (c) 2025 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 . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Autonomous Vehicles . . . . . . . . . . . . . . . . . . .   4
     3.2.  Smart Cities  . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Industrial IoT  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Multi-Scenario Applicability  . . . . . . . . . . . . . .   5
     4.2.  Efficient Data Transmission . . . . . . . . . . . . . . .   5
     4.3.  Anonymity . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Data Security . . . . . . . . . . . . . . . . . . . . . .   6
     4.5.  Traceability  . . . . . . . . . . . . . . . . . . . . . .   6
     4.6.  Information Awareness . . . . . . . . . . . . . . . . . .   6
     4.7.  Multi-Source Federation & Scale . . . . . . . . . . . . .   6
   5.  Publish-subscribe mechanism for data distribution . . . . . .   7
     5.1.  Why Pub-Sub and MoQ for Data Distribution . . . . . . . .   7
     5.2.  Benefits of Pub-Sub Mechanism for Data Distribution . . .   8
   6.  Pub-Sub Flows for Data Distribution . . . . . . . . . . . . .   8
     6.1.  Data Publish Flows  . . . . . . . . . . . . . . . . . . .   9
     6.2.  Data Subscribe Flows  . . . . . . . . . . . . . . . . . .  10
   7.  MoQ Protocol Enhancements for Sensing Data Transport  . . . .  11
     7.1.  Conceptual Object Format with Metadata Extension  . . . .  11
     7.2.  Extended Metadata Fields  . . . . . . . . . . . . . . . .  13
       7.2.1.  Data Information  . . . . . . . . . . . . . . . . . .  13
       7.2.2.  Network Information . . . . . . . . . . . . . . . . .  13
       7.2.3.  Service and Task Context  . . . . . . . . . . . . . .  14
       7.2.4.  QoS Information . . . . . . . . . . . . . . . . . . .  14
     7.3.  Protocol Behavior Enhancements  . . . . . . . . . . . . .  15
       7.3.1.  Control Plane Coordination  . . . . . . . . . . . . .  15
       7.3.2.  Failure Feedback Mechanisms . . . . . . . . . . . . .  15



Yue, et al.               Expires 22 April 2026                 [Page 2]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   With the advent of 6G networks, there is an exponential increase in
   the volume and diversity of data generated by connected devices,
   sensors, and applications.  This data, known as "sensing data,"
   encompasses a wide range of information, including environmental,
   contextual, and behavioral data that can be leveraged for various
   advanced applications like autonomous driving, smart cities, and
   industrial IoT.  However, transmitting this sensing data efficiently
   in a 6G environment poses a significant challenge due to its large
   volume, distributed and massive number of sources , dynamic nature,
   and stringent real-time requirements.

   Media Over QUIC (MOQ) [*I-D.ietf-moq-transport*], a protocol designed
   to enable efficient media transport over QUIC, presents a promising
   solution for addressing these challenges.  QUIC, being a modern
   transport protocol, provides low-latency, multiplexed connections
   with enhanced congestion control, making it well-suited for real-time
   communication in dynamic networks.  MOQ builds on QUIC's capabilities
   to offer a robust and flexible framework for the high-throughput and
   low-latency transmission of multimedia data.

   This document explores how MOQ can be leveraged to efficiently
   transmit sensing data in 6G networks, focusing on its potential to
   handle the unique requirements of real-time, high-volume data streams
   while ensuring reliability, scalability, and low overhead.  The use
   of MOQ for data transport in this context can significantly improve
   the user experience and enable innovative services in next-generation
   wireless communication networks.

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.  Abbreviations and definitions used in this
   document: *MOQ: Media Over QUIC *V2V: Vehicle-to-Vehicle. *P2P:
   Point-to-Point





Yue, et al.               Expires 22 April 2026                 [Page 3]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


3.  Use Cases

   [*I-D.lcurley-moq-use-cases*] defines several use cases for MOQ,
   while this document focuses on MOQ use cases in the context of
   sensing data transmission.

3.1.  Autonomous Vehicles

   Autonomous vehicles rely on real-time sensing data from onboard
   sensors (e.g., LiDAR, cameras) and external sources (e.g., traffic
   signals, nearby vehicles).  MOQ facilitates the efficient and
   reliable transmission of this data in the following ways: 1.
   Vehicle-to-Vehicle (V2V) Communication: MOQ over QUIC establishes
   low-latency, multiplexed streams between vehicles, enabling the
   exchange of situational data like location, speed, and hazards in
   real-time. 2.  Data Prioritization: High-priority sensing data, such
   as collision warnings, is tagged for immediate transmission, while
   less critical data, like traffic updates, is sent with lower priority
   to optimize bandwidth.

3.2.  Smart Cities

   Smart cities generate diverse types of sensing data from devices such
   as traffic cameras, pollution monitors, and utility sensors.  MOQ
   enhances urban management through: 1.  Adaptive Data Aggregation:
   Sensors stream data to edge servers via MOQ's multiplexed
   connections, which dynamically adapt to varying link conditions to
   prevent packet loss during congestion. 2.  Real-Time Event Streaming:
   For critical events (e.g., emergencies or system failures), MOQ
   ensures prioritized and low-latency delivery of sensor data to
   central control systems or cloud platforms for immediate response.

3.3.  Industrial IoT

   Factories equipped with IoT sensors require reliable, low-latency
   communication to monitor and optimize operations.  MOQ supports
   industrial IoT through: 1.  Real-Time Monitoring: MOQ streams sensor
   data such as vibration or temperature directly to monitoring systems,
   ensuring fast anomaly detection and response. 2.  Redundant
   Transmission: For critical sensing data, MOQ can enable redundant
   streams over QUIC to ensure delivery even under adverse network
   conditions.









Yue, et al.               Expires 22 April 2026                 [Page 4]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


4.  Problem Statement

   The application of Media Over QUIC (MOQ) for transmitting sensing
   data in 6G networks presents several key challenges that must be
   addressed to ensure its feasibility and effectiveness.  These
   challenges are as follows:

4.1.  Multi-Scenario Applicability

   Sensing data in 6G networks is generated in diverse scenarios,
   ranging from autonomous vehicles to smart cities and industrial IoT.
   Each scenario imposes unique requirements on the transport protocol,
   such as varying latency, throughput, and reliability demands.  These
   use cases may involve real-time synchronous or asynchronous data
   transmission, as well as point to point (P2P) or multi-point
   communication modes.  Ensuring that MOQ can adapt to these diverse
   requirements without compromising performance or introducing overhead
   remains a significant challenge , e.g., how to differentiate
   transmissions of sensing data flows with varying demands.

4.2.  Efficient Data Transmission

   The sheer volume and velocity of sensing data in 6G networks
   necessitate highly efficient transport mechanisms.  MOQ must address
   issues such as reducing overhead for small and frequent data packets,
   optimizing transmission for bursty data patterns, and ensuring low-
   latency delivery even under high traffic loads.  Balancing efficient
   utilization of network resources while maintaining robust performance
   is critical.  Avoid redundant data collection and transmission, e.g.,
   to cache data on demand.

4.3.  Anonymity

   In applications such as smart cities and industrial IoT, sensing data
   often includes sensitive or identifiable information.  Ensuring
   anonymity during transmission is essential to protect user privacy
   and comply with regulatory requirements.  MOQ must integrate
   mechanisms to obscure identifying information in data streams while
   maintaining the integrity and usability of the transmitted data.
   Data sources and data consumers are not aware of each other.











Yue, et al.               Expires 22 April 2026                 [Page 5]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


4.4.  Data Security

   Sensing data in 6G networks is often critical to the operation of
   real-time systems, making it a prime target for cyber threats such as
   interception, tampering, and unauthorized access.  MOQ must
   incorporate advanced security measures to guarantee the
   confidentiality, integrity, and authenticity of data in transit.
   Additionally, the protocol must address the challenge of securely
   transmitting data in dynamic and heterogeneous network environments,
   including cross-domain communication.  Data payload is visible only
   to data sources and data consumers, and is invisible to intermediate
   nodes.  The payload needs to be encrypted.

4.5.  Traceability

   Sensing data logs can be recorded, and data collection and
   consumption history is traceable.

4.6.  Information Awareness

   MOQ endpoints should be aware of key contextual information related
   to sensing data to enable efficient and intelligent data
   distribution.  This includes: 1.  Network Awareness: The MOQ endpoint
   should have knowledge of network-related sensing data, such as cell
   or sensing area information, to optimize data distribution decisions.
   2.  QoS Awareness: MOQ should ensure QoS guarantees for the
   collection and transmission of sensing data, adjusting delivery
   mechanisms accordingly.  Service Awareness: The MOQ endpoint should
   identify the intended service or application utilizing the sensing
   data.  This enables proper classification, retrieval, and
   provisioning of sensing data to authorized services.

4.7.  Multi-Source Federation & Scale

   Sensing in future networks is expected to involve a large number of
   distributed and heterogeneous sources, such as base stations, user
   devices, roadside units, and access points.  Each source may produce
   sensing data of different types and at different temporal or spatial
   resolutions.  When combined across diverse sensing tasks and use
   cases, the overall volume of generated data can become massive.
   Managing such a distributed and data-intensive environment raises
   challenges in terms of scalability, coordination, and resource
   efficiency.  Multiple sensing entities may observe overlapping
   environments, leading to redundant or partially correlated
   information.  Without mechanisms to coordinate data generation and
   dissemination, the resulting data traffic can impose significant load
   on transport infrastructure.  Therefore, scalability in sensing
   networks is not only a matter of bandwidth or throughput but also of



Yue, et al.               Expires 22 April 2026                 [Page 6]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   how effectively information from numerous and diverse sources can be
   collected, organized, and made available to the entities that need
   it.  This requires careful consideration of data distribution
   principles that can operate efficiently under high source/destination
   density and dynamic network conditions.

5.  Publish-subscribe mechanism for data distribution

5.1.  Why Pub-Sub and MoQ for Data Distribution

   Large-scale sensing deployments, such as those envisioned for next-
   generation networks [3GPP.SA2.6G.SID], [3GPP.22.137], [3GPP.22.870],
   [ETSI.GRISC.001], can produce an immense and continuous flow of
   heterogeneous information ranging from assistance data, sensing
   measurements to sensing data, both attached with metadata, to sensing
   results that has contextual information attached.  When multiple
   sensing use cases operate concurrently, for example, object tracking,
   localization, and environmental monitoring, the aggregate volume of
   information can become substantial.  Using traditional web-based
   client-server application and point-to-point transport protocols to
   move such heterogeneous information across a mobile network, risks
   creating severe networking and processing bottlenecks.  Furthermore,
   the heterogenous information comes with severely different quality of
   service (QoS) requirements when being exchanged between two endpoints
   in the mobile network, with those endpoints possible to change at any
   point in time due to the mobile nature of terminals.

   Existing protocols generally require dedicated sessions per source or
   per consumer, leading to duplicated transmissions, inefficient
   resource use, and reduced timeliness as the system scales and the
   same set of information from a single source is required at different
   destinations, e.g. allowing multiple instances at different parts of
   the mobile network to process information to identify the most
   reliable and accurate result.

   To address these scalability and dynamism challenges, a _publish/
   subscribe_ information distribution model is more suitable.  It
   decouples data producers and consumers, allowing information
   generated by many sensing entities to be distributed flexibly and
   efficiently to multiple analytics or network/application functions
   without maintaining direct session state between every pair.  Such a
   model enables aggregation, filtering, and routing of sensing
   information according to spatial, temporal, or service-level needs,
   significantly improving scalability and resilience.

   Within the IETF, the Media over QUIC Transport (MOQT) protocol
   provides a foundation for realizing such an efficient, object-
   oriented, and real-time publish/subscribe distribution system.  MOQT



Yue, et al.               Expires 22 April 2026                 [Page 7]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   builds upon QUIC’s secure, congestion-controlled transport and
   introduces mechanisms for scalable dissemination of time-sensitive
   data.  Its general design principles – publisher – subscriber
   decoupling, adaptive data delivery, and relay-based distribution,
   align well with the characteristics of sensing data and the need to
   serve multiple simultaneous use cases in a resource-efficient manner.

   In summary, adopting a publish/subscribe distribution approach,
   supported by technologies such as MOQ, offers a path to transport
   sensing information at scale while maintaining efficiency,
   flexibility, and timeliness across diverse sensing applications.

5.2.  Benefits of Pub-Sub Mechanism for Data Distribution

   *  *Flexible and scalable:* applicable to Point to point/Multi-points
      data distribution, real-time synchronous or asynchronous data
      transmission,

   *  *Efficient data distribution:* any of the on-path Data Proxies can
      cache/store data, to avoid redundant data collection and
      transmission.

   *  *Data privacy and security:* Data payload is visible only to data
      sources and data consumers, and is invisible to Data-Proxy.

6.  Pub-Sub Flows for Data Distribution

   To support multi-scenario applicability of 6G system data (e.g.,
   sensing data) distribution, aspects such as Network topology and
   transmission requirement should be taken into consideration:

    *1.  Network topology:* Providers and consumers of 6G system data
   (e.g., sensing data) are highly distributed in 6G network.  P2P data
   distribution and point to multi-points (P2MP) data distribution are
   coexisted.

    *2.  Transmission requirement:* Different scenarios impose unique
   requirements in data sensing transmission, such as varying latency
   and throughput, real-time synchronous and asynchronous etc.  Even the
   same data source might be consumed in different requirements by
   consumers.

   Due to these these aspects, a publish/subscribe information model is
   required.

   _The publish/subscribe topology is illustrated in the figure below:_





Yue, et al.               Expires 22 April 2026                 [Page 8]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


                                +-------+
           +------------------->| Data  |----------------------+
           |         Data +-->--| proxy2|-->--+  Data          |
           |      session/      +-------+      \ session       |
           |            /         |  ^          \              |
           | Pub      (2)     Sub |  | Sub      (3)        Pub |
           |          /           |  |            \            |
           |         /            |  |             \           |
           |        /             |  |              \          |
           |    +-------+         |  |            +-------+    |
           +----| Data  |<--------+  +------------| Data  |<---+
     +--------->| proxy1|--+    +---------------->| proxy3|---------------+
     |          +-------+  |    |         +---<---+-------+--->---+       |
     |            |        |    |         |         |  ^          |       |
     | Pub       (1)   Sub |    | Sub     |     Pub |  | Sub      |   Pub |
     |            |        |    |       (4.1)       |  |        (4.2)     |
     |            ^        |    |         |         |  |          |       |
     |        Data|        |    |     Data|         |  |     Data |       |
     |     session|        |    |  session|         |  |   session|       |
     |            |        |    |         |         |  |          |       |
     |            |        |    |         |         |  |          |       |
     |   +------------+    |    |  +------------+   |  |  +------------+  |
     +---|   Data     |<---+    +--|    Data    |<--+  +--|    Data    |<-+
         | provider 1 |            | consumer 1 |         | consumer 2 |
    |    +------------+            +------------+         +------------+
    ^                        |
    |    +------------+      |
    +----|   Data     |<-----+
     Pub | provider 2 |   Sub
         +------------+

   _In this figure, data proxies act as MoQ relays, data providers are
   original publishers of data (e.g., sensing data) and consumers are
   end subscribers requesting for data._

6.1.  Data Publish Flows

   1.  Data providers (e.g., Data provide 1&2) publish metadata (e.g.,
       sensing metadata) of 6G system data to upstream data proxies
       (e.g., Data-proxy 1) based on the MoQ publish mechanism and
       procedure.  The data proxies can be new type of logical endpoints
       or other data providers or consumers.  This metadata may include
       non-exhaustively: data information, network information, service
       information and QoS information (refer to descriptions in
       following sections).






Yue, et al.               Expires 22 April 2026                 [Page 9]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   2.  The upstream data proxies active as publishers can continue
       publish metadata of 6G system data to their upstream endpoints
       (e.g., Data proxy 2).  Considering that different endpoints may
       have different capabilities and network contextual status, the
       published information by upstream endpoints (e.g., Data proxy 2)
       might be different from the original data provider’s.  Moreover,
       the upstream endpoints (e.g., Data-proxies) may perform some data
       processing actions (e.g., data cleaning, data filtering, data
       aggregation, data anonymization) before publish.

   3.  The metadata (e.g., sensing metadata) of 6G system data are
       published hop by hop to related upstream data proxies and/or data
       consumers, e.g., by specific policy.

6.2.  Data Subscribe Flows

    After the publish process,

   1.  Data Consumer (e.g., sensing data consumer 1) active as Original
       Subscriber sends MoQ subscribe messages to its downstream
       endpoint (e.g., Data-proxy 3).  The data consumer may select one
       of connected Data-proxies based on its specific demand on 6G
       system data (e.g., sensing data) and sends subscribe message.

   2.  Once the downstream endpoint (e.g., Data-proxy 3) receive the
       subscribe message, it will check whether there is available data
       (e.g., caching data), if there is, the downstream endpoint can
       send the available data to he Data Consumer; otherwise, the
       downstream endpoint will send MoQ subscribe messages to its
       downstream endpoints (e.g., Data-proxy 2) and so forth until the
       available data is found.  For example, the available data is
       found from Data Provider 1.

   3.  A data session (consisting of MoQ session) can be established
       between the Data Provider 1 and the Data Consumer.

   4.  It is possible that more than one Data Consumers (e.g., Data
       Consumer 1 and 2 as in the figure) request the same data.  The
       Data-proxy (e.g., Data-proxy 3) can collect data only once from
       Data Provider (e.g., data provider 1) and replicates the data to
       the Data consumers respectively.  It can reduce redundancy of
       data collection and data delivery.  Moreover, the Data Proxy can
       cache the collected data if necessary for further requests (e.g.,
       other data consumers' requests for the same data).







Yue, et al.               Expires 22 April 2026                [Page 10]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


7.  MoQ Protocol Enhancements for Sensing Data Transport

   To support the efficient and intelligent transmission of sensing data
   in 6G environments, enhancements to the MoQ protocol are proposed.
   These enhancements aim to enrich MoQ metadata or header extensions to
   include key information required for intelligent routing, data
   classification, service mapping, and QoS-aware scheduling in sensing-
   centric applications.

7.1.  Conceptual Object Format with Metadata Extension

   The following diagram illustrates a conceptual format for a MoQ
   object with enhanced metadata fields for sensing applications:






































Yue, et al.               Expires 22 April 2026                [Page 11]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


      +-------------------------------+
      |       MoQ Object Header       |
      +-------------------------------+
      |  - Object Name                |
      |  - Object Type                |
      |  - Duration (optional)        |
      |  - Group ID / Track ID        |
      +-------------------------------+
      |  Extended Metadata Header     |
      +-------------------------------+
      |  - Metadata Type (e.g., TLV)  |
      |  - Length                     |
      +-------------------------------+
      |           Data Info           |
      |  - Data Name                  |
      |  - Data Feature               |
      |  - Semantics Token            |
      |  - Data Representation        |
      |  - Data Hash                  |
      +-------------------------------+
      |         Network Info          |
      |  - Network ID (PLMN ID)       |
      |  - Cell ID                    |
      |  - Node ID                    |
      |  - Tracking Area Code         |
      |  - Sensing Region ID          |
      +-------------------------------+
      |        Service Info           |
      |  - Service ID                 |
      |  - Task ID                    |
      |  - Mission ID                 |
      |  - SFC ID                     |
      +-------------------------------+
      |          QoS Info             |
      |  - QoS Identifier (QI)        |
      |  - Timestamp                  |
      |  - data quality               |
      |  - data transmission QoS      |
      |  - data processing QoS        |
      +-------------------------------+
      |          Payload              |
      |      (Encrypted Data)         |
      +-------------------------------+








Yue, et al.               Expires 22 April 2026                [Page 12]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


7.2.  Extended Metadata Fields

   The following categories of metadata are recommended to be included
   in MoQ object headers or extension fields, either through expansion
   of the existing metadata field (e.g., the new information are some
   bits of the existing metadata fields) or through the definition of
   new metadata elements:

7.2.1.  Data Information

   Metadata related to the content and identity of the sensing data:

   (1) data_keyword: Keywords or descriptors representing data semantics
   of content.

   (2) data_feature: Characteristics such as modality, format or other
   attributes.

   (3) data_representation: Encoding type (e.g., JSON, CBOR, binary).

   (4) data_name: Human-readable or system-assigned identifier.

   (5) semantics: Token-level annotations describing data meaning.

   (6) hash: Hash value of content, e.g., for indexing or integrity
   verification.

7.2.2.  Network Information

   Network-related metadata used to describe the contextual origin or
   association of the data.  One or more of the following fields may be
   included:

   (1) network_id (e.g., PLMN ID): Identifies the network to which the
   data belongs.  This may refer to the network in which the data was
   collected or published, the network the data describes, or the
   network in which the sensing node resides.

   (2) cell_id: Identifies the cell associated with the data.  This may
   refer to the cell where the data was collected or published, the cell
   the data is about, or the cell in which the sensing node resides.

   (3) node_id: Identifies the network node associated with the data.
   This may be the node that collected or published the data, or the
   node the data describes.






Yue, et al.               Expires 22 April 2026                [Page 13]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   (4) tracking_area_code (TAC): Identifies the tracking area to which
   the data belongs.  This may refer to the area where the data was
   collected/published, the area the data is about, or the area in which
   the relevant node resides.

   (5) sensing_region_id: Identifies the sensing region associated with
   the data.  This may refer to the region where the data was collected,
   the region being sensed, the region where the sensing node resides,
   or the region where the sensed object is located.

7.2.3.  Service and Task Context

   Metadata describing the service or task context associated with the
   data.  One or more of the following fields may be included:

   (1) service_id: Identifies the service to which the data is related.
   For example, it indicates that data can be used by an AI service,
   sensing service, XR service, etc.

   (2) task_id: Identifies a specific task that processes the data.  A
   task may include AI model training, inference, data preprocessing,
   data analysis, privacy-preserving operations, or data distribution.

   (3) mission_id: Identifies a task group (or job), which consists of
   multiple tasks that are executed in a predefined sequence (e.g.,
   sequential or parallel).  The data is used as input for this mission.

   (4) sfc_id: Identifies a Service Function Chain (SFC).  The data is
   used for processing through the corresponding service function chain.

7.2.4.  QoS Information

   Metadata related to the quality of service requirements for the data.
   One or more of the following fields may be included:

   (1) QI (QoS Identifier): Represents a QoS class or profile, which may
   imply specific parameters such as maximum delay budget for
   processing, or end-to-end latency requirements (e.g., including both
   transmission and processing delays). (2) timestamp: Indicates the
   time at which the data was generated by the source or forwarded by an
   intermediate node.  This can be used to calculate end-to-end latency
   or time spent in transit.  The timestamp may be provided at different
   granularity levels, such as per object, group, or track.

   (3) data quality: identify quality metrics on data itself, e.g.,
   accuracy, completeness, reliability, redundancy, bias, source
   reliability, and integrity.




Yue, et al.               Expires 22 April 2026                [Page 14]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   (4) data transmission QoS: Indicates QoS requirement (e.g., delay) on
   data transmission.

   (5) data processing QoS: Indicates QoS requirement (e.g., delay,
   accuracy) on data processing, e.g., data cleaning, data
   anonymization, data analysis, or data generation.

7.3.  Protocol Behavior Enhancements

   In addition to metadata enrichment, certain behavioral extensions are
   necessary when applying MoQ to sensing applications, especially when
   operating at the user plane (UP) or data plane in 6G architectures:

7.3.1.  Control Plane Coordination

   MoQ endpoints deployed in sensing environments may require dynamic
   interaction with the control plane to receive configuration
   parameters, access control policies, and data routing instructions.
   This includes the ability to register interests or capability to
   control plane, or notify the control plane upon data path failures or
   when requested publishers are not found.

7.3.2.  Failure Feedback Mechanisms

   In cases where a MoQ subscriber is unable to locate a publisher
   (e.g., within limited time or hops) for the required sensing data,
   the protocol should support mechanisms to notify upstream
   orchestration entities or the control plane for further resolution or
   dynamic path redirection and publisher reselection.

8.  Security Considerations

   TBD

9.  IANA Considerations

   TBD

10.  References

10.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/info/rfc2119 (https://www.rfc-
      editor.org/info/rfc2119).





Yue, et al.               Expires 22 April 2026                [Page 15]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   *  [*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/info/rfc8174 (https://www.rfc-
      editor.org/info/rfc8174).

10.2.  Informative References

   *  [*3GPP.22.870*] 3GPP TR22.870, "Study on 6G Use Cases and Service
      Requirements",

      https://portal.3gpp.org/desktopmodules/Specifications/
      SpecificationDetails.aspx?specificationId=4374
      (https://portal.3gpp.org/desktopmodules/Specifications/
      SpecificationDetails.aspx?specificationId=4374).

   *  [*I-D.ietf-moq-transport*] Nandakumar, S., Vasiliev, V., Swett,
      I., and A.  Frindell, "Media over QUIC Transport", Work in
      Progress, Internet-Draft, draft-ietf-moq-transport-14, 2 September
      2025, https://datatracker.ietf.org/doc/html/draft-ietf-moq-
      transport-14 (https://datatracker.ietf.org/doc/html/draft-ietf-
      moq-transport-14).

   *  [*I-D.lcurley-moq-use-cases*] Curley, L., "Media over QUIC - Use
      Cases", Work in Progress, Internet-Draft, draft-lcurley-moq-use-
      cases-01, 22 July 2025, https://datatracker.ietf.org/doc/html/
      draft-lcurley-moq-use-cases-01
      (https://datatracker.ietf.org/doc/html/draft-lcurley-moq-use-
      cases-01).

   *  [*3GPP.SA2.6G.SID*] 3GPP SP-250806, "Study on Architecture for 6G
      System".

   *  [*3GPP.22.137*] 3GPP TS22.137, "Service requirements for
      Integrated Sensing and Communication",

      https://portal.3gpp.org/desktopmodules/Specifications/
      SpecificationDetails.aspx?specificationId=4198
      (https://portal.3gpp.org/desktopmodules/Specifications/
      SpecificationDetails.aspx?specificationId=4198).

   *  [*ETSI.GRISC.001*] ETSI ISAC ISG, "ISAC; Generic reference
      architecture for Integrated Sensing And Communications (ISAC),"
      ETSI GR ISC 001 - V1.1.1, 2025,
      https://www.etsi.org/deliver/etsi_gr/ISC/001_099/001/01.01.01_60/
      gr_isc001v010101p.pdf
      (https://www.etsi.org/deliver/etsi_gr/ISC/001_099/001/01.01.01_60/
      gr_isc001v010101p.pdf).




Yue, et al.               Expires 22 April 2026                [Page 16]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


Authors' Addresses

   Yi Yue (editor)
   China Unicom
   Beijing
   China
   Email: yuey80@chinaunicom.cn


   Feile Li (editor)
   China Unicom
   Beijing
   China
   Email: lifl100@chinaunicom.cn


   Wei Liu (editor)
   China Unicom
   Beijing
   China
   Email: liuw550@chinaunicom.cn


   Chenchen Yang (editor)
   Huawei Technologies Co., Ltd.
   Shanghai
   China
   Email: yangchenchen7@huawei.com


   Arashmid Akhavain (editor)
   Huawei Technologies Co., Ltd.
   Ottawa
   Canada
   Email: arashmid.akhavain@huawei.com


   Kuan Zhang (editor)
   Huawei Technologies Co., Ltd.
   Shanghai
   China
   Email: zhangkuan3@huawei.com


   Muhammad Awais Jadoon (editor)
   InterDigital Europe Ltd.
   London
   United Kingdom



Yue, et al.               Expires 22 April 2026                [Page 17]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   Email: Muhammad.AwaisJadoon@InterDigital.com


   Sebastian Robitzsch (editor)
   InterDigital Europe Ltd.
   London
   United Kingdom
   Email: Sebastian.Robitzsch@InterDigital.com











































Yue, et al.               Expires 22 April 2026                [Page 18]


name: draft-ahn-nmrg-5g-security-i2nsf-framework
rev: 01
title: An Integrated Security Service System for 5G Networks using an I2NSF Framework
time: 2026-02-25T08:28:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T08:28:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Autonomous netops", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:10.243441+00:00
abstract:
This document presents an integrated framework for automated security
   management in 5G edge networks using the Interface to Network
   Security Functions (I2NSF) architecture.  The proposed system
   leverages Intent-Based Networking (IBN) to allow users or
   administrators to declare high-level security intents, which are
   translated into enforceable network and application policies.
   Network-level policies are delivered to 5G core components via the
   Network Exposure Function (NEF), while application-level policies are
   enforced directly on a User Equipment (UE) through distributed IBN
   Controllers.  This architecture supports adaptive, context-aware, and
   distributed policy enforcement, enabling real-time response to
   dynamic edge conditions and user mobility scenarios such as
   handovers.  By integrating closed-loop monitoring and analytics, the
   system ensures consistent and autonomous security across
   heterogeneous 5G environments.

full_text:
Internet Research Task Force                                 Y. Ahn, Ed.
Internet-Draft                                             J. Jeong, Ed.
Intended status: Informational                   Sungkyunkwan University
Expires: 29 August 2026                                           Y. Kim
                                                     Soongsil University
                                                        25 February 2026


  An Integrated Security Service System for 5G Networks using an I2NSF
                               Framework
             draft-ahn-nmrg-5g-security-i2nsf-framework-01

Abstract

   This document presents an integrated framework for automated security
   management in 5G edge networks using the Interface to Network
   Security Functions (I2NSF) architecture.  The proposed system
   leverages Intent-Based Networking (IBN) to allow users or
   administrators to declare high-level security intents, which are
   translated into enforceable network and application policies.
   Network-level policies are delivered to 5G core components via the
   Network Exposure Function (NEF), while application-level policies are
   enforced directly on a User Equipment (UE) through distributed IBN
   Controllers.  This architecture supports adaptive, context-aware, and
   distributed policy enforcement, enabling real-time response to
   dynamic edge conditions and user mobility scenarios such as
   handovers.  By integrating closed-loop monitoring and analytics, the
   system ensures consistent and autonomous security across
   heterogeneous 5G environments.

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 29 August 2026.





Ahn, et al.              Expires 29 August 2026                 [Page 1]

Internet-Draft  An 5G Integrated Security Service System   February 2026


Copyright Notice

   Copyright (c) 2026 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  An I2NSF-Based Architecture for 5G Edge Security
           Management  . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  The Procedure for I2NSF-Based 5G Edge Security Management . .   7
   5.  Security Considerations Sections  . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Network softwarization has become a fundamental approach for
   delivering network services across various infrastructures, including
   5G mobile networks [TS-23.501], cloud computing platforms, and edge
   computing environments.  This paradigm is enabled through key
   technologies such as Network Functions Virtualization (NFV)
   [ETSI-NFV] and Software-Defined Networking (SDN) [RFC7149].  In
   addition, Intent-Based Networking (IBN) [RFC9315]
   [Survey-IBN-CST-2023] serves as a foundation for implementing
   intelligent behaviors in both network-level and application-level
   services.  As networks continue to evolve in this software-driven
   direction, the emergence of 5G introduces new challenges,
   particularly in the realm of security.

   As mobile networks evolve toward 5G, the increasing complexity of
   network functions and the widespread deployment of edge devices such
   as IoT nodes, user equipment (UE), and application functions (AFs)



Ahn, et al.              Expires 29 August 2026                 [Page 2]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   [TS-23.501] introduce significant challenges to existing security
   models.  These environments are inherently dynamic, heterogeneous,
   and latency-sensitive, making it difficult for traditional rule-based
   configurations, which are typically static and manually managed, to
   respond effectively to changing conditions.  In particular, security
   operations at the edge require more contextual awareness, automation,
   and adaptability than ever before.

   Intent-Based Networking (IBN) provides a promising paradigm to meet
   these requirements.  It enables operators or users to declare high-
   level goals, or intents, which the system can automatically translate
   into enforceable security and network policies [TS-28.312].  These
   policies may range from abstract service-level objectives to fine-
   grained access control rules.  By automating this translation and
   enforcement process, the network gains the ability to respond
   autonomously to operational demands without requiring manual
   intervention.  This model supports closed-loop control, where real-
   time feedback mechanisms continuously refine and adapt system
   behavior based on evolving context and intent.

   This document defines an intent-based framework for edge security
   management in the context of 5G systems.  The framework builds upon
   the service-based architecture (SBA) defined in 3GPP 5G and beyond,
   and introduces a layered approach that includes intent translation,
   policy generation, enforcement, and monitoring.  It integrates
   seamlessly with existing 3GPP network functions such as the Policy
   Control Function (PCF) [TS-29.520], Access and Mobility Management
   Function (AMF), Session Management Function (SMF), and Network Data
   Analytics Function (NWDAF) [TS-23.288].  The aim is to deliver
   scalable and adaptive security control across heterogeneous edge
   domains through policy-driven orchestration.

   Furthermore, the framework is designed to support mobility scenarios,
   including handovers between gNBs and session migration across
   multiple User Plane Functions (UPFs).  By dynamically enforcing
   intents on the edge, the system maintains consistent and context-
   aware security postures even in the presence of mobility events.
   This capability improves network resilience and responsiveness and
   provides a foundation for secure, automated, and intelligent 5G
   services.  The proposed framework also aligns with long-term goals of
   zero-touch security, AI-driven orchestration, and intent-based policy
   automation within future mobile network infrastructures.









Ahn, et al.              Expires 29 August 2026                 [Page 3]

Internet-Draft  An 5G Integrated Security Service System   February 2026


2.  Terminology

   This section provides definitions of the key terms and concepts used
   throughout this document.  The terminology is intended to establish a
   common understanding of the architectural elements, interfaces, and
   operational principles discussed in the context of intent-based
   security management in 5G networks.  These terms are used to describe
   5G Network automation based on the Intent-Based Networking (IBN) and
   Interface to Network Security Functions (I2NSF) framework.

   *  Intent: It refers to a set of operational objectives and expected
      outcomes that a network is expected to fulfill, expressed in a
      declarative manner without specifying the implementation details
      or the exact procedures to achieve them [RFC9315].  Intents can be
      represented using XML [RFC6020] [RFC7950] or YAML [YAML] formats,
      and may be delivered to the target components through protocols
      such as NETCONF [RFC6241], RESTCONF [RFC8040], or via standard
      REST APIs [REST].

   *  IBN User Function (IUF): The IUF is typically accessed via a web-
      browser interface, which allows Mobile Object administrators to
      input network intents for the IBN Control Function (ICF).  These
      intents serve as strategic objectives that guide the generation of
      security and network policies within the system.

   *  IBN Control Function (ICF): The ICF operates as a core component
      of the I2NSF architecture deployed within the 5G network.  It is
      responsible for managing and orchestrating security enforcement
      functions by both translating the intents from the IUF into
      actionable policies, and selecting appropriate 5G Network
      Functions (NFs) for their execution.

   *  Developer's Management Function (DMF): The DMF is a component
      within the Interface to Network Security Functions (I2NSF)
      framework that acts as a provider of Network Security Functions
      (NSFs).  It is responsible for registering the capabilities of
      these NSFs with the Security Controller, essentially making them
      available for use in enforcing security policies.

   *  Security Control Function (SCF): The SCF strengthens network
      security by generating low-level policies to modify and supplement
      the network configuration based on the delivered network policy
      and delivering them to the relevant individual NFs.








Ahn, et al.              Expires 29 August 2026                 [Page 4]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   *  Security Data Analytics Function (SDAF): THE SDAF collects and
      analyzes monitoring data to verify whether the policies generated
      based on intents have been properly enforced by the network
      security functions, and to evaluate the performance and
      functionality of the security services.

   *  Network Security Function (NSF): The NSF is a network security
      function that provides actual security services based on policies
      generated based on the user's intent.  It actually executes
      security tasks such as blocking or allowing traffic based on the
      policy delivered from ICF.

3.  An I2NSF-Based Architecture for 5G Edge Security Management

   This section defines a comprehensive framework for 5G security
   management automation by introducing its essential components and
   explaining how each of them is designed to interconnect with
   functions in the 5G core networks [TS-23.501].  The framework is
   grounded in intent-based networking principles, which enable high-
   level user or application intents to be automatically translated into
   actionable policies.  These policies are then enforced and monitored
   across both the core and edge domains without requiring manual
   intervention.

   As 5G networks become more distributed and support a growing number
   of latency-sensitive services and heterogeneous devices, traditional
   static security mechanisms struggle to cope with the dynamic nature
   of threats and the scale of real-time traffic.  Manual configuration
   is no longer feasible in such environments, making automated security
   orchestration essential to maintain consistent protection, reduce
   response time, and minimize human error.

   To realize this, the framework leverages a set of I2NSF-based
   functional modules that collectively support policy translation,
   enforcement, and real-time monitoring.  By integrating these
   components into the 5G architecture, the system enables scalable,
   adaptive, and context-aware security operations tailored to the needs
   of dynamic and heterogeneous edge environments.













Ahn, et al.              Expires 29 August 2026                 [Page 5]

Internet-Draft  An 5G Integrated Security Service System   February 2026


  +------------------------------------+ +-----------------------------+
  | 5G Core NFs                        | |                             |
  | +-----+  +-----+  +-----+  +-----+ | | +-----+  +-----+  +------+  |
  | |NSSF |  | UDM |  | NRF |  | PCF | | | | IUF |  | ICF |  | SDAF |  |
  | +---+-+  +---+-+  +---+-+  +---+-+ | | +--+--+  +--+--+  +--+---+  |
  |     |        |        |        |   | |    |        |        |      |
  | --+-+------+-+------+-+---+--+-+---+-+----+---+----+----+---+----- |
  |   |        |        |        |     | |        |         |          |
  | +-+---+  +-+---+  +-+---+  +-+---+ | |     +-----+   +-----+       |
  | | AUSF|  | AMF |  | SMF |  | NEF | | |     | DMF |   | SCF |       |
  | +-----+  +-+-+-+  +--+--+  +-----+ | |     +-----+   +-----+       |
  |            | |       |             | |                             |
  |      +-----+ +--+    +------+      | |  AFs for Security Services  |
  +------+----------+-----------+------+ +-----------------------------+
         |          |           |
      +--+--+   +---+---+    +--+---+   +--+---+   +--------------+
      | UE  +---+ (R)AN +----+ UPFs +---+ NSFs +---+ Data Network |
      +-----+   +-------+    +--+---+   +------+   +--------------+

     Figure 1: I2NSF-Based Security Management Framework for 5G Edge
                                 Networks

   Figure 1 illustrates a 5G edge security service architecture based on
   the I2NSF framework [RFC8329], implemented as an Intent-Based System
   (IBS).  An intent-based management strategy is required between the
   5G Core network and distributed edge domains to enable the autonomous
   configuration and security enforcement of edge functions such as User
   Equipment (UEs), as described in the IETF draft on intent-based
   network management automation.

   On the right side of the architecture, the AFs for Security Services
   represent application-layer functions that initiate and manage high-
   level security intents.  These functions serve as the interface
   between external users or applications and the intent-based security
   system.  This service is composed of several key modules, including
   the Intent-Based Use Function (IUF), the Intent Control Function
   (ICF), the Security Control Function (SCF), the Developer's
   Management Function (DMF), and the Security Data Analytics Function
   (SDAF), which collectively support intent interpretation, policy
   translation, enforcement, and monitoring across the network.

   The security intent generated by the Intent-Based Network Use
   Function (IUF) is first interpreted as a high-level objective
   reflecting the desired behavior of the network or specific
   applications.  This intent is then processed by the Intent-Based
   Network Control Function (ICF), which plays a central role in
   translating the abstract intent into concrete policies.  Through this
   translation process, two distinct types of policies are created: a



Ahn, et al.              Expires 29 August 2026                 [Page 6]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   network policy, which governs how the underlying network should
   behave (e.g., traffic routing, filtering, or QoS enforcement), and an
   application policy, which defines how specific applications or
   devices should operate under given security constraints.

   Once these policies are generated, they are delivered to the 5G Core
   Network via the Network Exposure Function (NEF).  The NEF serves as
   the gateway between external application functions and the internal
   control plane of the 5G Core.  To support flexible deployment and
   orchestration, these components can be implemented as containerized
   microservices and managed using Kubernetes[Kubernetes].  By passing
   the policies through the NEF, the system enables relevant 5G Core
   components such as the Policy Control Function (PCF), Session
   Management Function (SMF), and Access and Mobility Management
   Function (AMF) to enforce the translated policies in real time.  This
   ensures that the original user or service intent is consistently and
   dynamically applied throughout the network.

4.  The Procedure for I2NSF-Based 5G Edge Security Management

   This testbed demonstrates a use case where high-level user intents
   are automatically translated into enforceable network and application
   policies.  Leveraging the I2NSF (Interface to Network Security
   Functions) framework [RFC8329] and deployed on the free5GC platform,
   this architecture enables automated, intent-driven security
   management that reduces the reliance on manual configuration and
   static rule sets.

   The system is designed to support distributed policy enforcement by
   integrating key I2NSF components such as the Intent-Based Networking
   Use Function (IUF), Intent Control Function (ICF), Security Control
   Function (SCF), and Security Data Analytics Function (SDAF).  These
   components work collaboratively to process intents, generate
   appropriate policies, and enforce them dynamically across both the
   core network and the edge.


                 +--------------+
                 |User Equipment|
                 +--------------+
                        ^  Appplication Policy
                        |    (Configuration)
                        |          +-------------------+
+-----+             +--------+     |    IBN Control    |         +----------+
| NEF |<------------+ Router |<----+      Function     |<--------+ IBN Use  |
+-----+   Network   +--------+     |(Intent Translator)|  Intent | Function |
5G Core   Policy                   +-------------------+         +----------+
Network (Firewall& WebFilter)



Ahn, et al.              Expires 29 August 2026                 [Page 7]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   Figure 2: The Procedure of Policy Generation and Delivery for 5G
                             Edge Network

   Figure 2 shows the procedure for 5G Edge Security Management
   Automation, specifically illustrating the creation of user intents
   and the generation of corresponding network policies and application
   policies.  The process begins when a user or administrator expresses
   a security-related intent via the IBN Use Function (IUF).  This
   intent, representing a high-level goal such as restricting access to
   certain websites or monitoring device behavior, is passed to the IBN
   Control Function (ICF).  The ICF, equipped with an Intent Translator,
   converts this intent into both network-level and application-level
   policies.  The translated network-level policies are forwarded
   through the router to the 5G Core's Network Exposure Function (NEF)
   [TS-29.503], while the application-level policies are delivered
   directly to the User Equipment (UE).  This enables consistent policy
   enforcement from the core network to the device edge.


           User Equipment 1 (SmartPhone)  User Equipment 2 (IoT Device)
              +---------------------+        +---------------------+
              | +-----------------+ |        | +-----------------+ |
              | |Service Functions| |        | |Service Functions| |
              | |      (SFs)      | |        | |      (SFs)      | |
              | +-----------------+ |        | +-----------------+ |
              |          ^ |        |        |          ^ |        |
              |Monitoring| |  API   |        |Monitoring| |  API   |
              |   Data   | |Command |        |   Data   | |Command |
              |          | V        |        |          | V        |
              |   +--------------+  |        |   +--------------+  |
              |   |IBN Controller|  |        |   |IBN Controller|  |
              |   +--------------+  |        |   +--------------+  |
              |          ^  |       |        |        ^       |    |
              +----------+--+-------+        +--------+-------+----+
                         |  |                         |       |
                         |  +---------------------------------+
                         |                            |       |
                         +--------------+-----+-------+----+  +
                   Application Policy   |     |            |  |
                    (Configuration)     |     |            |  |
                                        |     |            |  |
            +---------------------------+-----+-----+      |  |
            |                           |     |     |      |  |
+--------+  |   +------+   +-----+   +--+--+  |     |      |  |
|  Data  +--|---+ NSFs +---+ UPF +---+ gNB |  |     |      |  |
| Network|  |   +------+   +--+--+   +--+--+  |     |      |  |
+--------+  |                 |         |     |     |      |  |
            |              +--+--+   +--+--+  |     |      |  |



Ahn, et al.              Expires 29 August 2026                 [Page 8]

Internet-Draft  An 5G Integrated Security Service System   February 2026


            |              | SMF |   | AMF +--+     |      |  |
            |              +--+--+   +--+--+        |      |  |
            |                 |         |           |    +-+--+---+
            |  ------------+--+-----+---+----+---   |    | Router +---+
            |              |        |        |      |    +---+----+   |
            |           +--+--+  +--+--+  +--+--+   |        |        |
            |           | DMF |  | SCF |  | NEF |<--+--------+        |
            |           +--+--+  +--+--+  +--+--+   | Network         |
            |                                       | Policy          |
            |                                       | (Firewall       |
            +---------------------------------------+ & Web Filter)   |
                          5G Core Network                             |
                                                           Monitoring |
                                                             Report   |
                                                                      V
                                                        +-------------------+
                                                        |   Security Data   |
                                                        | Analytics Function|
                                                        +---------+---------+
                                                                  |
                                                  +---------------+---------+
                                                  | Monitoring Data Storage |
                                                  +-------------------------+

    Figure 3: The Procedure within an I2NSF-Based Framework for 5G
                       Edge Security Management

   Figure 3 illustrates the procedure of how the intent-driven network
   policies and application policies are applied across both the 5G core
   network and user equipment.  These policies are then propagated
   throughout the 5G network to support coordinated and consistent
   security enforcement.  Network-level policies are distributed to core
   network functions [TS-23.501], where they help guide the overall
   behavior and resource allocation of the system in alignment with the
   user's intent.  At the same time, application-level policies are
   delivered to various user devices, such as smartphones and IoT nodes,
   which have embedded controllers capable of interpreting and enforcing
   the received policies locally.

   This allows each device to autonomously adjust its behavior according
   to the defined security or operational requirements.  In parallel,
   network-based security functions are also engaged to apply the
   necessary controls, such as access restrictions or traffic filtering,
   ensuring that both the core and the edge of the network operate
   securely and in harmony with the original intent.  This distributed
   approach enables flexible, scalable, and adaptive policy enforcement
   across the entire mobile network environment [TS-23.288].




Ahn, et al.              Expires 29 August 2026                 [Page 9]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   To support adaptive security validation, each user equipment's IBN
   Controller periodically generates monitoring reports based on local
   policy enforcement status.  These reports are sent to the Security
   Data Analytics Function (SDAF), which analyzes the monitoring data to
   evaluate whether the applied policies are effectively enforced.  All
   collected data is stored in a centralized Monitoring Data Storage
   module, enabling real-time policy validation and historical auditing.
   The related steps are as follows:

   *  Steps 1-2: An intent is sent from an application within the 5G
      Core to the IBN Control Function (ICF), where it is translated
      into network and application policies.  This marks the beginning
      of intent-driven automation for security management.

   *  Step 3: The network policy is delivered via the NEF to relevant 5G
      Core functions and connected security components.  These
      components then prepare for the enforcement of the policy.

   *  Step 4: The application policy is sent to the IBN Controllers on
      target user devices.  This allows the devices to receive
      instructions without direct user intervention.

   *  Step 5: Each device applies the policy to adjust its settings and
      behavior.  The changes take effect locally to reflect the system-
      wide intent.

   *  Step 6: Devices monitor their own status and send relevant data
      back to their IBN Controllers.  This ensures continuous awareness
      of policy impact at the device level.

   *  Step 7: The IBN Controllers compile and forward the data as
      monitoring reports.  These reports provide a basis for evaluating
      the effectiveness of the applied policies.

   *  Step 8: The reports are analyzed to check if the policies are
      working as intended, and the results are stored for future use.
      This completes the feedback loop that enables adaptive policy
      refinement.













Ahn, et al.              Expires 29 August 2026                [Page 10]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   Through this process, the system enables intent-driven security
   management that spans from core network functions to individual user
   devices.  By translating high-level intents into enforceable policies
   and continuously monitoring their effects, the architecture supports
   real-time adaptation to network conditions and user behaviors.  This
   ensures that security enforcement remains consistent, context-aware,
   and autonomous throughout distributed edge environments.  Moreover,
   the closed-loop structure provides a foundation for scalable and
   self-optimizing policy management, which is essential for future 5G
   edge-native networks.

   Also, the proposed system extends the core components such as the
   Intent-Based Networking Use Function (IUF), Intent Control Function
   (ICF), and distributed enforcement modules to operate in tandem with
   the handover procedures defined in 3GPP specifications.  This helps
   keep security consistent and smart across the edge network where
   quick response and local control are especially important.  This
   approach can also be applied to mobility scenarios where intent-
   driven security policies need to dynamically migrate and be re-
   enforced as User Equipment (UE) transitions between gNBs.

5.  Security Considerations Sections

   In the context of intent-based edge security management in 5G
   networks, several important security aspects must be considered to
   ensure robust and trustworthy system behavior.  One key concern
   involves the potential for malicious manipulation of user intents.
   Since intents are high-level expressions of user goals that drive the
   automated generation of network and application policies, any
   unauthorized alteration could lead to unintended or insecure
   outcomes.  Ensuring that each intent originates from a trusted source
   and is protected by integrity validation mechanisms is therefore
   essential.

   Another important consideration is the accuracy and reliability of
   the policy translation and enforcement process.  When translating
   abstract intents into concrete policies, the system must preserve the
   user's original intent without introducing misconfigurations or
   inconsistencies.  Incorporating validation checks and feedback
   mechanisms helps to ensure that policies are correctly interpreted
   and consistently applied across the network.  To further enhance this
   process, deep learning techniques [Deep-Learning] can be employed to
   detect anomalies, learn from past policy enforcement outcomes, and
   adaptively improve the translation logic based on contextual patterns
   and historical data.






Ahn, et al.              Expires 29 August 2026                [Page 11]

Internet-Draft  An 5G Integrated Security Service System   February 2026


6.  IANA Considerations

   This document does not require any IANA actions.

7.  References

7.1.  Normative References

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
              <https://www.rfc-editor.org/info/rfc7149>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
              <https://www.rfc-editor.org/info/rfc8329>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/info/rfc9315>.

7.2.  Informative References

   [YAML]     Ingerson, B., Evans, C., and O. Ben-Kiki, "Yet Another
              Markup Language (YAML) 1.0",
              Available: https://yaml.org/spec/history/2001-05-26.html,
              October 2023.




Ahn, et al.              Expires 29 August 2026                [Page 12]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   [TS-23.501]
              "System Architecture for the 5G System (5GS)", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3144, September
              2023.

   [TS-28.312]
              "Intent Driven Management Services for Mobile Networks",
              Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3554, September
              2023.

   [TS-23.288]
              "Architecture Enhancements for 5G System (5GS) to Support
              Network Data Analytics Services", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3579, September
              2023.

   [TS-29.503]
              "Service-Based Interface Specifications for the Network
              Exposure Function (NEF)", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3342, September
              2023.

   [TS-29.520]
              "Network Data Analytics Services", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3355, September
              2023.

   [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural
              Framework", Available:
              https://www.etsi.org/deliver/etsi_gs/
              nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf,
              December 2014.

   [REST]     Fielding, R. and R. Taylor, "Principled Design of the
              Modern Web Architecture", ACM Transactions on Internet
              Technology, Vol. 2, Issue 2,,
              Available: https://dl.acm.org/doi/10.1145/514183.514185,
              May 2002.







Ahn, et al.              Expires 29 August 2026                [Page 13]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   [Deep-Learning]
              Goodfellow, I., Bengio, Y., and A. Courville, "Deep
              Learning", Publisher: The MIT Press,
              Available: https://www.deeplearningbook.org/, November
              2016.

   [Kubernetes]
              "Kubernetes: Cloud Native Computing Platform",
              Available: https://kubernetes.io/, March 2024.

   [Survey-IBN-CST-2023]
              Leivadeas, A. and M. Falkner, "A Survey on Intent-Based
              Networking",
              Available: https://ieeexplore.ieee.org/document/9925251,
              March 2023.

   [ClickINC-Sigcomm-2023]
              Xu, W., Zhang, Z., Feng, Y., Song, H., Chen, Z., Wu, W.,
              Liu, G., Zhang, Y., Liu, S., Tian, Z., and B. Liu,
              "ClickINC: In-network Computing as a Service in
              Heterogeneous Programmable Data-center Networks",
              Publisher: ACM SIGCOMM,
              Available: https://dl.acm.org/doi/10.1145/3603269.3604835,
              September 2023.

Acknowledgments

   This work was supported by Institute of Information & Communications
   Technology Planning & Evaluation (IITP) grant funded by the Korea
   Ministry of Science and ICT (MSIT) (No.  RS-2024-00398199 and RS-
   2022-II221015).

   This work was supported in part by Institute of Information &
   Communications Technology Planning & Evaluation (IITP) grant funded
   by the Korea Ministry of Science and ICT (MSIT) (No.  IITP-2025-RS-
   2022-II221199, Regional strategic industry convergence security core
   talent training business).

Contributors

   This document is made by the group effort of NMRG, greatly benefiting
   from inputs and texts by Linda Dunbar (Futurewei), Yong-Geun Hong
   (Daejeon University), and Joo-Sang Youn (Dong-Eui University).  The
   authors sincerely appreciate their contributions.

   The following is the coauthor of this document:





Ahn, et al.              Expires 29 August 2026                [Page 14]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   Mose Gu
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: rna0415@skku.edu
   URI:   http://iotlab.skku.edu/people-Moses-Gu.php


Authors' Addresses

   Yoseop Ahn (editor)
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: ahnjs124@skku.edu
   URI:   http://iotlab.skku.edu/people-Ahn-Yoseop.php


   Jaehoon Paul Jeong (editor)
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4957
   Email: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


   Younghan Kim
   School of Electronic Engineering
   Soongsil University
   369, Sangdo-ro, Dongjak-gu
   Seoul
   06978
   Republic of Korea



Ahn, et al.              Expires 29 August 2026                [Page 15]

Internet-Draft  An 5G Integrated Security Service System   February 2026


   Email: younghak@ssu.ac.kr


















































Ahn, et al.              Expires 29 August 2026                [Page 16]


name: draft-ietf-netconf-configuration-tracing
rev: 06
title: External Trace ID for Configuration Tracing
time: 2025-11-03T09:57:35Z
group_uri: /api/v1/group/group/1575/
expires: 2026-05-07T09:57:35Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/41/"]
categories: ["Autonomous netops", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:10.243451+00:00
abstract:
Network equipment are often configured by a variety of network
   management systems (NMS), protocols, and teams.  If a network issue
   arises (e.g., because of a wrong configuration change), it is
   important to quickly identify the root cause and obtain the reason
   for pushing that modification.  Another potential network issue can
   stem from concurrent NMSes with overlapping intents, each having
   their own tasks to perform.  In such a case, it is important to map
   the respective modifications to its originating NMS.

   This document specifies a NETCONF mechanism to automatically map the
   configuration modifications to their source, up to a specific NMS
   change request.  Such a mechanism is required, in particular, for
   autonomous networks to trace the source of a particular configuration
   change that led to an anomaly detection.  This mechanism facilitates
   the troubleshooting, the post-mortem analysis, and in the end the
   closed loop automation required for self-healing networks.  The
   specification also includes a YANG module that is meant to map a
   local configuration change to the corresponding trace id, up to the
   controller or even the orchestrator.

full_text:
OPSAWG                                                       J. Quilbeuf
Internet-Draft                                                    Huawei
Intended status: Standards Track                               B. Claise
Expires: 7 May 2026                                       Everything OPS
                                                                 T. Graf
                                                                Swisscom
                                                                D. Lopez
                                                          Telefonica I+D
                                                                  Q. Sun
                                                           China Telecom
                                                         3 November 2025


              External Trace ID for Configuration Tracing
              draft-ietf-netconf-configuration-tracing-06

Abstract

   Network equipment are often configured by a variety of network
   management systems (NMS), protocols, and teams.  If a network issue
   arises (e.g., because of a wrong configuration change), it is
   important to quickly identify the root cause and obtain the reason
   for pushing that modification.  Another potential network issue can
   stem from concurrent NMSes with overlapping intents, each having
   their own tasks to perform.  In such a case, it is important to map
   the respective modifications to its originating NMS.

   This document specifies a NETCONF mechanism to automatically map the
   configuration modifications to their source, up to a specific NMS
   change request.  Such a mechanism is required, in particular, for
   autonomous networks to trace the source of a particular configuration
   change that led to an anomaly detection.  This mechanism facilitates
   the troubleshooting, the post-mortem analysis, and in the end the
   closed loop automation required for self-healing networks.  The
   specification also includes a YANG module that is meant to map a
   local configuration change to the corresponding trace id, up to the
   controller or even the orchestrator.

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/netconf-wg/configuration-tracing.







Quilbeuf, et al.           Expires 7 May 2026                   [Page 1]

Internet-Draft     Configuration Tracing via trace-id      November 2025


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 7 May 2026.

Copyright Notice

   Copyright (c) 2025 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Configuration Mistakes  . . . . . . . . . . . . . . . . .   5
     3.2.  Concurrent NMS Configuration  . . . . . . . . . . . . . .   5
     3.3.  Conflicting Intents . . . . . . . . . . . . . . . . . . .   5
     3.4.  Not a use case: Onboarding  . . . . . . . . . . . . . . .   5
   4.  Relying on W3C Trace Context to Trace Configuration
           Modifications . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Existing configuration metadata on device . . . . . . . .   6
     4.2.  Client ID . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Instantiating the YANG module . . . . . . . . . . . . . .   6
     4.4.  Using the YANG module . . . . . . . . . . . . . . . . . .   7
   5.  YANG module . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   9



Quilbeuf, et al.           Expires 7 May 2026                   [Page 2]

Internet-Draft     Configuration Tracing via trace-id      November 2025


     5.2.  YANG module ietf-external-transaction-id  . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  Open Issues / TODO  . . . . . . . . . . . . . . . . . . . . .  14
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  15
   11. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  Changes between revisions  . . . . . . . . . . . . .  17
   Appendix B.  Example of NETCONF message . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Issues arising in the network, for instance violation of some SLAs,
   might be due to some configuration modification.  In the context of
   automated networks, the assurance system needs not only to identify
   and revert the problematic configuration modification, but also to
   make sure that it won't happen again and that the fix will not
   disrupt other services.  To cover the last two points, it is
   imperative to understand the cause of the problematic configuration
   change.  Indeed, the first point, making sure that the configuration
   modification will not be repeated, cannot be ensured if the cause for
   pushing the modification in the first place is not known.  Ensuring
   the second point, not disrupting other services, requires as well
   knowing if the configuration modification was pushed in order to
   support new services.  Therefore, we need to be able to trace a
   configuration modification on a device back to the reason that
   triggered that modification, for instance in a NMS, whether the
   controller or the orchestrator.

   This specification focuses only on configuration pushed via NETCONF
   [RFC6241] or RESTCONF [RFC8040].  The rationale for this choice is
   that NETCONF is better suited for normalization than other protocols
   (SNMP, CLI).  Another reason is that the notion of trace context,
   useful to track configuration modifications, has been ported to
   NETCONF in [I-D.ietf-netconf-trace-ctx-extension] and RESTCONF in
   [I-D.ietf-netconf-restconf-trace-ctx-headers].

   The same network element, or NETCONF [RFC6241] server, can be
   configured by different NMSs or NETCONF clients.  If an issue arises,
   one of the starting points for investigation is the configuration
   modification on the devices supporting the impacted service.  In the
   best case, there is a dedicated user for each client and the
   timestamp of the modification allows tracing the problematic
   modification to its cause.  In the worst case, everything is done by
   the same user and some more correlations must be done to trace the
   problematic modification to its source.



Quilbeuf, et al.           Expires 7 May 2026                   [Page 3]

Internet-Draft     Configuration Tracing via trace-id      November 2025


   This document specifies a mechanism to automatically map the
   configuration modifications to their source, up to a specific NMS
   service request.  Practically, this mechanism annotates configuration
   changes on the configured element with sufficient information to
   unambiguously identify the corresponding transaction, if any, on the
   element that requested the configuration modification.  It reuses the
   concept of Trace Context [W3C-Trace-Context] applied to NETCONF as in
   [I-D.ietf-netconf-trace-ctx-extension] The information needed to
   trace the configuration is stored in a new YANG module that maps a
   local configuration change to some additional metadata.  The
   additional metadata contains the trace ID, and, if the local change
   is not the beginning of the trace, the ID of the client that
   triggered the local-change.  In that sense, it is an instance of the
   YANG DataStore implementation of the Trace Context as proposed in
   Section 1.2 of [I-D.ietf-netconf-trace-ctx-extension].

2.  Terminology

   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 client and server from [RFC6241].

   This document uses the terms transaction and Transaction ID from
   [I-D.ietf-netconf-transaction-id].

   This document uses the term trace ID from [W3C-Trace-Context].

   Local Commit ID  Identifier of a local configuration change on a
      Network Equipment, Controller, Orchestrator or any other device or
      software handling configuration.  Such an identifier is usually
      present in devices that can show a history of the configuration
      changes, to identify one such configuration change.

3.  Use cases

   This document was written with autonomous networks in mind.  We
   assume that an existing monitoring or assurance system, such as
   described in [RFC9417], is able to detect and report network
   anomalies , e.g. SLA violations, intent violations, network failure,
   or simply a customer issue.  Here are the use cases for the proposed
   YANG module; they are extensions of the "Provisioning root cause
   analysis" use case presented in Section 1.3.1 of
   [I-D.ietf-netconf-trace-ctx-extension].




Quilbeuf, et al.           Expires 7 May 2026                   [Page 4]

Internet-Draft     Configuration Tracing via trace-id      November 2025


3.1.  Configuration Mistakes

   Taking into account that many network anomalies are due to
   configuration mistakes, this mechanism allows to find out whether the
   offending configuration modification was triggered by a tracing-
   enabled client/NMS.  In such a case, we can map the offending
   configuration modification id on a server/NE to a local configuration
   modification id on the client/NMS.  Assuming that this mechanism (the
   YANG module) is implemented on the controller, we can recursively
   find, in the orchestrator, the latest (set of of) service request(s)
   that triggered the configuration modification.  Whether this/those
   service request(s) are actually the root cause needs to be
   investigated.  However, they are a good starting point for
   troubleshooting, post-mortem analysis, and in the end the closed loop
   automation, which is absolutely required for self-healing networks.

3.2.  Concurrent NMS Configuration

   Building on the previous use case is the situation where two NMS's,
   unaware of each other, are configuring a common router, each
   believing that they are the only NMS for the common router.  So one
   configuration executed by the NMS1 is overwritten by the NMS2, which
   in turn is overwritten by NMS1, etc.

3.3.  Conflicting Intents

   Autonomous networks will be solved first by assuring intent per
   specific domain; for example data center, core, cloud, etc.  This
   last use case is a more specific "Concurrent NMS configuration" use
   case where assuring domain intent breaks the entire end to end
   service, even if the domain-specific controllers are aware of each
   other.

3.4.  Not a use case: Onboarding

   During onboarding, a newly added device is likely to receive a
   multiple configuration message, as it needs to be fully configured.
   Our use cases focus more on what happens after the initial
   configuration is done, i.e. when the "stable" configuration is
   modified.

4.  Relying on W3C Trace Context to Trace Configuration Modifications









Quilbeuf, et al.           Expires 7 May 2026                   [Page 5]

Internet-Draft     Configuration Tracing via trace-id      November 2025


4.1.  Existing configuration metadata on device

   This document assumes that NETCONF clients or servers (orchestrators,
   controllers, devices, ...) have some kind of mechanism to record the
   modifications done to the configuration.  For instance, devices
   typically have a history of configuration changes and this history
   associates a locally unique identifier to some metadata, such as the
   timestamp of the modification, the user doing the modification or the
   protocol used for the modification.  Such a locally unique identifier
   is a Local Commit ID, we assume that it exists on the platform.  This
   Local Commit ID is the link between the module presented in this
   draft and the device-specific way of storing configuration changes.

4.2.  Client ID

   This document assumes that each NETCONF client for which
   configuration must be traced (for instance orchestrator and
   controllers) has a unique client ID among the other NETCONF clients
   in the network.  Such an ID could be an IP address or a host name.
   The mechanism for providing and defining this client ID is out of
   scope of the current document.

4.3.  Instantiating the YANG module

   [I-D.ietf-netconf-trace-ctx-extension] defines a NETCONF extension
   providing the trace context from [W3C-Trace-Context].  Using this
   mechanism, the NETCONF server captures the trace-id, when available,
   and maps it to a local commit ID, by populating the YANG module.

   The trace context from W3C provides a parent-id.  This parent-id does
   not identify a particular server or NMS but rather one request in the
   chain of HTTP requests constituting the trace.  Similarly to the
   passing of the trace context in
   [I-D.ietf-netconf-trace-ctx-extension], we propose an XML attribute
   on NETCONF messages to pass the client-id.  The attribute name is
   "client-id" and the namespace is the namespace of the YANG module
   from Section 5, namely 'urn:ietf:params:xml:ns:yang:ietf-external-
   transaction-id'.  An example of a commit message including the
   client-id is shown in Figure 4.












Quilbeuf, et al.           Expires 7 May 2026                   [Page 6]

Internet-Draft     Configuration Tracing via trace-id      November 2025


                            +---------------+
                            | Orchestrator  |
                            +---------------+
                                   | tr-1, tx-1
                                   v
                            +---------------+
                            |   Controller  |
                            +---------------+
                   tr-1, tx-2 |           | tr-1, tx-3
                              v           v
                           +-----+     +-----+
                           | NE1 |     | NE2 |
                           +-----+     +-----+


     Figure 1: Example of Hierarchical Configuration. tx: transaction.
                                 tr: trace.

   In Figure 1, the transactions 'tx-1', 'tx-2' and 'tx-3' are sent via
   NETCONF.  The NETCONF RPC used, most likely 'commit' in our use case,
   is annotated with the 'traceparent' annotation as defined in
   [I-D.ietf-netconf-trace-ctx-extension].  The traceparent annotation
   has the same trace id 'tr-1' for each of these transactions.
   Additionally, for each transaction the client id is passed via the
   'client-id' annotation.  For 'tx-1' the client-id is the id of the
   Orchestrator.  For 'tx-2' and 'tx-3', the client is the id of the
   Controller.

   It is technically possible that several clients push configuration to
   the candidate configuration datastore and only one of them commits
   the changes to the running configuration datastore.  From the running
   configuration datastore perspective, which is the effective one,
   there is a single modification, but caused by several clients, which
   means that this modification should have several corresponding
   client-ids.  Although, this case is technically possible, it is a bad
   practice.  We won't cover it in this document.  In other terms, we
   assume that a given configuration modification on a server is caused
   by a single client, and thus has a single corresponding client-id.

4.4.  Using the YANG module

   The YANG module defined below enables tracing a configuration change
   in a Network Equipment back to its origin, for instance a service
   request in an orchestrator.  To do so, the Anomaly Detection System
   (ADS) should have, for each client-id, access to some credentials
   enabling read access to the YANG module for configuration tracing on
   that client.  It should as well have access to the network equipment
   in which an issue is detected.



Quilbeuf, et al.           Expires 7 May 2026                   [Page 7]

Internet-Draft     Configuration Tracing via trace-id      November 2025


                                                     +---------------+
        .----------------[5]match tr-1-------------->|               |
        |                                            | Orchestrator  |
        | ----------------[6]commit-id---------------|               |
        | |                                          +---------------+
        | |                                                | tx-1
        | |                                                v
        | |                                          +---------------+
        | |   .-----------[3] match tr-1------------>|               |
        | |   |                                      |   Controller  |
        | |   | .-----------[4] c-id O tr-1----------|               |
        | |   | |                                    +---------------+
        | |   | |                                          | tx-2
        | v   | v                                          v
      +-----------+                                      +----+
      | Anomaly   |--[1] match commit-id before time t-->|    |
      | Detection |                                      | NE |
      | System    |<--------- [2] c-id C tr-1------------|    |
      +----------+                                       +----+


        Figure 2: Example of Configuration Tracing. tr: trace-id, C:
      Controller, O: orchestrator.  The number between square brackets
                    refer to steps in the listing below.

   The steps for a software to trace a configuration modification in a
   Network Equipment back to a service request are illustrated in
   Figure 2.  They are detailed below.

   1.  The Anomaly Detection System (ADS) identifies the commit-id that
       created an issue, for instance by looking for the last commit-id
       occurring before the issue was detected.  The ADS queries the NE
       for the trace id and client id associated to the commit-id.

   2.  The ADS receives the trace-id and the client-id.  In Figure 2,
       that step would receive the trace-id tr-1 and the id of the
       Controller as a result.  If there is no associated client-id, the
       change was not done by a client compatible with the present
       draft, and the investigation stops here.

   3.  The ADS queries the client identified by the client-id found at
       the previous step, looking for a match of the trace-id from the
       previous step.  In Figure 2, for that step, the software would
       look for the trace-id tr-1 stored in the Controller.







Quilbeuf, et al.           Expires 7 May 2026                   [Page 8]

Internet-Draft     Configuration Tracing via trace-id      November 2025


   4.  From that query, the ADS knows the local-commit-id on the client
       (Controller in our case).  Since the local-commit-id is
       associated to a client-id pointing to the Orchestrator, the ADS
       continues the investigation.

   5.  The ADS queries the Orchestrator, trying to find a match for the
       trace-id tr-1.

   6.  Finally, the ADS receives the commit-id from the Orchestrator
       that ultimately caused the issue in the NE.  Since there is no
       associated client-id, the investigation stops here.  The
       modification associated to the commit-id, for instance a service
       request, is now available for further manual or automated
       analysis, such as analyzing the root cause of the issue.

   Note that step 5 and 6 are actually a repetition of step 3 and 4.
   The general algorithm is to continue looking for a client until no
   more client-id can be found in the current element.

5.  YANG module

   We present in this section the YANG module for modelling the
   information about the configuration modifications.

5.1.  Overview

   The tree representation [RFC8340] of our YANG module is depicted in
   Figure 3

   module: ietf-external-transaction-id
     +--ro external-transactions-id
        +--ro configuration-change* [local-commit-id]
           +--ro local-commit-id    string
           +--ro timestamp?         yang:date-and-time
           +--ro trace-parent
           |  +--ro version?       hex-digits
           |  +--ro trace-id?      hex-digits
           |  +--ro parent-id?     hex-digits
           |  +--ro trace-flags?   hex-digits
           +--ro client-id?         string


       Figure 3: Tree representation of ietf-external-transaction-id
                                YANG module

   The local-commit-id represents the local id of the configuration
   changes, which is device-specific.  It can be used to retrieve the
   local configuration changes that happened during that transaction.



Quilbeuf, et al.           Expires 7 May 2026                   [Page 9]

Internet-Draft     Configuration Tracing via trace-id      November 2025


   The trace-parent is present to identify the trace associated to the
   local-commit-id.  This trace-parent can be transmitted by a client or
   created by the current server.  In Section 4.4, the most important
   field in trace-parent is the trace-id.  We also included the other
   fields for trace-parent as defined in [W3C-Trace-Context] for the
   sake of completion.  In some cases, for instance direct configuration
   of the device, the device may choose to not include the trace-id.

   The presence of a client-id indicates that the trace-parent has been
   transmitted by that client.  If the trace is initiated by the current
   server, there is no associated client-id.

   Even if this document focuses only on NETCONF or RESTCONF, the use
   cases defined in Section 3 are not specific to NETCONF or RESTCONF
   and the mechanism described in this document could be adapted to
   other configuration mechanisms.  For instance, a configuration
   modification pushed via CLI can be identified via a label, which
   could contain the trace-parent.  As such cases are difficult to
   standardize, we won't cover them in this document.

5.2.  YANG module ietf-external-transaction-id

   <CODE BEGINS> file "ietf-external-transaction-id@2021-11-03.yang"
   module ietf-external-transaction-id {
     yang-version 1.1;
     namespace
       "urn:ietf:params:xml:ns:yang:ietf-external-transaction-id";
     prefix ext-txid;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types, Section 3";
     }

     organization
       "IETF NETCONF Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
        WG List:  <mailto:netconf@ietf.org>
        Author:   Benoit Claise  <mailto:benoit.claise@huawei.com>
        Author:   Jean Quilbeuf  <mailto:jean.quilbeuf@huawei.com>";
     description
       "This module enables tracing of configuration changes in a
        network for the sake of automated correlation between
        configuration changes and the external request that triggered
        that change.




Quilbeuf, et al.           Expires 7 May 2026                  [Page 10]

Internet-Draft     Configuration Tracing via trace-id      November 2025


        The module stores the identifier of the trace, if any, that
        triggered the change in a device. If that trace-id was provided
        by a client, (i.e. not created locally by the server), the id
        of that client is stored as well to indicated which client
        triggered the configuration change.

        Copyright (c) 2025 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Revised BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).
        This version of this YANG module is part of RFC XXXX; see the
        RFC itself for full legal notices.  ";

     revision 2022-10-20 {
       description
         "Initial revision";
       reference
         "RFC xxxx: External Trace ID for Configuration Tracing";
     }

     typedef hex-digits {
       type string {
         pattern '[0-9a-f]*';
       }
       description
         "A string composed of hexadecimal digits. Digits represented by
          letters are restricted to lowercase so that a single
          representation of a given value is allowed. This enables using
          the string equality to check equality of the represented
          values.";
     }

     grouping trace-parent-g {
       description
         "Trace parent frow the W3C trace-context recommandation.
          Follows the format version 00.";
       leaf version {
         type hex-digits {
           length "2";
         }
         must "../version = '00'";
         description
           "Version of the trace context. Must be 00 to match the



Quilbeuf, et al.           Expires 7 May 2026                  [Page 11]

Internet-Draft     Configuration Tracing via trace-id      November 2025


            format described in this module.";
       }
       leaf trace-id {
         type hex-digits {
           length "32";
         }
         must "../trace-id != '00000000000000000000000000000000'";
         description
           "Trace ID that is common for every transaction that is
            part of the configuration chain. This value can be used
            to match a local commit id to a commit local to another
            system.";
       }
       leaf parent-id {
         type hex-digits {
           length "16";
         }
         description
           "ID of the request (client-side) that lead to configuring
            the server hosting this module.";
       }
       leaf trace-flags {
         type hex-digits {
           length "2";
         }
         description
           "Flags enabled for this trace. See W3C reference for the
            details about flags.";
       }
     }

     container external-transactions-id {
       config false;
       description
         "Contains the IDs of configuration transactions that are
          external to the device.";
       list configuration-change {
         key "local-commit-id";
         description
           "List of configuration changes, identified by their
            local-commit-id";
         leaf local-commit-id {
           type string;
           description
             "Stores the identifier as saved by the server. Can be used
              to retrieve the corresponding changes using the server
              mechanism if available.";
         }



Quilbeuf, et al.           Expires 7 May 2026                  [Page 12]

Internet-Draft     Configuration Tracing via trace-id      November 2025


         leaf timestamp {
           type yang:date-and-time;
           description
             "A timestamp that can be used to further filter change
              events.";
         }
         container trace-parent {
           description
             "Trace parent associated to the local-commit-id. If a
              client ID is present as well, the trace context was
              transmitted by that client. If not, the trace context was
              created locally.

              This trace-parent must come from the trace context of the
              request actually modifying the running configuration
              datastore. This request might be an edit-config or a
              commit depending on whether the candidate datastore is
              used.";
           uses trace-parent-g;
         }
         leaf client-id {
           type string;
           description
             "ID of the client that originated the modification, to
              further query information about the corresponding
              change.

              This data node is present only when the configuration was
              pushed by a compatible system.";
         }
       }
     }
   }
   <CODE ENDS>

6.  Security Considerations

   This section is modeled after the template described in Section 3.7
   of [I-D.ietf-netmod-rfc8407bis].

   The "ietf-external-transaction-id" module defines a data model that
   is designed to be accessed via YANG-based management protocols, such
   as NETCONF [RFC6241] and RESTCONF[RFC8040].  These protocols have to
   use a secure transport layer (e.g., SSH [RFC6242], TLS [RFC8446] and
   QUIC [RFC9000]) and have to use mutual authentication.






Quilbeuf, et al.           Expires 7 May 2026                  [Page 13]

Internet-Draft     Configuration Tracing via trace-id      November 2025


   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  Specifically, the following
   subtrees and data nodes have particular sensitivities/
   vulnerabilities:

   *  external-transactions-id/configuration-change exposes information
      about which user or external system can configure the device and
      could help an attacker to send its own configuration to the
      device.  It could also give some information about the
      architecture of the configuration, i.e. what are the controllers
      and the orchestrators.

7.  IANA Considerations

   RFC Ed.: replace XXXX with actual RFC number and remove this note.

   IANA is requested to register the following URI in the "ns"
   subregistry within the "IETF XML Registry" [RFC3688]:

           URI: urn:ietf:params:xml:ns:yang:ietf-external-transaction-id
           Registrant Contact:  The IESG.
           XML: N/A; the requested URI is an XML namespace.

   IANA is requested to register the following YANG module in the "YANG
   Module Names" subregistry [RFC6020] within the "YANG Parameters"
   registry.

        Name: ietf-external-transaction-id
        Maintained by IANA?  N
        Namespace: urn:ietf:params:xml:ns:yang:ietf-external-transaction-id
        Prefix: ext-txid
        Reference: RFC XXXX

8.  Contributors

9.  Open Issues / TODO

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

   None




Quilbeuf, et al.           Expires 7 May 2026                  [Page 14]

Internet-Draft     Configuration Tracing via trace-id      November 2025


10.  Normative References

   [I-D.ietf-netconf-restconf-trace-ctx-headers]
              Gagliano, R., Larsson, K., and J. Lindblad, "RESTCONF
              Extension to Support Trace Context Headers", Work in
              Progress, Internet-Draft, draft-ietf-netconf-restconf-
              trace-ctx-headers-07, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
              restconf-trace-ctx-headers-07>.

   [I-D.ietf-netconf-trace-ctx-extension]
              Gagliano, R., Larsson, K., and J. Lindblad, "NETCONF
              Extension to support Trace Context propagation", Work in
              Progress, Internet-Draft, draft-ietf-netconf-trace-ctx-
              extension-05, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
              trace-ctx-extension-05>.

   [I-D.ietf-netconf-transaction-id]
              Lindblad, J., "Transaction ID Mechanism for NETCONF", Work
              in Progress, Internet-Draft, draft-ietf-netconf-
              transaction-id-07, 19 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
              transaction-id-07>.

   [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/info/rfc2119>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [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/info/rfc8174>.





Quilbeuf, et al.           Expires 7 May 2026                  [Page 15]

Internet-Draft     Configuration Tracing via trace-id      November 2025


   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [W3C-Trace-Context]
              "W3C Recommendation on Trace Context", 23 November 2021,
              <https://www.w3.org/TR/2021/REC-trace-context-
              1-20211123/>.

11.  Informative References

   [I-D.ietf-netmod-rfc8407bis]
              Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
              Authors and Reviewers of Documents Containing YANG Data
              Models", Work in Progress, Internet-Draft, draft-ietf-
              netmod-rfc8407bis-28, 5 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
              rfc8407bis-28>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9417]  Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
              Arumugam, "Service Assurance for Intent-Based Networking
              Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,
              <https://www.rfc-editor.org/info/rfc9417>.





Quilbeuf, et al.           Expires 7 May 2026                  [Page 16]

Internet-Draft     Configuration Tracing via trace-id      November 2025


Appendix A.  Changes between revisions

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

   05 -> 06

   *  Change Benoit's affiliation

   04 -> 05

   *  Fix security considerations template

   03 -> 04

   *  Add security and IANA considerations

   01 -> 02

   *  Remove YANG specific annotation for the mechanism to pass the
      client-id.

   *  Align with NETCONF Trace context draft.

   00(WG adoption) -> 01

   *  Define mechanism to pass the client-id.

   01 -> 02

   *  Switch to trace-parent instead of transaction id for tracing
      configuration

   00 -> 01

   *  Define Parent and Child Transaction

   *  Context for the "local-commit-id" concept

   *  Feedback from Med, both in text and YANG module

Appendix B.  Example of NETCONF message










Quilbeuf, et al.           Expires 7 May 2026                  [Page 17]

Internet-Draft     Configuration Tracing via trace-id      November 2025


   <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"
        xmlns:w3ctc="urn:ietf:params:xml:ns:netconf:w3ctc:1.0"
        xmlns:ext-txid=
          "urn:ietf:params:xml:ns:yang:ietf-external-transaction-id"
        w3ctc:traceparent=
          "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"
        ext-txid:client-id="controller-01">
     <commit/>
   </rpc>


          Figure 4: Example of NETCONF commit RPC with annotations

   In Figure 4, we present an RPC annotated with the traceparent and the
   client-id.  The traceparent example is taken from
   [I-D.ietf-netconf-trace-ctx-extension].  The client-id annotation is
   defined in our YANG module.  Here the client-id passed is
   'controller-01'.

Acknowledgements

   The authors would like to thank Mohamed Boucadair, Jan Linblad and
   Roque Gagliano for their reviews and propositions.

Authors' Addresses

   Jean Quilbeuf
   Huawei
   Email: jean.quilbeuf@huawei.com


   Benoit Claise
   Everything OPS
   Email: benoit@everything-ops.net


   Thomas Graf
   Swisscom
   Binzring 17
   CH-8045 Zurich
   Switzerland
   Email: thomas.graf@swisscom.com









Quilbeuf, et al.           Expires 7 May 2026                  [Page 18]

Internet-Draft     Configuration Tracing via trace-id      November 2025


   Diego R. Lopez
   Telefonica I+D
   Don Ramon de la Cruz, 82
   Madrid  28006
   Spain
   Email: diego.r.lopez@telefonica.com


   Qiong Sun
   China Telecom
   Email: sunqiong@chinatelecom.cn








































Quilbeuf, et al.           Expires 7 May 2026                  [Page 19]


name: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps
rev: 13
title: Zeroconf Multicast Address Allocation Problem Statement and Requirements
time: 2026-02-26T17:46:14Z
group_uri: /api/v1/group/group/1397/
expires: 2026-08-22T04:45:48Z
ad: /api/v1/person/person/108304/
shepherd: /api/v1/person/email/stig@venaas.com/
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:10.243465+00:00
abstract:
This document surveys current problems with existing protocols for
   automatically assigning multicast IP addresses in zero-configuration
   ("zeroconf") networking environments.  It addresses key challenges,
   such as link-layer address collisions, hardware limitations,
   multicast snooping inefficiencies, and the need to avoid manual
   configuration.  Based on these challenges, it derives requirements
   for a lightweight, decentralized solution for dynamically allocating
   unique multicast group addresses without central coordination.

   The document presents explicit requirements covering discovery,
   allocation, conflict detection and resolution, and lease management.
   It also evaluates considerations specific to IPv6 and IPv4 multicast
   address ranges, and identifies approaches that are unsuited for
   zeroconf deployment.  This foundation serves as a reference for
   developing future solutions for multicast address allocation that
   operate autonomously within local networks.

states:
["/api/v1/doc/state/1/", "/api/v1/doc/state/110/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
Network Working Group                                        N. Karstens
Internet-Draft                                                    Garmin
Intended status: Informational                              D. Farinacci
Expires: 21 August 2026                                      lispers.net
                                                              M. McBride
                                                               Futurewei
                                                        17 February 2026


Zeroconf Multicast Address Allocation Problem Statement and Requirements
             draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-13

Abstract

   This document surveys current problems with existing protocols for
   automatically assigning multicast IP addresses in zero-configuration
   ("zeroconf") networking environments.  It addresses key challenges,
   such as link-layer address collisions, hardware limitations,
   multicast snooping inefficiencies, and the need to avoid manual
   configuration.  Based on these challenges, it derives requirements
   for a lightweight, decentralized solution for dynamically allocating
   unique multicast group addresses without central coordination.

   The document presents explicit requirements covering discovery,
   allocation, conflict detection and resolution, and lease management.
   It also evaluates considerations specific to IPv6 and IPv4 multicast
   address ranges, and identifies approaches that are unsuited for
   zeroconf deployment.  This foundation serves as a reference for
   developing future solutions for multicast address allocation that
   operate autonomously within local networks.

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 21 August 2026.




Karstens, et al.         Expires 21 August 2026                 [Page 1]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


Copyright Notice

   Copyright (c) 2026 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Link-Layer Address Collisions . . . . . . . . . . . . . . . .   4
   3.  Solution Requirements . . . . . . . . . . . . . . . . . . . .   5
   4.  IPv6 Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  IPv4 Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Excluded Solutions . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Multicast communication is commonly used in networks that need to
   distribute data from one sender to multiple receivers efficiently.
   In some environments, such as small or isolated networks, multicast
   must operate without centralized servers or manual configuration.
   These are referred to as zero-configuration (zeroconf) multicast
   networks.

   One example of such an environment is marine networks, which
   typically include a mix of sensors, controls, and displays.  These
   networks vary in complexity depending on the size and design of the
   vessel.  Devices may range from low-cost temperature or fluid sensors
   to high-bandwidth sources such as radar, sonar, or video feeds.  Many
   marine networks are built on a single subnet and rely on Layer 2
   Ethernet switches to connect devices.




Karstens, et al.         Expires 21 August 2026                 [Page 2]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   In these networks, multicast is the most efficient method for
   distributing sensor data to multiple displays.  However, challenges
   arise when high-bandwidth multicast streams overload links to low-
   bandwidth devices.  Cost-effective switches often do not support
   source-specific multicast (SSM) because their address table only maps
   destination MAC addresses.  Instead, each multicast stream is
   assigned a unique destination multicast IP address, and IGMP/MLD
   snooping [RFC4541] is used to control multicast delivery.  This
   method introduces limitations, especially in environments where
   switch hardware lacks advanced multicast filtering capabilities.

   While marine networks illustrate these issues well, the challenges
   they face are not unique.  Many other zeroconf multicast
   environments, such as industrial automation, small-scale AV systems,
   or ad hoc sensor networks, share similar constraints.

   [RFC2730] (MADCAP) describes a method for multicast IP address
   allocation, but its server-based model does not suit a zeroconf
   environment.  [RFC3306] and [RFC4489] both discuss similar approaches
   to host-based multicast IPv6 address allocation, but neither
   adequately prevents link-layer address collisions.  Although
   [RFC3307] establishes a framework to avoid multicast address
   collisions at both IPv6 and link layers, additional refinement is
   needed to put this into practice (see Section 4).

   This document outlines the problem space for zeroconf multicast
   address allocation, describes the key limitations of current
   protocols, details sources of link-layer address collisions, and
   defines a set of requirements for decentralized, zero-configuration
   multicast address allocation solutions.  Multicast applications
   deployed in a zeroconf environment can use these solutions to
   dynamically allocate multicast group addresses.  The manner in which
   a multicast group address is used after allocation is outside the
   scope of this document.

   The organization of IPv6 multicast and immense volume of possible
   multicast addresses makes IPv6 well-suited for zeroconf multicast
   networks.  However, IPv4 is still considered by this document for
   networks where transitioning to IPv6 remains impractical.

1.1.  Requirements Language

   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.




Karstens, et al.         Expires 21 August 2026                 [Page 3]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   The requirements language is used in Section 3 and applies to
   implementations conformant to the listed requirements.

2.  Link-Layer Address Collisions

   Link-layer address collisions are a key concern in multicast
   networks, particularly when devices rely on zero-configuration
   operation.  Collisions occur when two or more multicast groups are
   assigned the same link-layer (MAC) address, leading to performance or
   forwarding issues.  This section outlines three scenarios where such
   collisions can cause problems.

   First, many host network interfaces allow filtering of multicast
   traffic directly in hardware.  When an application joins a multicast
   group, the host network stack typically programs the hardware to
   accept only traffic for that group.  However, if two groups share the
   same link-layer address, the network interface cannot distinguish
   them.  The network stack is then forced to process unwanted traffic
   in software, reducing performance and increasing CPU usage.

   Second, link-layer address collisions reduce the benefit of using
   multicast snooping switches on a network.  Section 4 of [RFC4541]
   indicates some switches forward multicast traffic based solely on the
   link-layer address, without considering the network-layer group (see
   the results for Q2 and Q3).  Although the survey is outdated,
   switches with these limitations still exist in some of the target
   deployments.  In such cases, if two multicast streams share the same
   MAC address, traffic may be sent to devices that did not request it.
   This is especially problematic when low-bandwidth links are
   overwhelmed by high-bandwidth streams.  Additional concerns related
   to the overlap of IPv6 and link-layer addresses are discussed in
   [RFC4541], Section 3.

   Third, the internal design of some switches can also contribute to
   collisions.  For example, certain switch implementations use a hash
   table with fixed buckets to store forwarding entries based on MAC
   addresses (see [US6690667B1]).  If multiple addresses hash to the
   same location and the bucket fills up, additional entries may be
   dropped or rejected, resulting in forwarding failures.

   These examples highlight why a collision-resistant multicast address
   allocation mechanism is essential in zeroconf environments.  The
   success of this approach depends on the capabilities of the hardware
   (such as the number of addresses supported by the filters in host
   network interfaces and the size of the tables maintained in switches/
   routers) and on the number of multicast groups that are subscribed to
   by a particular receiver.  When the number of entries in the filter
   tables exceeds availability, a typical fallback mechanism is to



Karstens, et al.         Expires 21 August 2026                 [Page 4]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   bypass the filter entirely and flood traffic to the receiver.  This
   subsequently incurs a per-packet cost for any software-based
   filtering that is needed.

3.  Solution Requirements

   A solution intended for decentralized, zero-configuration multicast
   IP address assignment is expected to operate in dynamic,
   infrastructure-free environments.  To be effective in such contexts,
   the solution needs to exhibit the following characteristics:

   1.  [REQ-1] Unique Address Assignment: Use of the solution SHALL
       result in a unique address being assigned to the multicast group
       at both the network and link layers.

   2.  [REQ-2] Resilience to Single Points of Failure: The solution
       SHALL be designed to minimize introduction of a single point of
       failure, ensuring that operation continues even if individual
       devices or links become unavailable.

   3.  [REQ-3] Zero User Configuration: It SHALL operate without
       requiring user or administrator configuration, allowing seamless
       deployment in unmanaged networks.

   4.  [REQ-4] Coexistence with Multicast Address Allocation Solutions:
       The design SHALL allow coexistence with other multicast IP
       address allocation solutions, including both manual assignment
       and existing dynamic protocols.

   5.  [REQ-5] Single-Subnet Operation: It SHALL support operation
       within a single IP subnet, which is typical in link-local or
       isolated network environments.

   6.  [REQ-6] No External Connectivity: The solution SHALL NOT require
       Internet access or connectivity to external infrastructure.

   7.  [REQ-7] Supports Multiple Host Applications: It SHALL support
       multiple applications on the same host, each independently
       allocating multicast addresses and transmitting to those
       addresses.

   8.  [REQ-8] Collision Detection and Resolution: The solution SHALL
       include mechanisms to detect and resolve multicast address
       collisions at both the network and link layers.







Karstens, et al.         Expires 21 August 2026                 [Page 5]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   Note: In rare cases, collisions may arise after a temporary network
   partition, when different parts of the network allocate the same
   multicast address independently.  Upon reconnection, such collisions
   SHALL be detectable and resolved gracefully by ensuring that
   conflicting streams are migrated to unique addresses.

   In addition to the above, the following characteristics are
   considered desirable, but are left as recommendations to allow for
   flexibility in solution design:

   1.  [CONS-1] Multi-Subnet Support: Operation across multiple subnets
       is beneficial in more complex or routed environments and SHOULD
       be supported.

   2.  [CONS-2] Standards Compatibility: The solution SHOULD aim to
       minimize the need for changes to existing protocols or standards
       that affect backwards compatibility or deployment in existing
       networks.

   3.  [CONS-3] Cross-Platform Availability: It SHOULD use capabilities
       that are widely available across host platforms and operating
       systems.

   4.  [CONS-4] Minimal Dependency on Manufacturing Data: It SHOULD
       avoid reliance on pre-loaded configuration or device-specific
       manufacturing data.

   5.  [CONS-5] Low Overhead: The solution SHOULD minimize the volume
       and frequency of network traffic generated during normal
       operation.

   6.  [CONS-6] Advertisement: The solution SHOULD describe a mechanism
       for advertising and discovering multicast addresses allocated for
       an application.

   7.  [CONS-7] Network Topology: To allow compatibility with a variety
       of networks, the solution SHOULD work independent of the dynamics
       of the underlying topology and adjacencies.

4.  IPv6 Considerations

   The rules for IPv6 multicast addresses, described in [RFC3307], are
   comprehensive and well-organized.  These rules must be followed by
   any solution allocating IPv6 multicast addresses, including solutions
   that meet the requirements defined in this document.  However, some
   aspects of its current organization need to be improved to ensure
   that a zeroconf multicast address assignment solution can coexist
   with other IPv6 multicast address assignment protocols.



Karstens, et al.         Expires 21 August 2026                 [Page 6]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   For example, Section 2 of [RFC3307] explains that the last 32 bits of
   an IPv6 multicast address, called the group ID, are mapped directly
   to the Ethernet MAC address.  Different parts of the group ID range
   are assigned based on how the address is allocated.  Section 4.3 of
   [RFC3307] describes two ways to assign group IDs dynamically: one
   where a server assigns addresses, and one where hosts assign
   addresses themselves.  However, both methods use the same group ID
   range, which creates a risk of address collisions if both are used at
   the same time.

   An additional concern is that the group IDs used for this dynamic
   range overlap with the range used for Solicited-Node multicast
   addresses, a special type of multicast used by IPv6 for neighbor
   discovery (see Section 2.7.1 of [RFC4291]).  This overlap increases
   the risk of unintentional conflicts with link-layer addresses.

   Note that [RFC3307] focuses on 48-bit addresses on Ethernet, but
   similar issues would be seen on any medium that generates link-layer
   multicast addresses by truncating an IPv6 multicast address.

5.  IPv4 Considerations

   In IPv4, multicast addresses can sometimes cause conflicts at the
   data link layer.  For example, as explained with Ethernet in
   Section 6.4 of [RFC1112], this happens because only the lower 23 bits
   of an IPv4 multicast address are used to generate the Ethernet
   multicast address.  Since an IPv4 multicast address is 32 bits and
   starts with a fixed 4-bit prefix (leaving 28 bits), this means up to
   2^(28-23) = 32 different multicast IP addresses can map to the same
   Ethernet address.  As a result, devices may receive multicast traffic
   they didn't ask for.

   The address allocation guidelines in [RFC5771] did not account for
   this type of collision when they were created.  Because of this
   limitation, the recommended approach for new designs that need
   dynamic multicast IP address assignment is to use IPv6 instead of
   IPv4.

   However, if using IPv4 is necessary, then multicast addresses SHOULD
   be chosen carefully from within the Administratively Scoped Block
   (239.0.0.0/8).  Additionally, solutions for zeroconf multicast
   address allocation SHOULD try to avoid using addresses that may
   already be in use by other applications on the same network, to
   minimize the risk of conflicts.







Karstens, et al.         Expires 21 August 2026                 [Page 7]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   Zeroconf coexistence with other IPv4 multicast address allocation
   solutions may not be possible, in which case it may be necessary to
   require manual configuration or to limit the solutions that are
   deployed.

6.  Security Considerations

   Zeroconf multicast address allocation mechanisms are vulnerable to
   accidental or malicious address collisions, which may lead to denial
   of service or misdirection of traffic.  Solutions derived from these
   requirements SHALL include measures for collision detection and
   conflict resolution [REQ-7], and SHOULD include measure to prevent
   unauthorized address use.  Specific security mechanisms are outside
   the scope of this document.

7.  IANA Considerations

   This document has no IANA actions.

8.  Acknowledgement

   Special thanks to the National Marine Electronics Association for
   their contributions in developing marine industry standards and their
   support for this research.

   Thanks also to the members of the PIM working group for their early
   brainstorming sessions and review of this draft, and to Gunter van de
   Velde for his review and suggestions.

9.  References

9.1.  Normative References

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <https://www.rfc-editor.org/info/rfc1112>.

   [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/info/rfc2119>.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
              <https://www.rfc-editor.org/info/rfc2464>.






Karstens, et al.         Expires 21 August 2026                 [Page 8]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
              <https://www.rfc-editor.org/info/rfc3307>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
              <https://www.rfc-editor.org/info/rfc4541>.

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              DOI 10.17487/RFC5771, March 2010,
              <https://www.rfc-editor.org/info/rfc5771>.

   [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/info/rfc8174>.

9.2.  Informative References

   [RFC2730]  Hanna, S., Patel, B., and M. Shah, "Multicast Address
              Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
              DOI 10.17487/RFC2730, December 1999,
              <https://www.rfc-editor.org/info/rfc2730>.

   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
              August 2002, <https://www.rfc-editor.org/info/rfc3306>.

   [RFC4489]  Park, J., Shin, M., and H. Kim, "A Method for Generating
              Link-Scoped IPv6 Multicast Addresses", RFC 4489,
              DOI 10.17487/RFC4489, April 2006,
              <https://www.rfc-editor.org/info/rfc4489>.

   [US6690667B1]
              Warren, D., "United States Patent 6690667B1: Switch with
              adaptive address lookup hashing scheme", 10 February 2004.









Karstens, et al.         Expires 21 August 2026                 [Page 9]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


Appendix A.  Excluded Solutions

   The way multicast IP addresses are mapped to link-layer multicast
   addresses is already defined in existing standards, such as [RFC1112]
   for IPv4 over Ethernet and [RFC2464] for IPv6 over Ethernet.  These
   standards specify a fixed prefix used in creating the Ethernet
   multicast address.  Changing this prefix would open the door to new
   solutions, but those are not being considered here for practical
   reasons.

   One idea is to reduce the size of the fixed prefix, which would leave
   more bits available for the group ID.  This would make address
   collisions less likely.  Another idea is to create a new protocol
   that dynamically maps multicast IP addresses to link-layer addresses,
   similar to how DHCP assigns IP addresses.  This protocol could work
   locally on a subnet, and routers could adjust the mapping for
   incoming multicast traffic at the network edge.

   However, these ideas would require significant changes to how network
   devices handle multicast traffic.  Since existing hardware and
   operating systems are built around the current standards, it's
   unlikely that such changes would be widely supported anytime soon.

   Another potential solution for IPv4 was to assign 32 separate, non-
   overlapping address ranges to avoid collisions altogether (e.g.,
   assign 224.0.0.254, 224.128.0.254, 225.0.0.254, etc.).  But this was
   rejected because [RFC5771] discourages new allocations, given how
   limited the IPv4 multicast address space already is.

Authors' Addresses

   Nate Karstens
   Garmin International, Inc.
   1200 E. 151st St.
   Olathe, KS 66062-3426
   United States of America
   Email: nate.karstens@gmail.com


   Dino Farinacci
   lispers.net
   San Jose, CA
   United States of America
   Email: farinacci@gmail.com







Karstens, et al.         Expires 21 August 2026                [Page 10]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


   Mike McBride
   Futurewei
   United States of America
   Email: michael.mcbride@futurewei.com















































Karstens, et al.         Expires 21 August 2026                [Page 11]


name: draft-jeong-opsawg-intent-based-sdv-framework
rev: 04
time: 2025-12-12T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-12-12T05:16:01Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Agent discovery/reg", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:10.243468+00:00
title:
An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems

abstract:
Software-Defined Vehicle (SDV) is a new player towards autonomous
   vehicles in Intelligent Transportation Systems (ITS).  An SDV is
   constructed by a software platform like a cloud-native system (e.g.,
   Kubernetes) and has its internal network.  To facilitate the easy and
   efficient configuration of networks in the SDV, an intent-based
   management is an appropriate direction.  This document proposes a
   framework of intent-based management for networks, security, and
   applications in SDVs so that they can communicate with other SDVs and
   infrastructure nodes for safe driving and infotainment services in
   the road networks.

full_text:
Operations and Management Area Working Group               J. Jeong, Ed.
Internet-Draft                                                   Y. Shen
Intended status: Informational                                    Y. Ahn
Expires: 11 December 2025                                          M. Gu
                                                 Sungkyunkwan University
                                                             9 June 2025


 An Intent-Based Management Framework for Software-Defined Vehicles in
                   Intelligent Transportation Systems
            draft-jeong-opsawg-intent-based-sdv-framework-04

Abstract

   Software-Defined Vehicle (SDV) is a new player towards autonomous
   vehicles in Intelligent Transportation Systems (ITS).  An SDV is
   constructed by a software platform like a cloud-native system (e.g.,
   Kubernetes) and has its internal network.  To facilitate the easy and
   efficient configuration of networks in the SDV, an intent-based
   management is an appropriate direction.  This document proposes a
   framework of intent-based management for networks, security, and
   applications in SDVs so that they can communicate with other SDVs and
   infrastructure nodes for safe driving and infotainment services in
   the road networks.

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 December 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Jeong, et al.           Expires 11 December 2025                [Page 1]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Intent-Based Management Framework for Software-Defined
           Vehicles  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Life Cycle of an IBS for SDV Management . . . . . . . . .   6
     3.2.  V2V and V2I Networking for SDVs . . . . . . . . . . . . .   7
     3.3.  Intent-Based Management Framework for SDVs  . . . . . . .   9
     3.4.  Interfaces in the SDV Management Framework  . . . . . . .  12
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Appendix A.  Changes from
           draft-jeong-opsawg-intent-based-sdv-framework-03  . . . .  18
   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  18
   Appendix C.  Contributors . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   The network management has been evolving dramatically from manual
   configuration to advanced automatic management.  This evolution leads
   to the intent-based network (IBN) management and automation
   [RFC9315], which has been driven by several factors, including
   complexity of networks, scale, cost and efficiency, dynamic
   environments, service delivery, and security [Survey-IBN-CST-2023].
   Apart from network management and automation, the automotive industry
   is also witnessing a fundamental transformation, particularly with
   the advent of software-defined vehicles (SDVs).  SDVs leverage
   powerful onboard high-performance computers (HPCs) and a high-speed
   network backbone, typically Ethernet-based Internet Protocol (IP)
   network [Survey-IPVehNet-2021], to enable flexible and dynamic
   allocation of functions and resources.  Shifting to SDVs is also a
   new paradigm in Intelligent Transportation Systems (ITS).  The SDVs
   can interact with each other via Vehicle-to-Vehicle (V2V)
   communications and infrastructure via Vehicle-to-Infrastructure (V2I)



Jeong, et al.           Expires 11 December 2025                [Page 2]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   communications (e.g., edge servers) for safe driving and infotainment
   services.  Figure 1 shows an architecture of vehicular networks for
   SDVs that are grouped into multiple subnets.  They can communicate
   with edge servers and vehicular cloud by IP Road-Side Unit (IP-RSUs,
   e.g., gNodeB in 5G [TS-23.501]).

                              Vehicular Cloud
               *******************************************
             *                                             *
            *              +------------------+             *
           *               | Cloud Controller |              *
           *               +------------------+              *
           *                         ^                       *
            *                        |                      *
             *                       v                     *
               *******************************************
                 ^ +------------+   ^ +------------+   ^ +------------+
                 | |Edge-Server1|   | |Edge-Server2|   | |Edge-Server3|
                 | +------------+   | +------------+   | +------------+
                 |   ^              |   ^              |   ^
                 |   |              |   |              |   |
                 v   V              v   V              v   V
               +---------+         +---------+        +---------+
               | IP-RSU1 |<------->| IP-RSU2 |<------>| IP-RSU3 |
               +---------+         +---------+        +---------+
                    ^                   ^                    ^
                    :                   :                    :
           +-----------------+ +-----------------+   +-----------------+
           |        : V2I    | |        : V2I    |   |       : V2I     |
           |        v        | |        v        |   |       v         |
+--------+ |   +--------+    | |   +--------+    |   |   +--------+    |
|  SDV1  |===> |  SDV2  |===>| |   |  SDV3  |===>|   |   |  SDV4  |===>|
+--------+<...>+--------+<........>+--------+    |   |   +--------+    |
           V2V     ^         V2V        ^        |   |        ^        |
           |       : V2V     | |        : V2V    |   |        : V2V    |
           |       v         | |        v        |   |        v        |
           |  +--------+     | |   +--------+    |   |    +--------+   |
           |  |  SDV5  |===> | |   |  SDV6  |===>|   |    |  SDV7  |==>|
           |  +--------+     | |   +--------+    |   |    +--------+   |
           +-----------------+ +-----------------+   +-----------------+
                 Subnet1              Subnet2              Subnet3
                (Prefix1)            (Prefix2)            (Prefix3)

        <----> Wired Link   <....> Wireless Link   ===> Moving Direction

      Figure 1: Vehicular Networks for Software-Defined Vehicles





Jeong, et al.           Expires 11 December 2025                [Page 3]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   To facilitate the development of SDVs, a large number of automotive
   companies and original equipment manufacturers (OEMs) are developing
   the components of SDVs based on different open architectures, such as
   AUTOSAR [AUTOSAR-SDV] and Eclipse SDV [Eclipse-SDV].  An SDV can
   include many electronic control units (ECUs) and hundreds of sensors
   and actuators for in-vehicle functions and services, e.g., advanced
   driver-assistance systems (ADAS), automatic emergency braking (AEB),
   forward collision warning (FCW), and lane keeping assist (LKA)
   applications.  They can also run multiple computing devices,
   operating systems, and a cloud-native platform (e.g., Kubernetes
   [Kubernetes]) to manage those ECUs and functions.  The Connected
   Vehicle System Alliance (COVESA) [COVESA] has developed a common
   vehicle signal specification (VSS) to represent the vehicle data to
   be shared for both in-vehicle and vehicle-to-cloud networks.
   Figure 2 shows a vehicular platform for SDV having foundation
   hardwares, a virtualization engine (i.e., Hypervisor), different
   operating systems (OS), various applications and network functions
   (such as NF-1 to NF-x) along with their runtime and management agent.

 +--------------------------------+  +---------------------------------+
 |            Apps                |  |          Functions              |
 | +------+  +------+  +-------+  |  | +------+  +------+     +------+ |
 | | ADAS |  |  LKA |  |  AEB  |  |  | | NF-1 |  | NF-2 | ... | NF-x | |
 | +------+  +------+  +-------+  |  | +------+  +------+     +------+ |
 +--------------------------------+  +---------------------------------+
 +-------------+  +--------------+  +-------------------+--------------+
 |Critical Apps|  |Classical Apps|  | Container Runtime |  Mgmt Agent  |
 +-------------+  +--------------+  +-------------------+--------------+
 +-----------------+   +-------------------+   +-----------------------+
 |                 |   |   Vehicle OS I    |   |     Vehicle OS II     |
 |    Real-Time    |   +-------------------+   +-----------------------+
 |       OS        |   +-----------------------------------------------+
 |                 |   |                    Hypervisor                 |
 +-----------------+   +-----------------------------------------------+
 +---------------------------------------------------------------------+
 |                    Vehicle Electric/Electronics                     |
 |  +------------------+  +------------------+  +------------------+   |
 |  |   Vehicle ECUs   |  |   Vehicle HPC    |  | Sensors/Actuators|   |
 |  +------------------+  +------------------+  +------------------+   |
 +---------------------------------------------------------------------+

                 Figure 2: A Vehicular Platform for SDV

   To manage the ever-growing network functions and applications in
   SDVs, SDVs need an intent-based management framework for networks and
   security inside their in-vehicle networks.  An intent is a
   declarative command to request a configuration for a network or
   security function [TS-28.312][TR-28.812].  It emphasizes more on



Jeong, et al.           Expires 11 December 2025                [Page 4]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   "What" is needed (i.e., declarative command) to be accomplished than
   "How" it should be accomplished (i.e., imperative command).  Since
   there are a huge number of vehicles produced by each automotive
   company, the networks and security for the SDV need to be remotely
   configured and monitored by a control center of each automotive
   company.  The in-vehicle networks are based on Gigabit Ethernet and
   can be configured as multiple subnets including ECUs and infotainment
   devices.  It requires huge overhead for an operator to configure and
   monitor networks and security for those in-vehicle networks.

   This document proposes a framework of intent-based management for
   networks, security, and applications in SDVs that are Service
   Functions (SFs).  Such SFs can be constructed and managed by
   Software-Defined Networking (SDN) [RFC7149], Network Functions
   Virtualization (NFV) [ETSI-NFV][ETSI-NFV-Release-2], and Cloud Native
   Computing Platform (e.g., Kubernetes [Kubernetes]).  This framework
   automates the configuration and monitoring for the networks and
   security in each SDV through a vehicular cloud and the SDV's mobile
   network.  An SDV User (i.e., administrator) for the management of
   SDVs can configure and monitor the networks and security through an
   intent.  The intent from the SDV User is delivered to a Cloud
   Controller in charge of a vehicular cloud for SDVs.  The Cloud
   Controller translates the intent into the corresponding high-level
   policy, and delivers the high-level policy to an SDV Controller in
   charge of an SDV.  The SDV translates the high-level policy into the
   corresponding low-level policy and delivered it to an appropriate
   Network Function (NF) for a specific service (e.g., router, firewall,
   and navigator) in the SDV.

2.  Terminology

   This document uses the terminology described in [RFC8329],
   [I-D.ietf-i2nsf-applicability],
   [I-D.jeong-opsawg-security-management-automation],
   [I-D.jeong-nmrg-ibn-network-management-automation], and [SPT].  In
   addition, the following terms are defined below:

   *  Intent: A set of operational goals (that a network should meet)
      and outcomes (that a network is supposed to deliver) defined in a
      declarative manner without specifying how to achieve or implement
      them [RFC9315].

   *  Intent-Based Management (IBM): It enforces an intent from a user
      (or administrator) into a target system (e.g., SDV).  An intent
      can be expressed as a Natural Language (e.g., English) and can be
      translated into a high-level policy by a Natural Language
      Processing (NLP) [USENIX-ATC-Lumi][BERT] [Deep-Learning].  In this
      document, the intent can be translated into the corresponding



Jeong, et al.           Expires 11 December 2025                [Page 5]

Internet-Draft        An Intent-Based SDV Framework            June 2025


      high-level policy by an intent translator
      [I-D.jeong-opsawg-security-management-automation].  The high-level
      policy can also be translated into the corresponding low-level
      policy by a policy translator [SPT].  The low-level policy is
      dispatched to appropriate Service Functions (SFs).  Through the
      monitoring of the SFs, the activity and performance of the SFs is
      monitored and analyzed.  If needed, the rules of the high-level or
      low-level network policy are augmented or new rules are generated
      and configured to appropriate SFs.

3.  Intent-Based Management Framework for Software-Defined Vehicles

   This section introduces the intent-based management framework for
   SDVs.  It first describes the life cycle of an intent-based system
   (IBS) for SDV management.  Then, it discusses the V2V and V2I
   networking in the framework.  Eventually, the components and
   interfaces of the framework are explained.

3.1.  Life Cycle of an IBS for SDV Management

   According to the life cycle design of IBN [RFC9315], Figure 3 shows
   the life cycle of an intent-based system (IBS) for SDV management.
   It divides the life cycle into three spaces, namely SDV User Space,
   Translation & IBS Space, and Network Operations (Ops) & Application
   (App) Space.  Each space is further divided into two sections,
   fulfillment and assurance.  The fulfillment section pipelines the
   steps (i.e., intent input, translation/refinement, learning/planning/
   rendering, and configuration/provisioning) toward the final SFs such
   as network functions (NFs) and applications in SDVs.  The assurance
   section monitors final results of the intent fulfillment to validate
   and analyze the resulted NFs and applications for SDVs.




















Jeong, et al.           Expires 11 December 2025                [Page 6]

Internet-Draft        An Intent-Based SDV Framework            June 2025


        SDV User      :            Translation/          : Network Ops/
         Space        :             IBS Space            :  App Space
 Fulfill              :                                  :
        +----------+  :  +------------+   +------------+ : +-----------+
        |Recognize/|---->| Translate/ |-->|   Learn/   |-->| Configure/|
        | Generate |  :  |   Refine   |   |   Plan/    | : | Provision |
        | Intent   |<----|            |   |   Render   | : |           |
        +----------+  :  +------------+   +------------+ : +-----------+
             ^        :                         ^        :       |
 ............|..................................|................|.....
             |        :                    +----------+  :       v
             |        :                    | Validate |  :  +----------+
             |        :                    +----^-----+<----| Monitor/ |
 Assure      |        :                         |        :  | Observe  |
         +--------+   :  +----------+      +----------+<----|          |
         | Report |<-----| Abstract |<-----| Analyze/ |  :  +----------+
         +--------+   :  +----------+      | Aggregate|  :
                      :                    +----------+  :


           Figure 3: The Life Cycle of IBS for SDV Management

3.2.  V2V and V2I Networking for SDVs

   Benefited from V2V and V2I networking, SDVs can be managed and
   monitored by the vehicular cloud.  Figure 4 shows an example of V2V
   communications between two SDVs having their internal SFs.  An SDV
   has its own internal networks (called in-vehicle networks), which
   consist of multiple subnets connected with each other through
   routers.  The SDV can communicate with other SDVs via the interface
   from an IP-based on-board unit (IP-OBU).  IP-OBU is a network device
   in an SDV that has a basic processing ability and can be driven by a
   low-power CPU (e.g., ARM) with a 5G Vehicle-to-Everything (V2X)
   communication device [RFC9365].  By the IP-OBU interface, the
   internal SFs of the SDV can also communicate with that of other SDVs.
   In this way, the internal SFs can be flexibly managed and controlled
   through V2V networking.














Jeong, et al.           Expires 11 December 2025                [Page 7]

Internet-Draft        An Intent-Based SDV Framework            June 2025


                           (*)<........>(*)
        (2001:db8:1:1::/64) |            | (2001:db8:1:2::/64)
   +------------------------|-----+  +---|-----------------------------+
   |                        v     |  |   v                             |
   | +---------+        +-------+ |  | +-------+         +---------+   |
   | |Navigator|        |IP-OBU1| |  | |IP-OBU2|         |Navigator|   |
   | +---------+        +-------+ |  | +-------+         +---------+   |
   |     ^                  ^     |  |     ^                  ^        |
   |     |                  |     |  |     |                  |        |
   |     v                  v     |  |     v                  v        |
   | ---------------------------- |  | ------------------------------- |
   | 2001:db8:10:1::/64 ^         |  |     ^ 2001:db8:20:1::/64        |
   |                    |         |  |     |                           |
   |                    v         |  |     v                           |
   | +---------+    +-------+     |  | +--------+ +-------+   +-------+|
   | |Firewall |    |Router1|     |  | |Firewall| |Router1|...|Router2||
   | +---------+    +-------+     |  | +--------+ +-------+   +-------+|
   |     ^              ^         |  |     ^         ^           ^     |
   |     |              |         |  |     |         |           |     |
   |     v              v         |  |     v         v           v     |
   | ---------------------------- |  | ------------------------------- |
   |      2001:db8:10:2::/64      |  |       2001:db8:20:2::/64        |
   +------------------------------+  +---------------------------------+
        SDV1 (Mobile Network1)              SDV2 (Mobile Network2)

      <----> Wired Link   <....> Wireless Link   (*) Antenna

                          Figure 4: V2V Networking

   SDVs can receive software updates as well as the configuration of
   their networks and security from the vehicular cloud.  As shown in
   Figure 1, SDVs as vehicles can communicate with each other via V2V
   and with infrastructure nodes such as IP-RSU via V2I, for example,
   gNodeB in 5G networks, respectively.  Figure 5 illustrates the V2I
   networking with edge and cloud networks for SDVs.  An Edge Network
   (EN) is a radio access network which has an IP-RSU for wireless
   communication with other SDVs having an IP-OBU and wired
   communication with other network devices (e.g., routers, IP-RSUs, and
   edge servers) [RFC9365].  The IP-RSU is a network device situated
   along the road as an infrastructure node.  It has at least two
   distinct IP-enabled interfaces where one is for 5G V2X and the other
   is for the wired network connected to the vehicular cloud [RFC9365].
   As shown in Figure 5, the IPv6 prefixes should be configured for both
   the in-vehicle network (also called mobile network) and EN.  Also,
   for V2X IP networking, the wireless interfaces of IP-OBU and IP-RSU
   should be configured with appropriate IPv6 network prefixes and
   default gateways towards the infrastructure network connected to the
   vehicular cloud.  An edge server in EN (e.g., Server1 inside EN1



Jeong, et al.           Expires 11 December 2025                [Page 8]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   shown in Figure 5) can help SDVs to perform their safe driving
   functions by processing environmental data collected by the SDVs and
   giving maneuver guidance to the SDVs.

                                                    +-----------------+
                           (*)<........>(*)  +----->| Vehicular Cloud |
        (2001:db8:1:1::/64) |            |   |      +-----------------+
   +------------------------|-----+  +---|---|-------------------------+
   |                        v     |  |   v   v                         |
   | +---------+        +-------+ |  | +-------+         +---------+   |
   | |Navigator|        |IP-OBU1| |  | |IP-RSU1|         |Navigator|   |
   | +---------+        +-------+ |  | +-------+         +---------+   |
   |     ^                  ^     |  |     ^                  ^        |
   |     |                  |     |  |     |                  |        |
   |     v                  v     |  |     v                  v        |
   | ---------------------------- |  | ------------------------------- |
   | 2001:db8:10:1::/64 ^         |  |     ^ 2001:db8:20:1::/64        |
   |                    |         |  |     |                           |
   |                    v         |  |     v                           |
   | +---------+    +-------+     |  | +-------+ +-------+   +-------+ |
   | |Firewall |    |Router1|     |  | |Router2| |Server1|...|ServerN| |
   | +---------+    +-------+     |  | +-------+ +-------+   +-------+ |
   |     ^              ^         |  |     ^         ^           ^     |
   |     |              |         |  |     |         |           |     |
   |     v              v         |  |     v         v           v     |
   | ---------------------------- |  | ------------------------------- |
   |      2001:db8:10:2::/64      |  |       2001:db8:20:2::/64        |
   +------------------------------+  +---------------------------------+
        SDV1 (Mobile Network1)              EN1 (Fixed Network1)

      <----> Wired Link   <....> Wireless Link   (*) Antenna

           Figure 5: V2I Networking with Edge and Cloud Networks

3.3.  Intent-Based Management Framework for SDVs

   For the automatic network configuration of SDVs, an intent-based
   management is required between the vehicular cloud and SDVs
   [I-D.jeong-nmrg-ibn-network-management-automation].  Figure 6 shows a
   framework of intent-based management for SDVs.  The framework
   consists of a vehicular cloud and SDVs.


                         <Vehicular Cloud (VC)>
 +---------------------------------------------------------------------+
 | +------------------+                      +--------------------+    |
 | |     SDV User     |          +---------->|    SDV Database    |    |
 | +------------------+          |           +--------------------+    |



Jeong, et al.           Expires 11 December 2025                [Page 9]

Internet-Draft        An Intent-Based SDV Framework            June 2025


 |          ^                    |                     ^               |
 |          |                    | Database            | Database      |
 |          |                    | Interface           | Interface     |
 |          | Consumer-Facing    |                     V               |
 |          | Interface (Intent) |           +--------------------+    |
 |          |                    | +-------->|    Cloud Analyzer  |<-+ |
 |          |                    | |         +--------------------+  | |
 |          V                    | |Analytics                        | |
 | +------------------+<---------+ |Interface                        | |
 | | Cloud Controller |<-----------+         +--------------------+  | |
 | +------------------+<-------------------->|Vendor's Mgmt System|  | |
 |          ^         Registration Interface +--------------------+  | |
 |          |                                          ^             | |
 +----------|------------------------------------------|-------------|-+
            | Controller-Facing Interface   VMS-Facing |   Analyzer- |
            |     (High-level Policy)        Interface |   Facing    |
            |                                          |   Interface |
 +----------|------------------------------------------|-------------|-+
 |          |                                          |             | |
 |          v                                          v             | |
 | +------------------+     Registration     +--------------------+  | |
 | |  SDV Controller  |<-------------------->|    SDV Vendor's    |  | |
 | +------------------+      Interface       |    Mgmt System     |  | |
 |          ^      ^                         +--------------------+  | |
 |          |      |                                                 | |
 |          |      |                                                 | |
 |          |      |   Analytics Interface   +--------------------+  | |
 |          |      +------------------------>|    SDV Analyzer    |<-+ |
 |          |                                +--------------------+    |
 |          | SF-Facing Interface                      ^               |
 |          |  (Low-level Policy)                      |               |
 |          |                                          |               |
 |          |                                          |               |
 |          |    +--------------+----------------------+---+           |
 |          |    |              |   Monitoring Interface   |           |
 |          v    v              v                          v           |
 |   +---------------+  +---------------+        +---------------+     |
 |   |     SF-1      |  |     SF-2      |........|     SF-n      |     |
 |   |   (Router)    |  |  (Firewall)   |        |  (Navigator)  |     |
 |   +---------------+  +---------------+        +---------------+     |
 +---------------------------------------------------------------------+
                   <Software-Defined Vehicle (SDV)>

    Figure 6: Intent-Based Management Framework for Software-Defined
                                Vehicles






Jeong, et al.           Expires 11 December 2025               [Page 10]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   The vehicular cloud consists of SDV User (as network administrator),
   Cloud Controller (as an orchestrator for a vehicular cloud), SDV
   Database (as a main repository for SDV management and monitoring),
   and Cloud Analyzer (as a monitoring data analyzer for SDVs) such as
   Network Data Analytics Function (NWDAF) in 5G networks
   [TS-23.288][TS-29.520].

   *  SDV User: It is the software (e.g., web-browser-based user
      interface) used by SDV administrators to deliver network intents
      to SDV controllers.  In the 3GPP intent driven management service
      document, it is assumed that network intent is configured by the
      intent data model.

   *  Cloud Controller: It is a component that controls and manages
      other system components of the vehicular cloud.  From a security
      point of view, a security service policy can be transmitted to the
      service function (SF) by converting the SDV User's security
      service intent into the corresponding security service policy and
      selecting an SF that provides an appropriate security service.

   *  Cloud Vendor's Management System: It is a component that provides
      images of virtualized SFs for vehicular cloud services and
      registers the SFs and access information with Cloud Controller.

   *  Cloud Analyzer: It gathers and evaluates monitoring data from SDV
      Analyzers to ensure the functionality and performance of SFs,
      e.g., the network data analytics function (NWDAF) in 5G networks.

   *  SDV Database: It is a database for managing SDVs, including
      network and security configuration information of SDVs, current
      location and navigation path of SDVs, etc.

   An IBS in SDV is composed of SDV Controller (as a manager for an
   SDV), SDV Analyzer (as a monitoring data analyzer for an SDV)
   [I-D.jeong-nmrg-ibn-network-management-automation], Vendor's
   Management System (as a vendor system to provide cloud-native
   containers) [RFC8329][I-D.ietf-i2nsf-applicability], and Service
   Functions such as NFs ( e.g., router, DNS server, firewall
   [I-D.jeong-nmrg-ibn-network-management-automation]) and applications
   (e.g., safe driver and navigator).  The functions of each component
   is described as follows.

   *  SDV Controller: It is a component that controls and manages other
      components of the SDV framework.  It translates the high-level
      policy received from the Cloud Controller into a low-level policy
      that the SF can understand.  An SF to perform this low-level
      service policy is selected, and the policy is transmitted to the
      SF.



Jeong, et al.           Expires 11 December 2025               [Page 11]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   *  SDV Vendor's Management System: It is a component that provides an
      image of a virtualized SF for SDV services to the SDV framework
      and registers the function and access information of the SF with
      SDV Controller.

   *  Service Function (SF): It is a component that refers to a virtual
      network function (VNF), cloud native network function (CNF), or
      physical network function (PNF) for a specific service.  For
      security services, it provides security services such as
      firewalls, web filters, DDoS attack mitigators, and anti-viruses.
      In addition, networks and application services can also operate as
      SFs.

   *  SDV Analyzer: It is a component that collects monitoring data from
      SFs of SDVs and analyzes these data to confirm the activity and
      performance of SFs.  SDV Analyzer acts as NWDAF in a 5G network.
      If there are problems (e.g., security attacks, traffic congestion,
      QoS degradation) in the SDV internal network, SDV Analyzer
      delivers either policy reconfiguration or feedback information to
      SDV Controller for security and network troubleshooting.

3.4.  Interfaces in the SDV Management Framework

   Together with the designed SDV management framework, in Figure 6,
   interfaces are also defined between a pair of system components in
   the vehicular cloud and SDV, respectively.  These interfaces include

   *  Consumer-Facing Interface: It is an interface between SDV User and
      Cloud Controller for conveying intents.

   *  Controller-Facing Interface: It is an interface between Cloud
      Controller and SDV Controller for high-level policy delivery with
      translated intents.

   *  SF-Facing Interface: It is an interface between SDV Controller and
      SF for the delivery of a translated lower-level policy.

   *  Registration Interface: It is an interface used to transfer SF
      capabilities and access information for registration to either
      Cloud Controller or SDV Controller, or deliver SF queries for
      searching the requested SFs.  This interface can be an interface
      between Cloud Controller and Cloud Vendor's Management System
      (Cloud VMS), or between SDV Controller and SDV Vendor's Management
      System (SDV VMS).

   *  Monitoring Interface: It is an interface between the SF and the
      SDV Analyzer used to collect the SF's monitoring data to identify
      SF-related security, system, and network issues.



Jeong, et al.           Expires 11 December 2025               [Page 12]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   *  Analytics Interface: It is an interface for delivering policy
      reconfiguration or feedback as a result of analyzing SF monitoring
      data.  This interface is an interface between SDV Analyzer and SDV
      Controller, between SDV Analyzer and Cloud Analyzer, or between
      Cloud Analyzer and Cloud Controller.

   *  Analyzer-Facing Interface: It is an interface between SDV Analyzer
      and Cloud Analyzer for the exchange of security, network, and
      system-related analysis of SFs.

   *  VMS-Facing Interface: It is an interface between Cloud VMS and SDV
      VMS to exchange SF container images with SF feature information.

   *  Database Interface: It is an interface for exchanging data in an
      SDV database.  It is an interface between SDV Database and Cloud
      Controller, or between SDV Database and Cloud Analyzer.

   The intent, high-level policy, and low-level policy can be either XML
   documents [RFC6020][RFC7950] or YAML documents [YAML].  They can be
   delivered to the destination components via NETCONF [RFC6241],
   RESTCONF [RFC8040], or REST API [REST].

   As shown in Figure 6, the Intent-Based Management SDV Framework
   enforces an intent from an SDV User, which as a user (or
   administrator), into a target system such as SDV.  The intent from
   the SDV User can be translated into the corresponding high-level
   policy by an intent translator in the Cloud Controller of the
   Vehicular Cloud [I-D.jeong-opsawg-security-management-automation].
   The high-level policy can also be translated into the corresponding
   low-level policy by a policy translator in the SDV Controller of the
   SDV [SPT].  The low-level policy is dispatched from the SDV
   Controller to appropriate Service Functions (SFs) in the SDV, such as
   Router, Firewall, and Navigator, as shown in the figure.  Through the
   monitoring of the SFs, the activity and performance of the SFs in the
   SDV is monitored and analyzed by the SDV Analyzer in the SDV.  If
   needed, the rules of the high-level or low-level network policy can
   be augmented by the SDV Analyzer.  Also, new rules can be
   automatically generated and configured to appropriate SFs by the SDV
   Analyzer.

   Therefore, this document proposes a framework of intent-based
   management for networks in Software-Defined Vehicles.  Through this
   intent-based management, the SFs in SDVs can be better managed and
   configured.  Base on the proposed framework, both virtualized network
   functions and applications can be efficiently orchestrated for agile
   network resource re-configurations and flexible SDV application
   updates.




Jeong, et al.           Expires 11 December 2025               [Page 13]

Internet-Draft        An Intent-Based SDV Framework            June 2025


4.  IANA Considerations

   This document does not require any IANA actions.

5.  Security Considerations

   The same security considerations for the Interface to Network
   Security Functions (I2NSF) Framework [RFC8329] are applicable to the
   intent-based management framework this document.

6.  References

6.1.  Normative References

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
              <https://www.rfc-editor.org/info/rfc8329>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/info/rfc9315>.

   [RFC9365]  Jeong, J., Ed., "IPv6 Wireless Access in Vehicular
              Environments (IPWAVE): Problem Statement and Use Cases",
              RFC 9365, DOI 10.17487/RFC9365, March 2023,
              <https://www.rfc-editor.org/info/rfc9365>.

6.2.  Informative References



Jeong, et al.           Expires 11 December 2025               [Page 14]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   [I-D.ietf-i2nsf-applicability]
              Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and D. Lopez,
              "Applicability of Interfaces to Network Security Functions
              to Network-Based Security Services", Work in Progress,
              Internet-Draft, draft-ietf-i2nsf-applicability-19, 3 April
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              i2nsf-applicability-19>.

   [I-D.jeong-opsawg-security-management-automation]
              Jeong, J. P., Lingga, P., Jung-Soo, J., Lopez, D., and S.
              Hares, "An I2NSF Framework for Security Management
              Automation in Cloud-Based Security Systems", Work in
              Progress, Internet-Draft, draft-jeong-opsawg-security-
              management-automation-01, 13 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-jeong-opsawg-
              security-management-automation-01>.

   [I-D.jeong-nmrg-ibn-network-management-automation]
              Jeong, J. P., Ahn, Y., Gu, M., Kim, Y., and J. Park,
              "Intent-Based Network Management Automation in 5G
              Networks", Work in Progress, Internet-Draft, draft-jeong-
              nmrg-ibn-network-management-automation-06, 9 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-jeong-nmrg-
              ibn-network-management-automation-06>.

   [SPT]      Lingga, P., Jeong, J., Yang, J., and J. Kim, "SPT:
              Security Policy Translator for Network Security Functions
              in Cloud-Based Security Services", IEEE Transactions on
              Dependable and Secure Computing, Volume 21, Issue 6,
              Available: https://ieeexplore.ieee.org/document/9416312,
              November 2024.

   [YAML]     Ingerson, B., Evans, C., and O. Ben-Kiki, "Yet Another
              Markup Language (YAML) 1.0",
              Available: https://yaml.org/spec/history/2001-05-26.html,
              October 2023.

   [TS-23.501]
              "System Architecture for the 5G System (5GS)", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3144, September
              2023.









Jeong, et al.           Expires 11 December 2025               [Page 15]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   [TS-28.312]
              "Intent Driven Management Services for Mobile Networks",
              Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3554, September
              2023.

   [TR-28.812]
              "Study on Scenarios for Intent Driven Management Services
              for Mobile Networks", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3553, December
              2020.

   [TS-23.288]
              "Architecture Enhancements for 5G System (5GS) to Support
              Network Data Analytics Services", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3579, September
              2023.

   [TS-29.520]
              "Network Data Analytics Services", Available:
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3355, September
              2023.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, March 2014,
              <https://www.rfc-editor.org/rfc/rfc7149>.

   [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural
              Framework", Available:
              https://www.etsi.org/deliver/etsi_gs/
              nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf,
              December 2014.

   [ETSI-NFV-Release-2]
              "Network Functions Virtualisation (NFV) Release 2;
              Management and Orchestration; Architectural Framework
              Specification", Available:
              https://www.etsi.org/deliver/etsi_gs/
              nfv/001_099/006/02.01.01_60/gs_nfv006v020101p.pdf, January
              2021.






Jeong, et al.           Expires 11 December 2025               [Page 16]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   [REST]     Fielding, R. and R. Taylor, "Principled Design of the
              Modern Web Architecture", ACM Transactions on Internet
              Technology, Vol. 2, Issue 2,,
              Available: https://dl.acm.org/doi/10.1145/514183.514185,
              May 2002.

   [USENIX-ATC-Lumi]
              Jacobs, A., Pfitscher, R., Ribeiro, R., Ferreira, R.,
              Granville, L., Willinger, W., and S. Rao, "Hey, Lumi!
              Using Natural Language for Intent-Based Network
              Management", USENIX Annual Technical Conference,
              Available:
              https://www.usenix.org/conference/atc21/presentation/
              jacobs, July 2021.

   [BERT]     Devlin, J., Chang, M., Lee, K., and K. Toutanova, "BERT:
              Pre-training of Deep Bidirectional Transformers for
              Language Understanding", NAACL-HLT Conference,
              Available: https://aclanthology.org/N19-1423.pdf, June
              2019.

   [Deep-Learning]
              Goodfellow, I., Bengio, Y., and A. Courville, "Deep
              Learning", Publisher: The MIT Press,
              Available: https://www.deeplearningbook.org/, November
              2016.

   [AUTOSAR-SDV]
              "AUTOSAR Adaptive Platform", Available: 
              https://www.autosar.org/standards/adaptive-platform, March
              2024.

   [Eclipse-SDV]
              "Eclipse Software Defined Vehicle Working Group Charter",
              Available: https://www.eclipse.org/org/workinggroups/sdv-
              charter.php, March 2024.

   [COVESA]   "Connected Vehicle Systems Alliance",
              Available: https://covesa.global/, March 2024.

   [Kubernetes]
              "Kubernetes: Cloud Native Computing Platform",
              Available: https://kubernetes.io/, March 2024.








Jeong, et al.           Expires 11 December 2025               [Page 17]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   [Survey-IBN-CST-2023]
              Leivadeas, A. and M. Falkner, "A Survey on Intent-Based
              Networking",
              Available: https://ieeexplore.ieee.org/document/9925251,
              March 2023.

   [Survey-IPVehNet-2021]
              Jeong, J., Shen, Y., Oh, T., Cespedes, S., Benamar, N.,
              Wetterwald, M., and J. Harri, "A comprehensive survey on
              vehicular networks for smart roads: A focus on IP-based
              approaches",
              Available: https://ieeexplore.ieee.org/document/9925251,
              June 2021.

Appendix A.  Changes from draft-jeong-opsawg-intent-based-sdv-
             framework-03

   The following changes are made from draft-jeong-opsawg-intent-based-
   sdv-framework-03:

   *  This version is submitted for the maintenance of draft-jeong-
      opsawg-intent-based-sdv-framework.

Appendix B.  Acknowledgments

   This work was supported by Institute of Information & Communications
   Technology Planning & Evaluation (IITP) grant funded by the Korea
   Ministry of Science and ICT (MSIT) (No.  RS-2024-00398199).

   This work was supported in part by Institute of Information &
   Communications Technology Planning & Evaluation (IITP) grant funded
   by the Korea Ministry of Science and ICT (MSIT) (No.  RS-
   2022-II221015, Development of Candidate Element Technology for
   Intelligent 6G Mobile Core Network).

   This work was supported in part by the National Research Foundation
   of Korea (NRF) grant funded by the Korea government, Ministry of
   Science and ICT (MSIT) (No. 2023R1A2C2002990), and by Basic Science
   Research Program through the NRF of Korea funded by the Ministry of
   Education (No. 2022R1I1A1A01053915).

Appendix C.  Contributors

   This document is made by the group effort of OPWAWG, greatly
   benefiting from inputs and texts by Linda Dunbar (Futurewei), Yong-
   Geun Hong (Daejeon University), and Joo-Sang Youn (Dong-Eui
   University).  The authors sincerely appreciate their contributions.




Jeong, et al.           Expires 11 December 2025               [Page 18]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   The following are coauthors of this document:

   Juwon Hong
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: hongju2024@skku.edu
   URI:   https://iotlab.skku.edu/people-Juwon-Hong.php


   Jiwon Suh
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: sjw6136@skku.edu
   URI:   http://iotlab.skku.edu/people-Jiwon-Suh.php


Authors' Addresses

   Jaehoon Paul Jeong (editor)
   Department of Computer Science and Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4957
   Email: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


   Yiwen Shen
   Department of Computer Science and Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon



Jeong, et al.           Expires 11 December 2025               [Page 19]

Internet-Draft        An Intent-Based SDV Framework            June 2025


   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: chrisshen@skku.edu
   URI:   https://chrisshen.github.io


   Yoseop Ahn
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: ahnjs124@skku.edu
   URI:   http://iotlab.skku.edu/people-Yoseop-Ahn.php


   Mose Gu
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4106
   Email: rna0415@skku.edu
   URI:   http://iotlab.skku.edu/people-Mose-Gu.php



















Jeong, et al.           Expires 11 December 2025               [Page 20]


