# drafts

name: draft-xiong-rtgwg-use-cases-hp-wan
rev: 00
title: Use Cases for High-performance Wide Area Network
time: 2025-01-03T08:05:07Z
group_uri: /api/v1/group/group/1027/
expires: 2025-01-04T07:30:33Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.396503+00:00
source: ietf
abstract:
  Big data and intelligent computing is widely adopted and in rapid
     development, with many applications demand massive data transmission
     with higher performance in wide area networks and metropolitan area
     networks.  This document describes the use cases for High-performance
     Wide Area Networks (HP-WAN).

full_text:
  RTGWG                                                           Q. Xiong
  Internet-Draft                                           ZTE Corporation
  Intended status: Informational                                     Z. Du
  Expires: 4 January 2025                                     China Mobile
                                                                     T. He
                                                              China Unicom
                                                                  H. Zhang
                                                             China Telecom
                                                                   J. Zhao
                                                                     CAICT
                                                               3 July 2024


              Use Cases for High-performance Wide Area Network
                   draft-xiong-rtgwg-use-cases-hp-wan-00

  Abstract

     Big data and intelligent computing is widely adopted and in rapid
     development, with many applications demand massive data transmission
     with higher performance in wide area networks and metropolitan area
     networks.  This document describes the use cases for High-performance
     Wide Area Networks (HP-WAN).

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

  Copyright Notice

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






  Xiong, et al.            Expires 4 January 2025                 [Page 1]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


     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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  High Performance Computing (HPC)  . . . . . . . . . . . .   4
       3.2.  Distributed Storage . . . . . . . . . . . . . . . . . . .   5
       3.3.  Data Migration  . . . . . . . . . . . . . . . . . . . . .   5
       3.4.  Collaborative Training across Multiple DCs  . . . . . . .   6
       3.5.  Cloud Computing Services  . . . . . . . . . . . . . . . .   6
       3.6.  Autonomous Driving  . . . . . . . . . . . . . . . . . . .   7
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     With the rapid development of big data and intelligent computing,
     there are many applications requiring data transmission between data
     centers (DC), such as cloud storage and backup of industrial internet
     data, digital twin modeling, Artificial Intelligence Generated
     Content (AIGC), multimedia content production, distributed training,
     High Performance Computing (HPC) for scientific research and so on.
     The long-distance connection and massive data transmission between
     intelligent computing centers have become a key factor affecting the
     performance.  Increasingly HPC connectivity must ensure data
     integrity and provide stable and efficient transmission services in
     Wide Area Networks (WAN) and Metropolitan Area Networks (MAN).

     Compared with ordinary networks, High-performance Wide Area Network
     (HP-WAN) puts forward higher performance requirements such as ultra-
     high bandwidth utilization, and ultra-low packet loss ratio ensuring
     effective high-throughput transmission.  This document describes key
     use cases for High-performance Wide Area Networks (HP-WAN).




  Xiong, et al.            Expires 4 January 2025                 [Page 2]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


  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.

  2.  Terminology

     The terminology is defined as following.

     High-performance Wide Area Networks (HP-WAN): indicates the WAN or
     MAN which puts forward higher performance requirements such as ultra-
     high bandwidth utilization, and ultra-low packet loss ratio ensuring
     effective high-throughput transmission.

     It also makes use of the following abbreviations and definitions in
     this document:

     DC:            Data Center

     DCI:           Data Centers Interconnection

     HPC:           High Performance Computing

     WAN:           Wide Area Networks

     MAN:           Metropolitan Area Networks

  3.  Use Cases

     Several characteristics and use cases may be documented for scenarios
     requiring high-performance data transmission in wide area networks,
     including:

     *  High Performance Computing (HPC): uses computing clusters to
        perform complex scientific computing and data analysis tasks.  It
        is necessary to support large-scale parallel processing, high-
        speed data transmission, and low latency communication to achieve
        effective collaboration between computing nodes.

     *  Distributed Storage: provides distributed data storage in
        different physical locations.  It is necessary to ensure efficient
        and reliable data transmission between different storage sites.






  Xiong, et al.            Expires 4 January 2025                 [Page 3]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


     *  Data Migration: refers to the process of transferring data from
        one system or storage location to another while ensuring the
        integrity, consistency, and usability of the data.

     *  Collaborative Training across Multiple DCs: refers to the process
        of distributed machine learning training between multiple data
        centers with Data Centers Interconnection (DCI).  It should
        provide sufficient bandwidth, low latency, and high reliability
        for data centers communications.

     *  Cloud Computing Services: provides computing resources through the
        internet for users.  It is necessary to optimize data
        synchronization between data centers.

     *  Autonomous Driving: provides big data management of autonomous
        driving which needs to be transmitted from the car systems to data
        center.

  3.1.  High Performance Computing (HPC)

     High Performance Computing (HPC) uses computing clusters to perform
     complex scientific computing and data analysis tasks.  HPC is a
     critical component to solve some complex problems in various fields
     such as scientific research, engineering, finance, and data analysis.

     For example, the research data of large science and engineering
     projects in cooperation with many research institutions requires
     long-term archiving of about 50~300PB of data every year.  The PSII
     protein process generates 30 to 120 high-resolution images per second
     during experiments.  This results in 60~100 GB of data every five
     minutes, requiring data transmission from one laboratory to another
     for analysis.  Another example is FAST astronomical data calculation
     with over 200 observations for each project, a single project
     generating observation data of TB~PB, and an annual production data
     of about 15PB per year.

     HPC requires high bandwidth and high-speed network to facilitate the
     rapid data exchange between processing units.  It also requires high-
     capacity and high-throughput storage solutions to handle the vast
     amounts of data generated by simulations and computations.  It is
     necessary to support large-scale parallel processing, high-speed data
     transmission, and low latency communication to achieve effective
     collaboration between computing nodes.








  Xiong, et al.            Expires 4 January 2025                 [Page 4]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


  3.2.  Distributed Storage

     Distributed storage is a method of storing data across multiple
     physical or virtual devices, which can be spread across different
     locations.  This method is designed to enhance data availability,
     improve performance, and provide redundancy.  In the big data
     environment, the increase in data size and complexity is often very
     rapid, requiring high scalability performance of the storage system.
     The scale of the big data storage system is huge and the node failure
     rate is high, so it is necessary to complete adaptive management
     functions.  The system must be able to estimate the required number
     of nodes based on the amount of data and computational workload, and
     dynamically migrate data between nodes and systems.  It also needs to
     move data from one storage system to another due to multiple reasons
     such as upgrading to a new storage system, consolidating storage, or
     moving to a cloud-based solution.  It needs to ensure that the
     migration process maintains data consistency across the distributed
     storage systems.

  3.3.  Data Migration

     Data migration is the process of transferring data from one system or
     storage location to another while ensuring the integrity,
     consistency, and usability of the data.  This can be necessary for
     various reasons, such as system upgrades, consolidation, or moving
     the data to a platform or storage site.

     For example, with the development of new media such as 4K/8K, 5G, AI,
     VR/AR and short video, large amount of audio and video data needs to
     be transmitted between data centers or different storage sites.  For
     AR/VR videos, the terminal outputs 1080P image quality requires 40M
     per user.  It demands data transmission with the traffic
     characteristics such as massive data scale and large burst.  For
     multimedia content production, the raw material data of a large-scale
     variety show or film and television program is at the PB level, with
     a single transmission of data in the range of 10TB to 100TB.

     Another data migration example is a P2P data express service, which
     requires task-based data transmission, point-to-point model, network
     resource pooling, high resilience and throughput, with single data
     ranging from TB to 100TB.  For the migration of backup data with the
     IT cloud resource pool is at the TB level, the working and backup
     data centers are built in different locations.  It requires long
     distance and massive data transmission for disaster recovery.







  Xiong, et al.            Expires 4 January 2025                 [Page 5]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


     Traditional data migration solutions include high-speed dedicated
     connectivity, which is expensive and manual transportation of hard
     copy which is as long as several days of each data transfer.  It is
     necessary to ensure efficient and reliable data transmission between
     different storage sites.

  3.4.  Collaborative Training across Multiple DCs

     With the increasing demand for computing power in AI large-scale
     model training, the scale of a single data center is limited due to
     factors such as power supply.  The AI training clusters expands from
     single data center to multiple DCs.  Collaborative training across
     multiple DCs typically refers to the process of distributed machine
     learning training across multiple data centers.

     For example, it is used for the training process of deep learning and
     the training data has reached 3.05TB.  Uploading a large model
     training templates requires uploading TB/PB level data to the data
     center.  Each training session has fewer data flows with larger
     bandwidth.  And 20% of the current network's services accounts for
     80% of the traffic which resulting in elephant flows.  The
     collaborative training method can improve computational efficiency,
     accelerate model training speed, and utilize more data resources.  It
     will distribute different parts of the model to different data
     centers, with each data center is responsible for calculating a
     portion of the model and then synchronously updates model parameters.
     Due to the demand for information exchange between data centers,
     communication efficiency is crucial for collaborative training.

     Compared with traditional DCI scenarios, parameters exchange
     significantly increases the amount of data transmission across DCs,
     typically from tens to hundreds of TBPS.  In addition, there is a
     higher demand for network latency and stability.  It must provide on-
     demand task allocation to different clusters, sufficient bandwidth,
     low latency, high throughput, and extremely high network availability
     and reliability for data centers communications.

  3.5.  Cloud Computing Services

     Cloud computing services represent a model where computing resources
     and data storage are provided over the Internet for users.  Main
     types of cloud computing services include Infrastructure as a Service
     (IaaS), Platform as a Service (PaaS), Database as a Service (DBaaS),
     Network as a Service (NaaS), Management as a Service (MaaS) and so
     on.  For example, MaaS is a cloud computing service model that
     service providers provide professional management services and tools
     through the internet to help customers manage their IT
     infrastructure, applications or business processes more effectively.



  Xiong, et al.            Expires 4 January 2025                 [Page 6]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


     MaaS services allow users to purchase services on the cloud, connect
     to multi-cloud computing, and achieve high experience.

     It must provide identity authentication and access management to
     ensure that only authorized users can access cloud services.  It is
     also required to synchronize user information between cloud storage
     services and local user data directories (such as Active Directory)
     for data backup, disaster recovery, and remote access.  It is
     necessary to optimize data synchronization between data centers.

  3.6.  Autonomous Driving

     Autonomous driving refers to the technology of vehicles that are
     capable of navigating without the need for human input.  It needs to
     use machine learning and AI algorithms to analyze the data from
     sensors to make decisions, such as identifying other vehicles,
     pedestrians, and traffic signals.  Vehicles record data from 4K HD
     cameras, laser scanners, and radars on the road.  Each vehicle can
     generate 80TB of data per day.  It is challenging for big data
     management to use autonomous driving.  Autonomous driving technology
     is categorized into different levels of automation, typically ranging
     from Level 0 (no automation) to Level 5 (full automation).  The
     amount of data required to be collected for vehicles of different
     levels shows a geometric increase.  For example, Level 2 autonomous
     vehicle needs 4~10PB data, Level 3 needs 50~100PB, and Level 5 needs
     more than 3EB.  It needs to transmit the vehicles record data from
     the car systems to data center.

  4.  Security Considerations

     This document covers a number of representative applications and
     network scenarios that are expected to make use of HP-WAN
     technologies.  Each of the potential use cases does not raise any
     security concerns or issues, but may have security considerations
     from both the use-specific perspective and the technology-specific
     perspective.

  5.  IANA Considerations

     This document makes no requests for IANA action.

  6.  Acknowledgements

     The authors would like to acknowledge Zheng Zhang, Yao Liu and Bin
     Tan for their thorough review and very helpful comments.

  7.  References




  Xiong, et al.            Expires 4 January 2025                 [Page 7]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


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

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

     [RFC7424]  Krishnan, R., Yong, L., Ghanwani, A., So, N., and B.
                Khasnabish, "Mechanisms for Optimizing Link Aggregation
                Group (LAG) and Equal-Cost Multipath (ECMP) Component Link
                Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424,
                January 2015, <https://www.rfc-editor.org/info/rfc7424>.

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

     [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
                and J. Hardwick, "Path Computation Element Communication
                Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
                DOI 10.17487/RFC8664, December 2019,
                <https://www.rfc-editor.org/info/rfc8664>.

     [RFC9232]  Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
                A. Wang, "Network Telemetry Framework", RFC 9232,
                DOI 10.17487/RFC9232, May 2022,
                <https://www.rfc-editor.org/info/rfc9232>.

  Authors' Addresses

     Quan Xiong
     ZTE Corporation
     China
     Email: xiong.quan@zte.com.cn


     Zongpeng Du
     China Mobile
     China
     Email: duzongpeng@chinamobile.com






  Xiong, et al.            Expires 4 January 2025                 [Page 8]


  Internet-Draft  Use Cases for High-performance Wide Area       July 2024


     Tao He
     China Unicom
     China
     Email: het21@chinaunicom.cn


     Huiyue Zhang
     China Telecom
     China
     Email: zhanghy30@chinatelecom.cn


     Junfeng Zhao
     CAICT
     China
     Email: zhaojunfeng@caict.ac.cn



































  Xiong, et al.            Expires 4 January 2025                 [Page 9]


name: draft-xiong-rtgwg-requirements-hp-wan
rev: 00
title: Requirements for High-performance Wide Area Networks
time: 2025-01-03T08:05:08Z
group_uri: /api/v1/group/group/1027/
expires: 2025-01-04T07:32:16Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.401051+00:00
source: ietf
abstract:
  Many applications such as big data and intelligent computing demand
     massive data transmission between data centers, which needs to ensure
     data integrity and provide stable and efficient transmission services
     in wide area networks and metropolitan area networks.  This document
     outlines the requirements for High-performance Wide Area Networks
     (HP-WAN).

full_text:
  RTGWG                                                           Q. Xiong
  Internet-Draft                                                    C. Gao
  Intended status: Informational                           ZTE Corporation
  Expires: 4 January 2025                                           Z. Han
                                                              China Unicom
                                                                   G. Zhao
                                                              China Mobile
                                                                     W. Qu
                                                             China Telecom
                                                               3 July 2024


            Requirements for High-performance Wide Area Networks
                  draft-xiong-rtgwg-requirements-hp-wan-00

  Abstract

     Many applications such as big data and intelligent computing demand
     massive data transmission between data centers, which needs to ensure
     data integrity and provide stable and efficient transmission services
     in wide area networks and metropolitan area networks.  This document
     outlines the requirements for High-performance Wide Area Networks
     (HP-WAN).

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

  Copyright Notice

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






  Xiong, et al.            Expires 4 January 2025                 [Page 1]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


     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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Primary Goals . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Extremely Low or Zero Packet Loss Ratio . . . . . . . . .   4
       3.2.  Low Long-distance Delay and Jitter  . . . . . . . . . . .   4
       3.3.  Ultra-high Bandwidth Utilization  . . . . . . . . . . . .   5
     4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Support High-precision Flow Control . . . . . . . . . . .   5
       4.2.  Support Congestion Control based on End-network
             Coordination  . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Support Muti-path Load Balance  . . . . . . . . . . . . .   6
       4.4.  Support the Differentiated Traffic Scheduling . . . . . .   7
       4.5.  Support Flow-based Network Monitoring . . . . . . . . . .   7
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Big data and intelligent computing is undergoing rapid development.
     There are many applications requiring massive data transmission
     between data centers, which need to ensure data integrity and provide
     stable and efficient transmission services in Wide Area Networks
     (WAN) and Metropolitan Area Networks (MAN).  The use cases have been
     discussed in [I-D.xiong-rtgwg-requirements-hp-wan].  The industries
     need to solve the problems such as long distance, slow feedback,
     multiple paths, load balance, low throughput and so on.

     Compared with ordinary WAN, High-performance Wide Area Networks (HP-
     WAN) puts forward higher performance requirements such as ultra-high
     bandwidth utilization, and ultra-low packet loss ratio ensuring
     effective high-throughput transmission.  The topology in HP-WAN is
     complicated with long distances, multiple hops, paths, domains and



  Xiong, et al.            Expires 4 January 2025                 [Page 2]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


     the services are massive and concurrent with multiple types and
     different traffic models such as the elephant flows with short
     interval time, high speed and large data scale.

     The network requirements demand high performance such as the high-
     throughput data transmission between data centers.  It is viewed as
     the main performance indicator which is affected by long-distance
     delays, jitter and packet loss ratio.  For example, the massive data
     transmission between data centers mainly depend on the transport
     layer protocols such as Transfer Control Protocol (TCP), Remote
     Direct Memory Access (RDMA) and Quick UDP Internet Connections (QUIC)
     etc.  The throughput will dramatically decrease when the packet loss
     ratio is over a threshold value.  Extremely low packet loss ratio or
     even zero packet loss will greatly reduce the bandwidth resource
     consumption caused by packet loss retransmission.

     Existing technologies in data centers, e.g.  Priority-based Flow
     Control (PFC) [IEEE 802.1qbb] and Explicit Congestion Notification
     (ECN) [RFC3168], have problems due to various service types, massive
     data, large burst, and high Round-Trip Time (RTT) latency and jitter
     in large-scale networks.  It will be challenging to achieve high-
     throughput transmission in HP-WAN.

     This document outlines the requirements for High-performance Wide
     Area Networks (HP-WAN).

  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.

  2.  Terminology

     The terminology is defined as following.

     High-performance Wide Area Networks (HP-WAN): indicates the WAN or
     MAN which puts forward higher performance requirements such as ultra-
     high bandwidth utilization, and ultra-low packet loss ratio ensuring
     effective high-throughput transmission.

     Abbreviations and definitions used in this document:

     PFC:           Priority Flow Control

     ECN:           Explicit Congestion Notification



  Xiong, et al.            Expires 4 January 2025                 [Page 3]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


     ECMP:          Equal-Cost Multipath

     RTT:           Round-Trip Time

     TCP:           Transfer Control Protocol

     RDMA:          Remote Direct Memory Access Round-Trip Time

     QUIC:          Quick UDP Internet Connections

     WAN:           Wide Area Networks

     MAN:           Metropolitan Area Networks

  3.  Primary Goals

     The primary goal of HP-WAN is to ensure the effective high-throughput
     transmission of massive data with the performance indicators such as
     ultra-high bandwidth utilization, zero packet loss ratio and low
     latency.  For instance, the computing method of throughput for TCP is
     as following shown.

     Throughput = min{BW,WindowSize/RTT,(MSS/RTT)*(1/P));

     BW indicates the maximum bandwidth, WindowSize indicates the size of
     the window, MSS indicates the maximum segment size, RTT indicates the
     round time delay, P indicates the square root of packet loss ratio.

  3.1.  Extremely Low or Zero Packet Loss Ratio

     According to the throughput computing formula, the packet loss
     negatively correlates with throughput.  The lower the packet loss
     rate, the higher the throughput.  According to the experimental data,
     for TCP, the throughput dramatically decreases up to 89.9% when the
     packet loss ratio is 2%. For RDMA, the throughput dramatically
     decreases with a packet loss ratio greater than 0.1%, and a 2% packet
     loss ratio effectively reduces the throughput to zero.  It is
     important to ensure the extremely low or zero packet loss ratio to
     achieve high-throughput data transmission in HP-WAN.

  3.2.  Low Long-distance Delay and Jitter

     According to the throughput computing formula, the RTT is negatively
     correlated with throughput.  The lower the RTT, the higher the
     throughput.  But the RTT delay is impacted with the long-distance
     latency.  For example, when the distance between the data centers is
     500 kilometers, the RTT is 5ms.  When the distance is 3000
     kilometers, the RTT is 30ms.  According to the experimental data,



  Xiong, et al.            Expires 4 January 2025                 [Page 4]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


     when the jitter is over 300~500us, the throughput will dramatically
     decrease.  So it is required to guarantee low long-distance delay and
     jitter to achieve high-throughput data transmission in HP-WAN.

  3.3.  Ultra-high Bandwidth Utilization

     It is important to reserve sufficient bandwidth to achieve high-
     throughput transmission for a single flow.  But for massive
     concurrent flows in a network with certain resources, bandwidth
     utilization is the key aspect.  Ultra-high bandwidth utilization
     refers to the efficient use of available network capacity to maximize
     data transfer rates and minimize latency.  This is particularly
     important in scenarios where high volumes of data need to be
     transferred quickly.  So it is required to improve the bandwidth
     utilization to achieve high-throughput data transmission for multiple
     concurrent services in HP-WAN.

  4.  Requirements

     Challenges of high-throughput transmission in HP-WAN come from
     massive concurrent services and long-distance delays, jitter and
     packet loss.  The existing network technologies have various problems
     and cannot meet the demands.  This document outlines the requirements
     for high-throughput data transmission in HP-WAN.

  4.1.  Support High-precision Flow Control

     Flow control refers to a method for ensuring the data is transmitted
     efficiently and reliably and controlling the rate of data
     transmission to prevent the fast sender from overwhelming the slow
     receiver and prevent packet loss in congested situations.  PFC
     (Priority-based Flow Control) [IEEE 802.1qbb] is a hop-by-hop and
     priority-based flow control method which provides backpressure
     mechanism for the receiver signals the sender to slow down the rate
     of data transmission.  For the long-distance link and transmission
     delay in WAN, it is required to configure the reasonable threshold
     and increase buffer for effective throughput without packet loss.

     PFC creates 8 virtual channels on a link and assigns a priority to
     each channel, allowing for individual pause and restart of any one of
     the virtual channels.  The existing flow control mechanism is based
     on port and priority with limited number, while there are multiple
     services with various types and different traffic requirements.  It
     is required to provide fine-grained and high-precision flow control
     to reduce the impact between different traffic flows.






  Xiong, et al.            Expires 4 January 2025                 [Page 5]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


  4.2.  Support Congestion Control based on End-network Coordination

     Congestion control refers to a method for controlling the total
     amount of data entering the network to maintain the traffic at an
     acceptable level.  The difference between congestion control and flow
     control is that flow control acts on the receiver, while congestion
     control acts on the network.  As per [RFC3168], ECN defines an end-
     to-end congestion notification mechanism based on IP and transport
     layers.  When the congestion occurred, the device marks packets and
     transmits congestion information to the server and the server sends
     packets to the client to notify the source to adjust the transmission
     rate to achieve congestion control.

     The long-distance transmission of thousands of kilometers results in
     extremely long link transmission delays and it will delay the network
     state feedback.  And it is inefficient that 1-bit ECN signal can not
     specify the detailed congestion information.  And it mainly relies on
     passive congestion control to adjust the rate after receiving
     congestion signals.  It is required to improve the congestion control
     by enhancing the IP network capability to achieve the end and network
     coordination in WAN.  For example, the device could initial the
     notification directly to the source and provide precise notification
     information.  And the device in the network may further perform the
     proactive congestion control.

  4.3.  Support Muti-path Load Balance

     Load balance refers to a method for the allocation of load (traffic)
     to multiple links for forwarding traffic.  When transmitting
     intelligent computing services, the traffic is mainly elephant flow
     and the network resources is insufficient in WAN.  Uneven network
     load will lead to a decrease in network throughput and low link
     utilization.  In order to improve bandwidth utilization, it is
     required to implement multi-path load balance to achieve low latency,
     zero packet loss and high-throughput performance in WAN.
















  Xiong, et al.            Expires 4 January 2025                 [Page 6]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


     There are three optional methods such as flow-based ECMP, flowlet-
     based load balance and packet-based load balance.  As per [RFC7424],
     Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) are used
     for bandwidth scaling.  ECMP uses 5-tuple for HASH load balancing to
     achieve per-flow load balancing and link backup and it is applied to
     scenarios with large number of flows.  It will be challenging for
     HASH conflict and poor network balancing with massive elephant flows.
     For example, flow-based ECMP will distribute the elephant flows into
     the same link, resulting in congestion and packet loss.  Packet-based
     load balance will result in out-of-order packets.  Flowlet-based load
     balance can distribute the sub-flows to different paths.  The time
     interval gap value between sub-flows needs be accurately configured
     based on the delay information of multiple path.  The deterministic
     technology can be implemented to guarantee the latency and jitter.

  4.4.  Support the Differentiated Traffic Scheduling

     Traffic scheduling refers to a method for managing and allocating the
     flow of data packets within a network to optimize performance and
     utilize network resources efficiently.  Considering the multiple
     services with various types and different traffic requirements, the
     traffic is required to be scheduled to multiple paths and resources
     to achieve differentiated QoS requirements.  The existing
     technologies such as resource reservation, network slicing, queuing-
     based solutions to guarantee deterministic latency can be used for
     providing zero packet loss, long-distance latency and jitter
     guarantees and high reliability in WAN.  For example, the flow-
     specific data may require low latency or loose latency and it is
     required to provide different queuing and scheduling functionalities.

  4.5.  Support Flow-based Network Monitoring

     When a fault occurs in data transmission, it should discover root
     causes of some of the hard-to-debug network and identify the node
     which is dropping the packets.  Bandwidth monitoring is also
     important for network planning and service-level assurance, which the
     network operators can predict bandwidth availability and guarantee
     the high-throughput transmission.  The performance monitoring is a
     critical aspect of managing and optimizing networks such as end-to-
     end measurement of packet loss, latency, jitter and hop-by-hop node
     ID, node delay, queue and buffer information.

     As per [RFC9232], network telemetry is a technology for gaining
     network insight and facilitating efficient and automated network
     management.It is required to provide flow-based network monitoring
     based on telemetry, which makes it easier to troubleshoot issues and
     monitor bandwidth, traffic and performance.




  Xiong, et al.            Expires 4 January 2025                 [Page 7]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


  5.  Security Considerations

     This document lists the requirements for HP-WAN and does not raise
     any security concerns or issues in addition to ones common to
     networking which may have security considerations from both the use-
     specific perspective and the technology-specific perspective.

  6.  IANA Considerations

     This document makes no requests for IANA action.

  7.  Acknowledgements

     The authors would like to acknowledge Yao Liu, Zheng Zhang and Bin
     Tan for their thorough review and very helpful comments.

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

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

     [RFC7424]  Krishnan, R., Yong, L., Ghanwani, A., So, N., and B.
                Khasnabish, "Mechanisms for Optimizing Link Aggregation
                Group (LAG) and Equal-Cost Multipath (ECMP) Component Link
                Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424,
                January 2015, <https://www.rfc-editor.org/info/rfc7424>.

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

     [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
                and J. Hardwick, "Path Computation Element Communication
                Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
                DOI 10.17487/RFC8664, December 2019,
                <https://www.rfc-editor.org/info/rfc8664>.






  Xiong, et al.            Expires 4 January 2025                 [Page 8]


  Internet-Draft  Requirements for High-performance Wide A       July 2024


     [RFC9232]  Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
                A. Wang, "Network Telemetry Framework", RFC 9232,
                DOI 10.17487/RFC9232, May 2022,
                <https://www.rfc-editor.org/info/rfc9232>.

  Authors' Addresses

     Quan Xiong
     ZTE Corporation
     China
     Email: xiong.quan@zte.com.cn


     Chenqiang Gao
     ZTE Corporation
     China
     Email: gao.chenqiang@zte.com.cn


     Zhengxin Han
     China Unicom
     China
     Email: hanzx21@chinaunicom.cn


     Guangyu Zhao
     China Mobile
     China
     Email: zhaoguangyu@chinamobile.com


     Wenkuan Qu
     China Telecom
     China
     Email: quwk@chinatelecom.cn
















  Xiong, et al.            Expires 4 January 2025                 [Page 9]


name: draft-chen-tsvwg-high-speed-data-express
rev: 00
title: High speed data express in IP: Concept, Reference Architecture and Technologies
time: 2025-01-09T08:05:58Z
group_uri: /api/v1/group/group/1027/
expires: 2025-01-09T10:05:09Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.405973+00:00
source: ietf
abstract:
  With the rapid development of AI technology, intelligent computing
     and super-computing services, the demand for wide-area transmission
     of massive data is increasing.  This paper makes full use of the
     advantages of IP network, such as statistical reuse and elastic
     supply, and proposes a reference architecture of high elasticity and
     high throughput data express based on IP network.  In order to
     support differentiated data express services and create task-type
     data express services, the "one low and three high" technical system
     is proposed.

full_text:
  Internet Research Task Force                                     D. Chen
  Internet-Draft                                                     Z. Li
  Intended status: Informational                              China Mobile
  Expires: 9 January 2025                                      8 July 2024


     High speed data express in IP: Concept, Reference Architecture and
                                Technologies
                draft-chen-tsvwg-high-speed-data-express-00

  Abstract

     With the rapid development of AI technology, intelligent computing
     and super-computing services, the demand for wide-area transmission
     of massive data is increasing.  This paper makes full use of the
     advantages of IP network, such as statistical reuse and elastic
     supply, and proposes a reference architecture of high elasticity and
     high throughput data express based on IP network.  In order to
     support differentiated data express services and create task-type
     data express services, the "one low and three high" technical system
     is proposed.

  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 RFC 2119 [RFC2119].

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







  Chen & Li                Expires 9 January 2025                 [Page 1]


  Internet-Draft    Transport and Services Working Group         July 2024


  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   3
     3.  "One low, three high" technology system . . . . . . . . . . .   6
     4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     With the rapid development of AI technology, intelligent computing,
     and super-computing services, the demand for wide-area transmission
     of massive data is increasing.  How to transfer a large amount of
     data quickly, efficiently and conveniently has become an important
     problem that needs to be solved in the development of communication
     networks.  With the network bandwidth from 10G to 25G, 100G, 200G and
     even 400G, bandwidth is not the bottleneck of data transmission, the
     key to data transmission is how to make full use of large bandwidth
     to achieve efficient throughput.

     In most cases, the effective throughput is less than the throughput,
     which in turn is less than the bandwidth.  Bandwidth refers to the
     number of bits that can be transmitted per second on the link, which
     depends on the link clock rate and channel coding, also known as line
     speed (network device transmission capacity).  Throughput refers to
     the actual amount of data transmitted on the bandwidth (terminal
     device transmission capacity).  Goodput refers to the throughput that
     truly meets service requirements, excluding invalid packets such as
     retransmission and discarding (service data transmission
     capability)..




  Chen & Li                Expires 9 January 2025                 [Page 2]


  Internet-Draft    Transport and Services Working Group         July 2024


     In-depth analysis shows that the data transmission throughput
     performance is mainly affected by five factors: transmission
     distance, network packet loss rate, effective data length , sending
     window and the impact factor.  As the transmission distance
     increases, RTT (round trip delay) increases.  In reliable
     transmission mode, the reply time of ACK acknowledgement messages
     becomes longer, and the sending sliding window cannot be adjusted in
     time.  Network packet loss rate will affect the rate adjustment of
     congestion control algorithm, and increase the tail delay of data
     transmission.  Effective data length refers to the effective data
     length of the packet header removed, which can be regarded as MSS.
     Increasing MSS will help improve throughput.  The sending window
     affects the duration of continuous data sending.  If the window is
     too small, data will be sent before the ACK reply is completed, and
     sending will be paused.  The impact factor F is a comprehensive
     parameter, such as the CPU frequency, PCIE rate, disk I/O rate, and
     bandwidth that affect the packet processing rate, 0<F<1, if these
     have no impact, the value of F is 1.  In summary, we can draw the
     following conclusion: in addition to improving the network
     environment (improving the physical bandwidth, etc.), the end-to-end
     data sending and receiving mechanism and transmission protocol are
     also a key part of the effective throughput.

     In order to improve the data transmission efficiency and reduce the
     data transmission cost as much as possible, we propose to build a
     highly elastic and high-throughput data transmission network based on
     IP network, and use elastic bandwidth, load balancing, security
     encryption and other technologies to realize new data express
     services.

  2.  Reference Architecture

     The data express solution enables massive data transmission from the
     data source to the destination.  Data sources are devices or systems
     that generate or store large amounts of data, such as enterprise
     servers, databases, and storage devices.  Data sources can be
     multiple nodes distributed across different geographies and network
     environments, or they can be a single node concentrated in one
     location.  Data destination refers to the device or system that
     receives or processes a large amount of data, such as cloud computing
     platform, intelligent computing center, and supercomputing center.
     The data destination can be a public service provided by a third
     party or a cloud data center built by a data express operator.








  Chen & Li                Expires 9 January 2025                 [Page 3]


  Internet-Draft    Transport and Services Working Group         July 2024


     Based on the massive transmission requirements from the data source
     to the destination end, the overall architecture of the data express
     solution is designed according to the hierarchical idea, which mainly
     includes three parts: cloud private network infrastructure, network
     controller and data express operation platform, as shown in

                              +--------------------+
                              |                    |
                              |    Data Express    |
               Task  -------> | Operation Platform |
             Delivery         |                    |
                              +---------+----------+
                                        |
                             +----------+-----------+
                             |                      |
             +---------------+  Network Controller  +---------+
             |               |                      |         |
             |               +-----------+----------+         |
             |                           |                    |
             |                           |                    |
     +-------+---------------------------+--------------------+----------+
     |                                                                   |
     | +-----------+                                       +-----------+ |
     | |Data Source|                                       |  Super    | |
     | |  Memory   |                                +------+ Computing | |
     | | card/disk |                Wide Area       |      |  Center   | |
     | +-----+-----+     +------+Interconnection +--+--+   +-----------+ |
     |       |           |Cloud +----------------+Cloud|                 |
     |       |           |  PE  |                | PE  |                 |
     |       |           +---+--+                +--+--+   +-----------+ |
     | +-----v------+        |                      |      |  General  | |
     | |Data Express|        |                      +------+ Computing | |
     | |  Station   +--------+                             |   Center  | |
     | +------------+                                      +-----------+ |
     |                                                                   |
     |                      Infrastructure                               |
     +-------------------------------------------------------------------+

        Infrastructure












  Chen & Li                Expires 9 January 2025                 [Page 4]


  Internet-Draft    Transport and Services Working Group         July 2024


        -  Data Express can use the existing network infrastructure to
           provide data transmission services for customers, and can
           access different data source and data consumption end through
           SPN, PON, optical fiber direct connection and other means
           according to the situation of live network resources, so as to
           achieve dynamic scheduling and optimization of network
           resources and ensure the quality and efficiency of data
           transmission.  SPN is the recommended access mode for data
           express because of its large access bandwidth, elastic
           bandwidth configuration, and wide coverage.

        Network Controller

        Network controllers include SPN and other network controllers in
        different fields, which complete the network configuration
        according to the requirements of the service platform, and realize
        the whole process automation and intelligent opening of the data
        express service.  The main functions include:

        -  Network configuration: Automatically or manually configure
           parameters such as network topology, routes, and security
           policies based on network requirements and scenarios to achieve
           flexibility and customization.

        -  Information collection: Collects and analyzes network
           performance, quality, and security indicators in real time to
           optimize and improve data express services.

        -  Network monitoring: Monitors the network in real time to detect
           and handle anomalies such as network faults, attacks, and
           leaks, ensuring data transmission security and stability.

        Operation Platform

        -  Operation platform refers to the online platform that provides
           users with one-stop data express service management and
           monitoring functions, and provides users with business
           ordering, opening, monitoring, billing and other functions.
           The operation platform can be accessed through the web or
           mobile terminal to realize the visualization and intelligence
           of the whole process of data express business.  The main
           functions include:

           o  Service order: Users can order data express services online
              on the operation platform, and select parameters such as
              data source, destination, transmission mode, and
              transmission time to generate service orders.




  Chen & Li                Expires 9 January 2025                 [Page 5]


  Internet-Draft    Transport and Services Working Group         July 2024


           o  Enabling the service: Users can enable the online data
              express service on the operation platform.  Based on the
              order information, users can automatically or manually
              configure data sources, destinations, and network resources
              to start data transfer tasks.

           o  Service monitoring: Users can monitor data express services
              online on the operation platform and view data transfer
              progress, status, rate, and quality in real time to detect
              and handle anomalies in a timely manner.

           o  Service charging: Users can charge online data express
              services on the operating platform, and generate and pay
              bills based on preset charging rules based on data transfer
              volume, duration, and bandwidth.

  3.  "One low, three high" technology system

     TBD

  4.  Summary

     TBD

  5.  Security Considerations

     TBD.

  6.  IANA Considerations

     This document has no requests to IANA.

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

  Authors' Addresses

     Danyang Chen
     China Mobile
     Beijing
     100053
     China
     Email: chendanyang@chinamobile.com




  Chen & Li                Expires 9 January 2025                 [Page 6]


  Internet-Draft    Transport and Services Working Group         July 2024


     Zhiqiang Li
     China Mobile
     Beijing
     100053
     China
     Email: lizhiqiang@chinamobile.com













































  Chen & Li                Expires 9 January 2025                 [Page 7]


name: draft-mzhang-nfsv4-recursively-setting
rev: 06
title: Recursively Setting Attributes of Subdirectories and files
time: 2025-04-16T07:05:03Z
group_uri: /api/v1/group/group/1027/
expires: 2025-04-17T02:48:27Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.410409+00:00
source: ietf
abstract:
  In the recent years, the concept of near-data computing has been
     widely recognized in storage architectures.  The core idea is to
     process data nearby, reduce the overhead of network transmission, and
     utilize the computing capability of smart devices (such as
     intelligent NICs, smart SSDs, and DPUs).  This reduces CPU and memory
     usage of clients (computing nodes) and improves data processing
     efficiency.  This design idea is applied in NFSv4.2 or future NFS
     versions, such as Server-Side Copy, in which client sends the control
     command and the storage server copies data without transmitting
     between client and server.  We are proposing a new mechanism for
     setting the attributes for all the files and directories in the
     parent directory, based on thes same thinking of the server side copy
     mechanism.  Compared with traditional setting of attributes, data
     transmission over the network is reduced and the bandwidth resources
     are greatly released.

full_text:
  Network File System Version 4                                   M. Zhang
  Internet-Draft                                       Huawei Technologies
  Intended status: Standards Track                               S. Bhargo
  Expires: 17 April 2025                                     Broadcom Inc.
                                                             R. Parambattu
                                                                   D. Geng
                                                                     Y. Du
                                                       Huawei Technologies
                                                           14 October 2024


         Recursively Setting Attributes of Subdirectories and files
                 draft-mzhang-nfsv4-recursively-setting-06

  Abstract

     In the recent years, the concept of near-data computing has been
     widely recognized in storage architectures.  The core idea is to
     process data nearby, reduce the overhead of network transmission, and
     utilize the computing capability of smart devices (such as
     intelligent NICs, smart SSDs, and DPUs).  This reduces CPU and memory
     usage of clients (computing nodes) and improves data processing
     efficiency.  This design idea is applied in NFSv4.2 or future NFS
     versions, such as Server-Side Copy, in which client sends the control
     command and the storage server copies data without transmitting
     between client and server.  We are proposing a new mechanism for
     setting the attributes for all the files and directories in the
     parent directory, based on thes same thinking of the server side copy
     mechanism.  Compared with traditional setting of attributes, data
     transmission over the network is reduced and the bandwidth resources
     are greatly released.

  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 RFC 2119 [RFC2119].

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




  Zhang, et al.             Expires 17 April 2025                 [Page 1]


  Internet-Draft       Recursively Setting Attributes         October 2024


     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 April 2025.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Implementation Considerations . . . . . . . . . . . . . . . .   6
     4.  Recursive Set Operations  . . . . . . . . . . . . . . . . . .   9
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
     Appendix A.  An Appendix  . . . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Problem Statement

     In actual storage applications, users often recursively set the
     attributes of directories and subitems(their subfiles and
     subdirectories).  Message interaction between client and server is
     complex, and the client consumes a lot of resources, which does not
     match the concept of near-data computing.  FIG. 1 sequence diagram
     shows the existing sequence of recursively setting the attributes of
     all files under directory.

     Step 1: The client sends the READDIR command to obtain the list of
     all files in dir1.




  Zhang, et al.             Expires 17 April 2025                 [Page 2]


  Internet-Draft       Recursively Setting Attributes         October 2024


     Step 2: The storage server responds to the READDIR operation.  If the
     directory contains many subdirectories and files the client needs to
     run the READDIR operation for multiple times.

     Step 3: The client sends a SETATTR request for each subdirectory and
     file.

     Step 4: The storage server responds to the SETATTR request.

     If the parent directory contains 100,000 files, the client needs to
     repeat step 3 and 4 for 100,000 files.  The whole process consumes
     more CPU resources and memory resources of the client, and a large
     number of RPC messages are exchanged between the client and the
     storage server.  As a result, an end-to-end time for the attribute
     set operation is relatively long.

     preamble to the figure.


                      Client                                Server
                      +                                       +
                      |                                       |
                      |------ READDIR ----------------------->|
                      |<--------------------------------------|
                      |------ GETATTR ----------------------->|
                      |<--------------------------------------|
                      |------ SETATTR ----------------------->|
                      |<--------------------------------------|
                      |         ....                          |
                      |                                       |

            Figure 1: Existing flowchart for recursive set operation

     As you can see, this figure doodled and dawdled.

     Similar to the design of Server-Side Copy, in this proposal we
     propose four new operations to be used to recursively set the
     attributes of a directory and its subdirectories and subfiles.  These
     operations can be in synchronous or asynchronous mode.  These four
     new operations are RECURSIVE_SET, RECURSIVE_SET_STATUS,
     RECURSIVE_SET_CANCEL and CB_RECURSIVE_SET_NOTIFY.

     RECURSIVE_SET is used by client to request setting of attributes of
     the directories and files.

     RECURSIVE_SET_STATUS is used by client to query the status of the
     recursively set operation requested by operation RECURSIVE_SET.




  Zhang, et al.             Expires 17 April 2025                 [Page 3]


  Internet-Draft       Recursively Setting Attributes         October 2024


     RECURSIVE_SET_CANCEL is used by client to cancel the recursively set
     operation.

     CB_RECURSIVE_SET_NOTIFY is used by server to notify client that the
     recursively set operation finished.  This operation is used only in
     asynchronous mode.

  2.  Protocol Overview

     In the proposed new mechanism, client has the option of using
     RECURSIVE_SET in synchronous or asynchronous mode.  The server has a
     concept of initial timeout for synchronous mode, which is recommended
     to be 1/3 of lease time.

     After adopting the concept of near data calculation, the above
     scenario can be optimized.

     Step 1: The client identifies that the object of the attribute
     setting is a directory and the attribute setting is recursive, and
     invokes the new operation RECURSIVE_SET in compound request, e.g.

     Compound request:

     SEQUENCE

     PUTFH (directory filehandle)

     RECURSIVE_SET

     SETATTR

     RECURSIVE_SET_STATUS

     Step 2: The storage server receives the compound request with
     RECURSIVE_SET operation before SETATTR, server identifies the
     filehandle as a directory filehandle create a recursively set task
     and start recursively querying all files in the directory, sets
     attributes for each file or directory.  If filehandle refers to a
     regular file, server SHOULD return NFS4ERR_NOTDIR.

     Step 3: The storage server responds to the request once the recursive
     set operation completes setting attributes of all subdirectories and
     files.  RECURSIVE_SET can be one of the two types either synchronous
     or asynchronous.

     If client choose synchronous RECURSIVE_SET, server must respond to
     the client, once server finishes the operation.  If the server fails
     to complete the attribute set within the timeout, the server responds



  Zhang, et al.             Expires 17 April 2025                 [Page 4]


  Internet-Draft       Recursively Setting Attributes         October 2024


     to the client with the error code NFS4ERR_PENDING, with recursive
     task id and verifier to the client.Client queries the result
     periodically till the operation is completed on server side.

     If client choose asynchronous setting, server will immediately return
     the error code NFS4ERR_PENDING for RECURSIVE_SET_STATUS operation
     with recursive task id and verifier to the client and client will
     start an observer task to monitor the server.  Server will send
     callback operation CB_RECURSIVE_SET_NOTIFY to the client once server
     finishes RECURSIVE_SET operation.  Client will terminate the observer
     task once client receives the callback notification from server.

     Compared to the original iterative process, the proposed process not
     only saves the CPU and memory usage of the client, but also
     significantly reduces the number of RPC’s exchanged between the
     client and server.  This greatly improves the performance of setting
     attributes in subdirectories and files.

     o If no backchannel is created when the client and server establish a
     connection, the client can only use the synchronous mode in the
     RECURSIVE_SET request.  If the client uses the asynchronous mode, the
     server returns the error code NFS4ERR_CB_PATH_DOWN.

     o If a backchannel is already established the client can choose to
     use synchronous or asynchronous mode.

     Server reboot

     When server reboot, the client will get NFS4ERR_BADSESSION.  Client
     SHOULD retry the RECURSIVE_SET operation after re-establishing the
     Clientid and after RECLAIM_COMPLETE procedure.

     Client Lease Expiry

     If the client sends the RECURSIVE_SET operation and later there is a
     network disruption between the client and server, the client lease
     may expire.  After the lease expiration the server will terminate the
     RECURSIVE_SET operation, which might result in partially modified
     files/directories under the parent directory on which the
     RECURSIVE_SET operation was executed.

     RECURSIVE_SET operation is tied to specific client instance, so if
     the client lease has expired the server should cancel the
     RECURSIVE_SET operation.  In case of there are huge number of files
     need to be set attributes, the server can determine the timeout but
     the timeout must be lesser than lease time.

     Backchannel Consideration



  Zhang, et al.             Expires 17 April 2025                 [Page 5]


  Internet-Draft       Recursively Setting Attributes         October 2024


     Before client initiate the RECURSIVE_SET operation to the server, the
     client MUST check if the client has a backchannel established with
     the server.  If there is no backchannel then client MUST use only
     synchronous RECURSIVE_SET operation.  If there is an existing
     backchannel then the client can use either synchronous or
     asynchronous RECURSIVE_SET operationrecursively setting.  If the
     server wants to send a callback operation over the backchannel of a
     session and no backchannel exists for the session, the server cannot
     establish the backchannel because only the client can associate
     connections with the backchannel.  If there is no such connection,
     the server indicate that the session has no backchannel by setting
     the SEQ4_STATUS_CB_PATH_DOWN_SESSION flag bit in the response to the
     next SEQUENCE operation from the client.  The client then associate a
     connection with the session.

     Grace Consideration

     RECURSIVE_SET operation must honor the server grace time.  During
     server grace period, server should send NFS4ERR_GRACE to the client
     and the client should retry the request till the grace period is
     over.

     Position Consideration

     RECURSIVE_SET operation MUST not be the first operation of the
     compound request and compound operation containing the RECURSIVE_SET
     op should always have the SEQUENCE as the first operation.

     Note to RFC Editor: this section may be removed on publication as an
     RFC.

  3.  Implementation Considerations

     A recommended Recursive Set operation in synchronous mode is shown in
     Figure 2.

     Step 1: The client sends a RECURSIVE_SET request.  In the request,
     rsa_sync must be set to true.

     Step 2: If the storage server completes to recursively set the
     attributes within the timeout period, the storage server returns the
     result back to the client.  If the attributes are not set within the
     timeout period, the server must generate rsr_callback_id and
     rsr_recursiveverf and return back to client.  In addition, server
     must respond the client with NFS4ERR_PENDING.






  Zhang, et al.             Expires 17 April 2025                 [Page 6]


  Internet-Draft       Recursively Setting Attributes         October 2024


     Step 3: The client sends a RECURSIVE_SET_STATUS query request.  The
     request contains the information of rss_recursive_taskid.  The value
     of rss_recursive_taskid should be set to rsr_callback_id which is
     obtained from the response of RECURSIVE_SET operation if the value of
     rss_recursive_taskid is the same as the value of rsr_callback_id
     cached on the storage server, the storage server returns the current
     status of the attribute set operation.  Storage server return NFS4_OK
     if the server has set all the attributes, or NFS4ERR_PENDING if the
     operation is still in progress.  If the server has encountered error
     during the attribute setting, then the result code must be cached and
     must be set in the response.  If the value of rss_recursive_taskid in
     the request is different from the value cached on the server, the
     storage server returns the error code NFS4ERR_INVAL.

     Step 4: The client decodes the response.  If the response is
     NFS4_PENDING, the client would retry the RECURSIVE_SET_STATUS
     operation again, after a delay period.  If the error code returned by
     the server is NFS4_OK, the recursive attribute setting is successful.
     If SETATTR operation has encountered an error, the recursive
     attribute setting fails.  In this case, the client returns a response
     to the application.

     preamble to the figure.


                   Client                                                     Server
                   +                                                             +
                   |                                                             |
                   |------ RECURSIVE_SET(rsa_sync = 1) ------------------------> |
                   |                                                             |
                   |<-----Response(rsr_callback_id = 0, rsr_recursiveverf = 0)---|  within the timeout period
                   |                                                             |
                   |                                                             |
                   |<----Response(rsr_callback_id = 1, rsr_recursiveverf = 1)----|  beyond the timeout period
                   |                                                             |
                   |                                                             |
                   |                                                             |
                   |-------RECURSIVE_SET_STATUS(rss_recursive_taskid = 1)------> |
                   |                                                             |
                   |<------Response--------------------------------------------- |
                   |                                                             |
                   |                                                             |

                             Figure 2:  A synchronous Recursive Set

     As you can see, this figure doodled and dawdled.





  Zhang, et al.             Expires 17 April 2025                 [Page 7]


  Internet-Draft       Recursively Setting Attributes         October 2024


     An alternative Recursive Set operation in asynchronous mode is also
     given in Figure 3.

     Step 1: The client sends a RECURSIVE_SET request.  In the request,
     rsa_sync flag should be set to false.

     Step 2: The storage server needs to generate rsr_callback_id and
     rsr_recursiveverf, and set the error code to NFS4ERR_PENDING.  The
     storage server continue executing the recursive setting operation.

     Step 3: After receiving the response, and if the error code is
     NFS4ERR_PENDING, the client starts an asynchronous task to monitor
     the progress of RECURSIVE_SET.

     Step 4: The client waits an asynchronous message from the server and
     matches rsr_callback_id and rsr_recursiveverf.  Client matches
     rsr_callback_id and rsr_recursiveverf in CB_RECURSIVE_SET_NOTIFY, and
     if both the parameters match then the response is a valid response.
     If rsr_callback_id can be matched but rsr_recursiveverf cannot be
     matched, client skip the message.

     Step 5: If the client does not receive the asynchronous message, the
     asynchronous task is forcibly terminated when the session is
     destroyed.

     If an error occurs when the storage server recursively set attributes
     of subdirectories and files, the storage server terminates the task
     and returns the error code to the client.  All possible errors are
     subject to the error codes defined by SETATTR.

     preamble to the figure.




















  Zhang, et al.             Expires 17 April 2025                 [Page 8]


  Internet-Draft       Recursively Setting Attributes         October 2024


                   Client                                                     Server
                   +                                                             +
                   |                                                             |
                   |------ RECURSIVE_SET(rsa_sync = 0) ------------------------->|
                   |                                                             |
                   |<------Response(rsr_callback_id = 1, rsr_recursiveverf = 1)--|
                   |                                                             |
                   |                                                             |
                   |<------CB_RECURSIVE_SET_NOTIFY-------------------------------|
                   |                                                             |
                   |                                                             |
                   |                                                             |

                              Figure 3: An asynchronous Recursive Set

     As you can see, this figure doodled and dawdled.

  4.  Recursive Set Operations

     4.1 Operation TBD1: RECURSIVE_SET – Recursively sets the attributes
     of a directory and its subdirectories and files.

     ARGUMENT

     Struct RECURSIVE_SET4args {

     bool rsa_sync;

     };

     RESULT

     struct recursive_set_response4 {

     recursive_taskid4 rsr_callback_id;

     verifier4 rsr_recursiveverf;

     };

     union RECURSIVE_SET4res (nfsstat4 rsr_status) {

     case NFS4_OK:

     recursive_set_response4 rsr_resok4;

     default:




  Zhang, et al.             Expires 17 April 2025                 [Page 9]


  Internet-Draft       Recursively Setting Attributes         October 2024


     void;

     };

     DESCRIPTION

     The RECURSIVE_SET operation is used by the client to recursively set
     the attributes of a directory and all its subdirectories and files.
     The operation should be placed before SETATTR in the compound
     operation.  After the storage server receives the SETATTR combination
     operation, if the SETATTR operation is not preceded by RECURSIVE_SET,
     the original process remains unchanged.  If the SETATTR operator is
     preceded by the RECURSIVE_SET operation, the storage server considers
     the attributes of the directory and its subdirectories and files to
     initiate recursive set mode.

     If the storage is successfully executed, the values of
     rsr_callback_id and rsr_recursiveverf are 0.

     If the recursive SETATTR operation in storage is not complete within
     the timeout period, the values of rsr_callback_id and
     rsr_recursiveverf are generated.

     If rsa_sync is set to true, then client can choose one of the below
     implementation.

     1.  After the client receives the response for RECURSIVE_SET as
     NFS4ERR_PENDING, the client waits for a period of time and executes
     RECURSIVE_SET_STATUS to query the execution progress of the current
     task.  If the recursive attribute setting is still in progress,
     NFS4ERR_PENDING is returned.  The recommended period of time can be
     set half the lease time.  The client continuous to poll till the
     client receives CB_RECURSIVE_SET_NOTIFY from server or NFS4ERR_OK for
     the RECURSIVE_SET_STATUS request.

     2.  The client can choose to wait for the CB_RECURSIVE_SET_NOTIFY
     from the server to know if the recursive set of attributes are
     completed.

     4.2 Operation TBD2: RECURSIVE_SET_STATUS – Query the result of the
     recursively setting the attributes of subdirectories and files

     ARGUMENT

     struct RECURSIVE_SET_STATUS4args {

     stateid4 rssa_recursive_taskid;




  Zhang, et al.             Expires 17 April 2025                [Page 10]


  Internet-Draft       Recursively Setting Attributes         October 2024


     };

     RESULT

     #define NFS4ERR_PENDING 10090

     struct RECURSIVE_SET_STATUS4res {

     nfsstat4 rssr_status;

     };

     DESCRIPTION

     rssa_recursive_taskid is the value same to rsr_callback_id in
     RECURSIVE_SET response.  The RECURSIVE_SET_STATUS operation is used
     by the client to query the status of a recursively set task
     (attributes of subdirectories and files).  Server must check if
     rssa_recursive_taskid match the task id in server and if the task on
     the storage server is complete, NFS4_OK is returned.  If any error
     occurs during task execution, a response error code is returned and
     the error code is not extended or modified in this case so the error
     code is the same as the error code that may occur during the SETATTR
     operation.  If the current setting task is not complete, NFS4_PENDING
     is returned.

     4.3 Operation TBD3: RECURSIVE_SET_CANCEL – Canceling a Running Task
     on the Client

     ARGUMENT

     struct RECURSIVE_SET_CANCEL4args {

     stateid4 rsca_recursive_taskid;

     };

     RESULT

     struct RECURSIVE_SET_CANCEL4res {

     nfsstat4 rscr_status;

     };

     DESCRIPTION





  Zhang, et al.             Expires 17 April 2025                [Page 11]


  Internet-Draft       Recursively Setting Attributes         October 2024


     RECURSIVE_SET_CANCEL is used to cancel the task that is being
     executed.  The request packet contains rsca_recursive_taskid.  The
     value of rsca_recursive_taskid is obtained from the response of
     RECURSIVE_SET.  If the storage server fails to cancel the task,
     NFS4ERR_DELAY is returned.  When receiving the message, the client
     delays the retry.  If the current task is complete, NFS4_OK is
     returned.

     4.4 Operation TBD4: CB_RECURSIVE_SET_NOTIFY – Notify the recursively
     setting result to client

     ARGUMENT

     struct CB_RECURSIVE_SET_NOTIFY4args {

     nfs_fh4 crsna_fh;

     stateid4 crsna_recursive_taskid;

     verifier4 crsna_recursiveverf;

     nfsstat4 crsna_status;

     };

     RESULT

     struct CB_RECURSIVE_SET_NOTIFY4res {

     nfsstat4 crsnr_status;

     };

     DESCRIPTION

     CB_RECURSIVE_SET_NOTIFY is used to send the server callback to client
     to notify the client of the result of the task of recursively setting
     the attributes of subdirectories and files.  Client check the
     crsna_recursive_taskid and crsna_recursiveverf and client will finish
     the wait task if arguments match the value received from previous
     RECURSIVE_SET response or will skip the notification in case of not
     match and return NFS4ERR_INVAL to server.









  Zhang, et al.             Expires 17 April 2025                [Page 12]


  Internet-Draft       Recursively Setting Attributes         October 2024


     Race condition between CB_RECURSIVE_SET_NOTIFY and
     RECURSIVE_SET_STATUS.  A race condition can happen if the
     RECURSIVE_SET_STATUS is in flight and server has responded with
     CB_RECURSIVE_SET_NOTIFY.  In this case the server would have cleaned
     up the recursive_taskid before the RECURSIVE_SET_STATUS is received
     from client.  The server may return NFS4ERR_INVAL, and this should be
     gracefully handled by the client.

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     TBD

  7.  References

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

     [RFC7862]  Haynes, T., "Network File System (NFS) Version 4 Minor
                Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
                November 2016, <https://www.rfc-editor.org/info/rfc7862>.

  7.2.  Informative References

     [InfRef]   "", 2004.

  Appendix A.  An Appendix


  Authors' Addresses

     Minqian Zhang
     Huawei Technologies
     1899 Xiyuan
     Chengdu
     High-tech West District, 611731
     China
     Phone: +86-13547833949
     Email: zhangmingqian.zhang@huawei.com





  Zhang, et al.             Expires 17 April 2025                [Page 13]


  Internet-Draft       Recursively Setting Attributes         October 2024


     Sunil Kumar Bhargo
     Broadcom Inc.
     Phone: +
     Email: sunil.bhargo@broadcom.com


     Rijesh Kunhi Parambattu
     Huawei Technologies
     Email: rijesh.kunhi.parambattu1@huawei.com


     Dongyu Geng
     Huawei Technologies
     Email: gengdongyu@huawei.com


     Yunfei Du
     Huawei Technologies
     Email: duyunfei1@huawei.com
































  Zhang, et al.             Expires 17 April 2025                [Page 14]


name: draft-pan-tsvwg-pie
rev: 00
title: PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem
time: 2024-09-24T23:12:03Z
group_uri: /api/v1/group/group/1324/
expires: 2013-06-13T18:15:15Z
ad: /api/v1/person/person/105519/
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.415212+00:00
source: ietf
abstract:
  Bufferbloat is a phenomenon where excess buffers in the network cause
     high latency and jitter. As more and more interactive applications
     (e.g. voice over IP, real time video streaming and financial
     transactions) run in the Internet, high latency and jitter degrade
     application performance. There is a pressing need to design
     intelligent queue management schemes that can control latency and
     jitter; and hence provide desirable quality of service to users.

     We present here a lightweight design, PIE(Proportional Integral
     controller Enhanced) that can effectively control the average
     queueing latency to a target value. Simulation results, theoretical
     analysis and Linux testbed results have shown that PIE can ensure low
     latency and achieve high link utilization under various congestion
     situations. The design does not require per-packet timestamp, so it
     incurs very small overhead and is simple enough to implement in both
     hardware and software.

full_text:
   



  Internet Draft                                                    R. Pan
  Network Working Group                P. Natarajan, C. Piglione,M. Prabhu
  Intended Status: Informational     V. Subramanian, F. Baker, B. V. Steeg
                                                             Cisco Systems

  Expires: June 2, 2013                                  December 10, 2012


             PIE: A Lightweight Control Scheme To Address the 
                            Bufferbloat Problem 

  		      draft-pan-tsvwg-pie-00


  Abstract

     Bufferbloat is a phenomenon where excess buffers in the network cause
     high latency and jitter. As more and more interactive applications
     (e.g. voice over IP, real time video streaming and financial
     transactions) run in the Internet, high latency and jitter degrade
     application performance. There is a pressing need to design
     intelligent queue management schemes that can control latency and
     jitter; and hence provide desirable quality of service to users. 

     We present here a lightweight design, PIE(Proportional Integral
     controller Enhanced) that can effectively control the average
     queueing latency to a target value. Simulation results, theoretical
     analysis and Linux testbed results have shown that PIE can ensure low
     latency and achieve high link utilization under various congestion
     situations. The design does not require per-packet timestamp, so it
     incurs very small overhead and is simple enough to implement in both
     hardware and software. 

  Status of this Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

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

   


  Pan et al.               Expires April 17, 2013                 [Page 1]


  INTERNET DRAFT                    PIE                  December 10, 2012


     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html


  Copyright and License Notice

     Copyright (c) 2012 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
     (http://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 Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.



  Table of Contents

     1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3. Design Goals  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4. The PIE Scheme  . . . . . . . . . . . . . . . . . . . . . . . .  5
       4.1 Random Dropping  . . . . . . . . . . . . . . . . . . . . . .  5
       4.2 Drop Probability Calculation . . . . . . . . . . . . . . . .  6
       4.3 Departure Rate Estimation  . . . . . . . . . . . . . . . . .  7
       4.4 Handling Bursts  . . . . . . . . . . . . . . . . . . . . . .  8
     5. Comments and Discussions  . . . . . . . . . . . . . . . . . . .  9
     6. Incremental Deployment  . . . . . . . . . . . . . . . . . . . . 10
     7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
     8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       8.1  Normative References  . . . . . . . . . . . . . . . . . . . 10
       8.2  Informative References  . . . . . . . . . . . . . . . . . . 10
       8.3  Other References  . . . . . . . . . . . . . . . . . . . . . 10
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11






   


  Pan et al.               Expires April 17, 2013                 [Page 2]


  INTERNET DRAFT                    PIE                  December 10, 2012


  1. Introduction

     The explosion of smart phones, tablets and video traffic in the
     Internet brings about a unique set of challenges for congestion
     control. To avoid packet drops, many service providers or data center
     operators require vendors to put in as much buffer as possible. With
     rapid decrease in memory chip prices, these requests are easily
     accommodated to keep customers happy. However, the above solution of
     large buffer fails to take into account the nature of the TCP
     protocol, the dominant transport protocol running in the Internet.
     The TCP protocol continuously increases its sending rate and causes
     network buffers to fill up. TCP cuts its rate only when it receives a
     packet drop or mark that is interpreted as a congestion signal.
     However, drops and marks usually occur when network buffers are full
     or almost full. As a result, excess buffers, initially designed to
     avoid packet drops, would lead to highly elevated queueing latency
     and jitter. It is a delicate balancing act to design a queue
     management scheme that not only allows short-term burst to smoothly
     pass, but also controls the average latency when long-term congestion
     persists.

     Active queue management (AQM) schemes, such as Random Early Discard
     (RED), have been around for well over a decade. AQM schemes could
     potentially solve the aforementioned problem. RFC 2309[RFC2309]
     strongly recommends the adoption of AQM schemes in the network to
     improve the performance of the Internet. RED is implemented in a wide
     variety of network devices, both in hardware and software. 
     Unfortunately, due to the fact that RED needs careful tuning of its
     parameters for various network conditions, most network operators
     don't turn RED on. In addition, RED is designed to control the queue
     length which would affect delay implicitly. It does not control
     latency directly. Hence, the Internet today still lacks an effective
     design that can control buffer latency to improve the quality of
     experience to latency-sensitive applications. 

     Recently, a new AQM scheme, CoDel[CoDel],  was proposed to control
     the latency directly to address the bufferbloat problem. CoDel
     requires per packet timestamps. Also, packets are dropped at the
     dequeue function after they have been enqueued for a while. Both of
     these requirements consume excessive processing and infrastructure
     resources. This consumption will make CoDel expensive to implement
     and operate, especially in hardware. 

     PIE aims to combine the benefits of both RED and CoDel: easy to
     implement like RED and directly control latency like CoDel. Similar
     to RED, PIE randomly drops a packet at the onset of the congestion.
     The congestion detection, however, is based on the queueing latency
     like CoDel instead of the queue length like RED. Furthermore, PIE
   


  Pan et al.               Expires April 17, 2013                 [Page 3]


  INTERNET DRAFT                    PIE                  December 10, 2012


     also uses the latency moving trends: latency increasing or
     decreasing, to help determine congestion levels. The design
     parameters of PIE are chosen via stability analysis. While these
     parameters can be fixed to work in various traffic conditions, they
     could be made self-tuning to optimize system performance. 

     In addition, we assume any delay-based AQM scheme would be applied
     over a Fair Queueing (FQ) structure or its approximate design, Class
     Based Queueing (CBQ). FQ is one of the most studied scheduling
     algorithms since it was first proposed in 1985 [RFC970]. CBQ has been
     a standard feature in most network devices today[CBQ]. These designs
     help flows/classes achieve max-min fairness and help mitigate bias
     against long flows with long round trip times(RTT). Any AQM scheme
     that is built on top of FQ or CBQ could benefit from these
     advantages. Furthermore, we believe that these advantages such as per
     flow/class fairness are orthogonal to the AQM design whose primary
     goal is to control latency for a given queue. For flows that are
     classified into the same class and put into the same queue, we need
     to ensure their latency is better controlled and their fairness is
     not worse than those under the standard DropTail or RED design.  

     This draft describes the overall design goals, system elements and
     implementation details of PIE. We will also discuss various design
     considerations, including how auto-tuning can be done. 




  2. Terminology

     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 RFC 2119 [RFC2119].


  3. Design Goals

     We explore a queue management framework where we aim to improve the
     performance of interactive and delay-sensitive applications. The
     design of our scheme follows a few basic criteria.  

          * First, we directly control queueing latency instead of
          controlling queue length. Queue sizes change with queue draining
          rates and various flows' round trip times. Delay bloat is the
          real issue that we need to address as it impairs real time
          applications. If latency can be controlled, bufferbloat is not
          an issue. As a matter of fact, we would allow more buffers for
          sporadic bursts as long as the latency is under control. 
   


  Pan et al.               Expires April 17, 2013                 [Page 4]


  INTERNET DRAFT                    PIE                  December 10, 2012


          * Secondly, we aim to attain high link utilization. The goal of
          low latency shall be achieved without suffering link under-
          utilization or losing network efficiency. An early congestion
          signal could cause TCP to back off and avoid queue building up.
          On the other hand, however, TCP's rate reduction could result in
          link udner-utilization. There is a delicate balance between
          achieving high link utilization and low latency.

          * Furthermore, the scheme should be simple to implement and
          easily scalable in both hardware and software. The wide adoption
          of RED over a variety of network devices is a testament to the
          power of simple random early dropping/marking. We strive to
          maintain similar design simplicity. 

          * Finally, the scheme should ensure system stability for various
          network topologies and scale well with arbitrary number streams.
          Design parameters shall be set automatically. Users only need to
          set performance-related parameters such as target queue delay,
          not design parameters. 

  In the following, we will elaborate on the design of PIE and its
  operation.

  4. The PIE Scheme

  As illustrated in Fig. 1, our scheme comprises three simple components:
  a) random dropping at enqueuing; b) periodic drop probability update; c)
  dequeuing rate estimation.

  The following sections describe these components in further detail, and
  explain how they interact with each other.  At the end of this section,
  we will discuss how the scheme can be easily augmented to precisely
  control bursts. 


  4.1 Random Dropping

  Like any state-of-the-art AQM scheme, PIE would drop packets randomly
  according to a drop probability, p, that is obtained from the drop-
  probability-calculation component:

      * upon a packet arrival

          randomly drop a packet with a probability p.




   


  Pan et al.               Expires April 17, 2013                 [Page 5]


  INTERNET DRAFT                    PIE                  December 10, 2012


           Random Drop 
               /               --------------
       -------/  -------------->    | | | | | -------------->     
              /|\                   | | | | |         |
               |               --------------         |
               |                 Queue Buffer         |
               |                     |                | Departure bytes
               |                     |queue           |
               |                     |length          | 
               |                     |                |
               |                    \|/              \|/
               |          -----------------    -------------------
               |          |     Drop      |    |                 |
               -----<-----|  Probability  |<---| Departure Rate  | 
                          |  Calculation  |    | Estimation      |
                          -----------------    ------------------- 



                        Figure 1. The PIE Structure




  4.2 Drop Probability Calculation

  The PIE algorithm periodically updates the drop probability as follows: 

      * estimate current queueing delay using Little's law:

          est_del = qlen/depart_rate; 


      * calculate drop probability p as: 

          p = p + alpha*(est_del-target_del) + beta*(est_del-est_del_old);

          est_del_old = est_del. 


  Here, the current queue length is denoted by qlen. The draining rate of
  the queue, depart_rate, is obtained from the departure-rate-estimation
  block.  Variables, est_del and est_del_old, represent the current and
  previous estimation of the queueing delay. The target latency value is
  expressed in target_del.  The update interval is denoted as Tupdate. 

  Note that the calculation of drop probability is based not only on the
  current estimation of the queueing delay, but also on the direction
   


  Pan et al.               Expires April 17, 2013                 [Page 6]


  INTERNET DRAFT                    PIE                  December 10, 2012


  where the delay is moving, i.e., whether the delay is getting longer or
  shorter. This direction can simply be measured as the difference between
  est_del and est_del_old. This is the classic Proportional Integral
  controller design that is adopted here for controlling queueing latency.
  The controller parameters, in the unit of hz, are designed using
  feedback loop analysis where TCP's behaviors are modeled using the
  results from well-studied prior art[TCP-Models]. 

  We would like to point out that this type of controller has been studied
  before for controlling the queue length [PI, QCN]. PIE adopts the
  Proportional Integral controller for controlling delay and makes the
  scheme auto-tuning. The theoretical analysis of PIE is under paper
  submission and its reference will be included in this draft once it
  becomes available. Nonetheless, we will discuss the intuitions for these
  parameters in Section 5.


  4.3 Departure Rate Estimation

  The draining rate of a queue in the network often varies either because
  other queues are sharing the same link, or the link capacity fluctuates.
  Rate fluctuation is particularly common in wireless networks. Hence, we
  decide to measure the departure rate directly as follows. 


      * we are in a measurement cycle if we have enough data in the queue:

          qlen > deq_threshold


      * if in a measurement cycle:

          upon a packet departure 

          dq_count = dq_count + deque_pkt_size;


      * if dq_count > deq_threshold then 


          depart_rate = dq_count/(now-start);

          dq_count = 0;

          start = now; 


  We only measure the departure rate when there are sufficient data in the
   


  Pan et al.               Expires April 17, 2013                 [Page 7]


  INTERNET DRAFT                    PIE                  December 10, 2012


  buffer, i.e., when the queue length is over a certain threshold,
  dq_threshold. Short, non-persistent bursts of packets result in empty
  queues from time to time, this would make the measurement less accurate.
  The parameter, dq_count, represents the number of bytes departed since
  the last measurement. Once dq_count is over a certain threshold,
  deq_threshold, we obtain a measurement sample. The threshold is
  recommended to be set to 10KB assuming a typical packet size of around
  1KB or 1.5KB. This threshold would allow us a long enough period to
  obtain an average draining rate but also fast enough to reflect sudden
  changes in the draining rate. Note that this threshold is not crucial
  for the system's stability. 



  4.4 Handling Bursts 

  The above three components form the basis of the PIE algorithm. Although
  we aim to control the average latency of a congested queue, the scheme
  should allow short term bursts to pass through the system without
  hurting them. We would like to discuss how PIE manages bursts in this
  section.

  Bursts are well tolerated in the basic scheme for the following reasons:
  first, the drop probability is updated periodically. Any short term
  burst that occurs within this period could pass through without
  incurring extra drops as it would not trigger a new drop probability
  calculation. Secondly, PIE's drop probability calculation is done
  incrementally. A single update would only lead to a small incremental
  change in the probability. So if it happens that a burst does occur at
  the exact instant that the probability is being calculated, the
  incremental nature of the calculation would ensure its impact is kept
  small.

  Nonetheless, we would like to give users a precise control of the burst.
  We introduce a parameter, max_burst, that is similar to the burst
  tolerance in the token bucket design. By default, the parameter is set
  to be 100ms. Users can certainly modify it according to their
  application scenarios. The burst allowance is added into the basic PIE
  design as follows:

      * if p == 0 and est_del < del_ref and est_del_old < del_ref

          burst_allowance = max_burst;

      * upon packet arrival

          if burst_allowance > 0 enqueue packet;

   


  Pan et al.               Expires April 17, 2013                 [Page 8]


  INTERNET DRAFT                    PIE                  December 10, 2012


      * upon probability update

          burst_allowance = burst_allowance - Tupdate;



  The burst allowance, noted by burst_allowance, is initialized to
  max_burst. As long as burst_allowance is above zero, an incoming packet
  will be enqueued bypassing the random drop process. During each update
  instance, the value of burst_allowance is decremented by the update
  period, Tupdate. When the congestion goes away, defined by us as p
  equals to 0 and both the current and previous samples of estimated delay
  are less than target_del, we reset burst_allowance to max_burst. 	

  5. Comments and Discussions

  While the formal analysis will be included later, we would like to
  discuss the intuitions regarding how to determine the key parameters.
  Although the PIE algorithm would set them automatically, they are not
  meant to be magic numbers. We hope to give enough explanations here to
  help demystify them so that users can experiment and explore on their
  own.

  As it is obvious from the above, the crucial equation in the PIE
  algorithm is

       p = p + alpha*(est_del-target_del) + beta*(est_del-est_del_old). 

  The value of alpha determines how the deviation of current latency from
  the target value affects the drop probability.  The beta term exerts
  additional adjustments depending on whether the latency is trending up
  or down. Note that the drop probability is reached incrementally, not
  through a single step. To avoid big swings in adjustments which often
  leads to instability, we would like to tune p in small increments.
  Suppose that p is in the range of 1%. Then we would want the value of
  alpha and beta to be small enough, say 0.1%, adjustment in each step. If
  p is in the higher range, say above 10%, then the situation would
  warrant a higher single step tuning, for example 1%. Finally, the drop
  probability would only be stabilized when the latency is stable, i.e.
  est_del equals est_del_old; and the value of the latency is equal to
  target_del. The relative weight between alpha and beta determines the
  final balance between latency offset and latency jitter. 

  The update interval, Tupdate, also plays a key role in stability. Given
  the same alpha and beta values, the faster the update is, the higher the
  loop gain will be. As it is not showing explicitly in the above
  equation, it can become an oversight. Notice also that alpha and beta
  have a unit of hz. 
   


  Pan et al.               Expires April 17, 2013                 [Page 9]


  INTERNET DRAFT                    PIE                  December 10, 2012


  As a further extension, we could introduce weights for flows that are
  classified into the same queue to achieve differential dropping. For
  example, the dropping probability for flow i could be p(i) =
  p/weight(i). Flows with higher weights would receive proportionally less
  drops; and vice versa. Adding FQ on top, FQ_PIE, is another alternative.

  Also, we have discussed congestion notification via the form of packet
  drops. The algorithm can be easily applied to networks codes where Early
  Congestion Notification (ECN) is enabled. The drop probability, p, above
  would become marking probability. 

  6. Incremental Deployment

  One nice property of the AQM design is that it can be independently
  designed and operated without the requirement of being inter-operable. 

  Although all network nodes can not be changed altogether to adopt
  latency-based AQM schemes, we envision a gradual adoption which would
  eventually lead to end-to-end low latency service for real time
  applications.  

  7. IANA Considerations

  There are no actions for IANA.

  8. References

  8.1  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.


  8.2  Informative References

     [RFC970]   Nagle, J., "On Packet Switches With Infinite
                Storage",RFC970, December 1985.



  8.3  Other References

     [CoDel]    	Nichols, K., Jacobson, V., "Controlling Queue Delay", ACM
                    Queue. ACM Publishing. doi:10.1145/2209249.22W.09264.

     [CBQ]      	Cisco White Paper, "http://www.cisco.com/en/US/docs/12_0t
                    /12_0tfeature/guide/cbwfq.html". 

   


  Pan et al.               Expires April 17, 2013                [Page 10]


  INTERNET DRAFT                    PIE                  December 10, 2012


     [TCP-Models] 	Misra, V., Gong, W., and Towsley, D., "Fluid-based 	   
                    Analysis of a Network of AQM Routers Supporting TCP   
                    Flows with an Application to RED", SIGCOMM 2000.

     [PI]		Hollot, C.V., Misra, V., Towsley, D. and Gong, W.,
     		"On Designing Improved Controller for AQM Routers
     		Supporting TCP Flows", Infocom 2001.

     [QCN]		"Data Center Bridging - Congestion Notification",
     		http://www.ieee802.org/1/pages/802.1au.html.


  Authors' Addresses



     Rong Pan
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: ropan@cisco.com

     Preethi Natarajan, 
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: prenatar@cisco.com

     Chiara Piglione
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: cpiglion@cisco.com

     Mythili Prabhu
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: mysuryan@cisco.com

     Vijay Subramanian
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: vijaynsu@cisco.com

     Fred Baker
     Cisco Systems
   


  Pan et al.               Expires April 17, 2013                [Page 11]


  INTERNET DRAFT                    PIE                  December 10, 2012


     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: fred@cisco.com

     Bill Ver Steeg
     Cisco Systems
     5030 Sugarloaf Parkway 
     Lawrenceville, GA, 30044, USA
     Email: versteb@cisco.com










































  Pan et al.               Expires April 17, 2013                [Page 12]


name: draft-wang-data-transmission-security-irii
rev: 07
title: Data Transmission Security of Identity Resolution in Industrial Internet
time: 2025-11-22T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2025-11-22T05:39:41Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.419993+00:00
source: ietf
abstract:
  This draft examines data transmission security in Industrial Internet
     identity resolution systems.  As pivotal infrastructure enabling
     secure cross-organizational sharing and intelligent correlation of
     heterogeneous data, these systems require robust security services
     during resolution processes.  The analysis focuses on essential
     protective measures for identity resolution operations.

full_text:
  Internet Engineering Task Force                             B. Wang, Ed.
  Internet-Draft                                               K. Lin, Ed.
  Intended status: Standards Track                               Hikvision
  Expires: 22 November 2025                                   C. Wang, Ed.
                                                                  IIE, CAS
                                                              X. Wang, Ed.
                                                                 Hikvision
                                                             H.N. Yan, Ed.
                                                         Xidian University
                                                             Y.H. Xie, Ed.
                                                                 Hikvision
                                                               21 May 2025


  Data Transmission Security of Identity Resolution in Industrial Internet
               draft-wang-data-transmission-security-irii-07

  Abstract

     This draft examines data transmission security in Industrial Internet
     identity resolution systems.  As pivotal infrastructure enabling
     secure cross-organizational sharing and intelligent correlation of
     heterogeneous data, these systems require robust security services
     during resolution processes.  The analysis focuses on essential
     protective measures for identity resolution 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 22 November 2025.

  Copyright Notice

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




  Wang, et al.            Expires 22 November 2025                [Page 1]


  Internet-Draft      Data Transmission Security of IR            May 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
       3.1.  International Root Node . . . . . . . . . . . . . . . . .   3
       3.2.  National Root Node  . . . . . . . . . . . . . . . . . . .   4
       3.3.  Secondary Node  . . . . . . . . . . . . . . . . . . . . .   4
       3.4.  Enterprise Node . . . . . . . . . . . . . . . . . . . . .   4
       3.5.  Recursive Node  . . . . . . . . . . . . . . . . . . . . .   4
       3.6.  Transmission Security . . . . . . . . . . . . . . . . . .   4
       3.7.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.8.  Personal Data . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Abbreviation  . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Security Protection Scope . . . . . . . . . . . . . . . . . .   7
     7.  Security Technical Requirements . . . . . . . . . . . . . . .   8
       7.1.  Data Transmission Integrity . . . . . . . . . . . . . . .   9
       7.2.  Data Transmission Availability  . . . . . . . . . . . . .   9
       7.3.  Data Transmission Confidentiality . . . . . . . . . . . .   9
       7.4.  Data Transmission Authentication  . . . . . . . . . . . .  10
       7.5.  Data Transmission Strategy  . . . . . . . . . . . . . . .  10
       7.6.  Data Transmission Protocol  . . . . . . . . . . . . . . .  10
       7.7.  Maintenance and Update of Transmission Protocol . . . . .  10
       7.8.  Log and Audit . . . . . . . . . . . . . . . . . . . . . .  11
     8.  Protection Dimension  . . . . . . . . . . . . . . . . . . . .  11
       8.1.  Physical Security . . . . . . . . . . . . . . . . . . . .  11
       8.2.  Authentication Mechanism  . . . . . . . . . . . . . . . .  11
       8.3.  System Security . . . . . . . . . . . . . . . . . . . . .  11
       8.4.  Transmission Security . . . . . . . . . . . . . . . . . .  12
       8.5.  Network Security  . . . . . . . . . . . . . . . . . . . .  12
       8.6.  Application Security  . . . . . . . . . . . . . . . . . .  12
       8.7.  Cloud Security  . . . . . . . . . . . . . . . . . . . . .  12
     9.  Data Full Cycle Security  . . . . . . . . . . . . . . . . . .  12
       9.1.  Data Collection Security  . . . . . . . . . . . . . . . .  12
       9.2.  Data transmission security  . . . . . . . . . . . . . . .  13
       9.3.  Data storage security . . . . . . . . . . . . . . . . . .  13
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13



  Wang, et al.            Expires 22 November 2025                [Page 2]


  Internet-Draft      Data Transmission Security of IR            May 2025


     12. Informative References  . . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     Identity resolution system is an important network infrastructure for
     the Industrial Internet.  It provides codes, registration and
     resolution services for industrial equipment, machines, materials,
     parts and products to achieve interoperability, secure sharing and
     intelligent association of heterogeneous information, which is an
     important cornerstone for the rapid development of the Industrial
     Internet.  Typical global identity resolution systems in existence
     include the Handle system [RFC3650] [RFC3651], the Object Identifier
     (OID) resolution system [OID], etc.  In order to ensure the security
     of data transmission involved in the Industrial Internet identity
     resolution systems, the security technical requirements are
     formulated to enhance the security of the entire Industrial Internet
     identity resolution system and reduce the security risk caused by
     data leakage.  The security technical requirements can be applied to
     the planning, construction, operation and management of data
     transmission security of Industrial Internet identity resolution
     systems.

  2.  Scope

     This draft specifies the security technical requirements for the
     transmission of Industrial Internet identity resolution data.

     This draft applies to the planning, construction, operation and
     management of the Industrial Internet identity resolution data
     transmission security of the relevant parties.

  3.  Terms and Definitions

  3.1.  International Root Node

     International root nodes serve as the global top-tier infrastructure
     for identity resolution systems, operating independently of
     geographic boundaries.  These nodes fulfill dual core functions:
     delivering universal root-level identity services worldwide while
     enabling localized data synchronization and registration management
     for hierarchical nodes across national networks.









  Wang, et al.            Expires 22 November 2025                [Page 3]


  Internet-Draft      Data Transmission Security of IR            May 2025


  3.2.  National Root Node

     A national root node is the top-level node within a country or a
     region, which is connected to the international root node and
     secondary nodes, provides top-level identity resolution services for
     the whole country.

  3.3.  Secondary Node

     A secondary node is a public node providing identity services for
     specific industries or multiple industries.  Secondary node is
     responsible for allocating identity and providing identity
     registration, identity resolution and identity data services for
     industrial enterprises.  Two types of secondary nodes exist, namely
     industry secondary nodes and comprehensive secondary nodes.

  3.4.  Enterprise Node

     An enterprise node is an intra-enterprise identity service node which
     is able to provide identity registration, identity resolution service
     and identity data service for a specific enterprise.  An enterprise
     node should be connected to a secondary node.

  3.5.  Recursive Node

     A recursive node is the key entrance facility of the identity
     resolution system, whose responsibility is to cache the resolution
     data in the process of identity resolution, in order to reduce the
     amount of resolution data processing and improve the efficiency of
     resolution services.

  3.6.  Transmission Security

     Protect the confidentiality, integrity, availability and timeliness
     of data transmitted over the network.

  3.7.  Privacy

     Privacy refers to the authority that individuals have to control
     their information, including who collects and stores it and who
     discloses it.

  3.8.  Personal Data

     Personal Data refers to the information that a natural person can be
     identified directly through the data, or indirectly through the data
     combined with other information.




  Wang, et al.            Expires 22 November 2025                [Page 4]


  Internet-Draft      Data Transmission Security of IR            May 2025


  4.  Abbreviation

             +==============+====================================+
             | Abbreviation |                          Full Name |
             +==============+====================================+
             | TLS          |           Transport Layer Security |
             +--------------+------------------------------------+
             | IPSec        |         Internet Protocol Security |
             +--------------+------------------------------------+
             | HTTPS        | Hypertext Transfer Protocol Secure |
             +--------------+------------------------------------+
             | OID          |                  Object Identifier |
             +--------------+------------------------------------+
             | DNS          |                 Domain Name System |
             +--------------+------------------------------------+
             | ENODE        |                    Enterprise Node |
             +--------------+------------------------------------+
             | IIP          |       Industrial Internet Platform |
             +--------------+------------------------------------+
             | HandleID     | Unique Identification of Equipment |
             +--------------+------------------------------------+

                             Table 1: Abbreviation

  5.  Overview

     The Industrial Internet identity resolution and management service
     system represents a comprehensive platform that supports global
     traceability management of industrial IoT product data and enables
     dynamic sharing of information throughout the entire product
     lifecycle.  This system leverages the capabilities of security
     identity management and resolution to accomplish these objectives.
     In the context of Industrial Internet identity resolution, data
     transmission pertains to the technology employed in the Industrial
     Internet terminal to obtain and transmit information.  The security
     of this transmission involves various dimensions, including the basic
     security protection measures in network security, functional domain
     data transmission within and across domains, and the entirety of the
     system's lifecycle.












  Wang, et al.            Expires 22 November 2025                [Page 5]


  Internet-Draft      Data Transmission Security of IR            May 2025


                              +---------------+
                +-------------+ DNS Root Node +----------------+
                |             +---------------+                |
          +-----+-------+                             +--------+------+
          |OID Root Node|  International Root Node    |Ecode Root Node|
          +-----+-------+                             +--------+------+
                |                                              |
                |         +---------------------+              |
                +---------+                     +--------------+
                          |  Handle Root Node   |
              +----------->                     <----------------+
              |           +---------------------+                |
              |                                                  |
              |                                       +----------v---+
              |                                       |Secondary Node|
        +-----+--------+          +---------+         +------+-------+
        |Recursive Node+----+----->National |                |
        +-----^--------+    |     |Top Level|        +-------+--------+
              |             |     |Node     |        |                |
              |             |     +---------+   +----+------+ +-------+--+
              |             |                   | Enterprise| |Enterprise|
              |             |                   | Node      | |Node      |
              |             |                   +-----------+ +----------+
              |             |
  +-----------+---------+   |    +--------------+
  |Identity Resolution  |   +---->Secondary Node|
  |Data and Application |        +------+-------+
  | +------------+      |               |
  | |Industry App|      |       +-------+--------+
  | +------------+      |       |                |
  | +-----------+       |  +----+------+ +-------+--+
  | |Enterprise |       |  | Enterprise| |Enterprise|
  | |Information|       |  | Node      | |Node      |
  | |System     |       |  +-----------+ +----------+
  | +-----------+       |
  | +-----------+       |
  | |Industrial |       |
  | |Internet   |       |
  | |Platform   |       |
  +-------------+-------+

     Figure 1: Industrial Internet Identity Resolution and Management
                              Service System








  Wang, et al.            Expires 22 November 2025                [Page 6]


  Internet-Draft      Data Transmission Security of IR            May 2025


  6.  Security Protection Scope

     The security protection scope of the Industrial Internet identity
     resolution and management service system proposed in this draft
     mainly means that the identity is written into the device and is
     responsible for collecting product information, including device
     model, device type, generation batch, generation date, generation
     site, device production information link, device description data
     link, etc., integrate this information into identity data, and then
     publish it to the data exchange system for access by identity
     resolution enterprise nodes.  Among the identity resolution
     enterprise node, the identity resolution secondary node, and the
     identity resolution root node, the process of data synchronization
     between the application scenarios, the collection of data
     transmission technologies used, is used to provide security assurance
     and security support for the Industrial Internet identity data
     transmission.

     The scope of Industrial Internet identity data transmission security
     protection specifically includes the security and the security
     support of the data transmission interface within and between the
     functional domains of the Industrial Internet identity resolution
     system.  Its role is in the whole life cycle of the system (planning
     and design, development and construction, operation and maintenance ,
     abandonment and exit).


























  Wang, et al.            Expires 22 November 2025                [Page 7]


  Internet-Draft      Data Transmission Security of IR            May 2025


              +--------------------------------------------------------+
              |          Identity Resolution Root Node                 |
              +-------------------------^------------------------------+
                                        |
              +-------------------------v------------------------------+
              |        Identity Resolution Secondary Node              |
              +-------------------------^------------------------------+
   +------------------------------------|--------------------------------+
   |                                    |                                |
   |          +-------------------------v------------------------------+ |
   |          |        Identity Resolution Enterprise Node             | |
   |          +-------------------------^------------------------------+ |
   |Demilitarized                       |                                |
   |   Zone   +-------------------------v------------------------------+ |
   |          |                Data Exchange System                    | |
   |          +-------------------------^------------------------------+ |
   |                                    |                                |
   +------------------------------------|--------------------------------+
   |          +-------------------------|------------------------------+ |
   |          |      Identity Generation and Management System         | |
   |          +------^------------------------------------------^------+ |
   |Enterprise       |                                          |        |
   | Intranet +------v-------+  Enterprise Products ------------v------+ |
   |          |              |  | +-----------------+ +--------------+ | |
   |          |              |  | |Network Hard Disk| |Access Control| | |
   |          |  Enterprise  |  | |Video Recorder   | |    Device    | | |
   |          | Information  |  | +-----------------+ +--------------+ | |
   |          |    System    |  | +------+    +----------+     +---+   | |
   |          |              |  | |Video |    |Industrial|     |...|   | |
   |          |              |  | |Camera|    |   Robot  |     |...|   | |
   |          |              |  | +------+    +----------+     +---+   | |
   |          +--------------+  +--------------------------------------+ |
   +---------------------------------------------------------------------+

     Figure 2: Industrial Internet Identity Resolution and Management
                              Service System

  7.  Security Technical Requirements

     During the transmission of gathered data, it is crucial to verify the
     identities of the communication parties to confirm that only
     authorized users are involved in sending or receiving information.
     This verification is typically accomplished through cryptographic
     methods like digital signatures.  It is also necessary to ensure the
     data remains confidential and that any attempts at alteration are
     noticeable throughout the transmission.  To maintain the secrecy and
     integrity of the data in transit, established cryptographic
     techniques such as encryption, hashing, and digital signatures are



  Wang, et al.            Expires 22 November 2025                [Page 8]


  Internet-Draft      Data Transmission Security of IR            May 2025


     utilized.

  7.1.  Data Transmission Integrity

     Data transmission should comply with the following common
     requirements:

     1) Support the information integrity check mechanism during
     transmission to realize the transmission integrity protection of
     management data, authentication information, sensitive information,
     important business data and other data (such as: check code, message
     abstract, digital signature, etc.).

     2) Should have transmission delay and interrupt handling capabilities
     to ensure the integrity of the data.

     3) Cryptographic technology should be used to protect the integrity
     of important data in transmit.

     4) Measures should be taken to recover the data when data integrity
     is compromised.

  7.2.  Data Transmission Availability

     The timeliness and accuracy of the data should be guaranteed during
     data transmission.  Specifically:

     1) Timeliness: the feature of identifying historical data received or
     data beyond the time limit.  Specifically, the data comes from the
     system using a unified time allocation/correction mechanism, and the
     data should include time stamps, etc.

     2) Accuracy: When there is an acceptable error in the data, there is
     an overload to ensure the normal acquisition of the data in time.

  7.3.  Data Transmission Confidentiality

     When transferring data, it is necessary to ensure the confidentiality
     of the data, including:

     1) For important data, authenticate information and important
     business data such as user passwords, biometrics, private keys,
     symmetric keys, product order information, and unique identity of a
     device (Handle ID), a certain strength encryption algorithm or other
     effective measures should be used to guarantee confidentiality.

     2) Appropriate security protocols (such as HTTPS, SSH, IPSec, TLS,
     etc.) should be used to safeguard the data being transmitted.



  Wang, et al.            Expires 22 November 2025                [Page 9]


  Internet-Draft      Data Transmission Security of IR            May 2025


  7.4.  Data Transmission Authentication

     Ensure the legitimacy of the identities of both parties in the data
     transmission, which means, ensure the identity authentication of the
     subject to the object before the interaction, and establish a trusted
     transmission path.

  7.5.  Data Transmission Strategy

     Establish a formal transmission strategy to protect the security of
     all types of information transmitted through communication
     facilities, and meet:

     1) Clarify the type and scope of information that can be transmitted
     in plain text.

     2) For sensitive data, such as user passwords, biometrics, private
     keys, symmetric keys, etc., an encrypted transmission strategy is
     required.

  7.6.  Data Transmission Protocol

     The protocol should address the safe transmission of internal and
     external business, and meet:

     Cryptographic algorithms such as data abstract, signature, and
     authentication shall use the cryptographic algorithms and
     combinations of abstract, signature, and authentication required by
     national regulations or national mandatory standards.

  7.7.  Maintenance and Update of Transmission Protocol

     The confidentiality protocol for data transmission should be
     regularly maintained and updated so that the procotol should reflect
     the requirements for data transmission security protection and meet:

     1) The transmission security protocol needs to be reviewed every year
     to ensure that the agreement should reflect the requirements for data
     transmission security protection

     2) When new services are launched or existing services are changed,
     the transmission security protocol needs to be audited and updated if
     necessary








  Wang, et al.            Expires 22 November 2025               [Page 10]


  Internet-Draft      Data Transmission Security of IR            May 2025


  7.8.  Log and Audit

     The transmission system shall log and audit the following security
     failure events.  The content of the log shall at least contains date/
     time, event type, event subject, event description, event result
     information, and meet the following requirements:

     1) The results of data transmission channel creation

     2) Transmission device online monitoring abnormalities and alarm
     events

     3) Malicious program intrusion alert event

     4) Configuration modification operations caused by administrators/
     non-administrators

  8.  Protection Dimension

     From the perspective of security requirement analysis and protection
     scheme design, the following implementable protection solutions can
     be considered.

  8.1.  Physical Security

     Ensuring physical security encompasses device hardware security,
     anti-interference measures, and prevention of transmission
     interception.  Qualified devices may also incorporate security chips,
     encryption, key storage, and device identity authentication
     capabilities.  Without robust physical security measures in place,
     implementing other security measures becomes challenging.

  8.2.  Authentication Mechanism

     This involves incorporating multiple authentication and access
     control mechanisms, such as dual-factor authentication and
     fingerprint scanners, suitable for IoT devices.  Enhancing the
     security of human-machine interaction and machine-machine interface
     ensures the overall data security.

  8.3.  System Security

     It involves reinforcing the security of the operating system,
     including digitally signing the operating system code to prevent
     tampering.  Additionally, the access interfaces (APIs) provided by
     the system externally need to be secured.  Data transmission
     interfaces should be analyzed to provide encryption and integrity
     protection functions.



  Wang, et al.            Expires 22 November 2025               [Page 11]


  Internet-Draft      Data Transmission Security of IR            May 2025


  8.4.  Transmission Security

     The protocol design at the transport layer should systematically
     analyze security and privacy threats and risks, ensuring the
     derivation of appropriate safety requirements.  Preventing privacy
     violations should also be considered as one of its primary
     considerations.

  8.5.  Network Security

     Traditional network security devices and functions can still serve as
     means or supplements to Perimeter Security in the Industial Internet.
     Examples include gateway security, firewalls, antivirus and anti-
     malware products, intrusion detection systems (IDS), and intrusion
     prevention systems (IPS).

  8.6.  Application Security

     IoT application developers must prioritize the security and privacy
     protection of their applications.  When designing IoT systems, a
     comprehensive analysis of security should be conducted, finding a
     suitable tradeoff between user experience and protection.

  8.7.  Cloud Security

     Considering the constrained processing power of IoT devices, security
     solutions for cloud data in the Industrial Internet should take into
     account the distinctive characteristics of IoT data, including its
     high volume endpoints and rapid flow.

  9.  Data Full Cycle Security

  9.1.  Data Collection Security

     When collecting data, it is necessary to comply with relevant laws
     and regulations, especially when it comes to personal data, so that
     users are informed, and must follow the principles of user consent,
     minimize collection, collect the required data according to need, and
     clearly set out the scope of collection and the purpose of use in the
     privacy policy.











  Wang, et al.            Expires 22 November 2025               [Page 12]


  Internet-Draft      Data Transmission Security of IR            May 2025


  9.2.  Data transmission security

     When transmitting the collected data, the identity of the two
     communicating parties is identified to ensure that the entity
     receiving or sending the data is a legitimate user, at which time
     digital signatures and other cryptographic techniques are mainly used
     to realize identity authentication.  During transmission, it must be
     ensured that the data content will not be leaked and the data can be
     perceived after being tampered with, i.e., the confidentiality and
     integrity of the transmitted data must be ensured, which can be
     realized by using traditional cryptographic algorithms, such as
     encryption, hash, digital signature, and so on.

  9.3.  Data storage security

     When storing data, the data should be stored in hierarchical
     isolation, according to the sensitive level of the data, and the data
     of different levels can be stored in different hard disks by using
     physical isolation, or by using logical isolation, using
     virtualization and other related technologies to achieve isolation
     between the areas where the data of different levels are located.

  10.  Security Considerations

     This entire memo deals with security issues.

  11.  IANA Considerations

     This documents has no IANA actions.

  12.  Informative References

     [OID]      "Introduction to OIDs and the OID Resolution System
                (ORS)", May 2020,
                <http://www.oid-info.com/introduction.htm>.

     [RFC3650]  Sun, S., Lannom, L., and B. Boesch, "Handle System
                Overview", DOI 10.17487/RFC3650, November 2003,
                <https://www.rfc-editor.org/info/rfc3650>.

     [RFC3651]  Sun, S., Reilly, S., and L. Lannom, "Handle System
                Namespace and Service Definition", DOI 10.17487/RFC3651,
                November 2003, <https://www.rfc-editor.org/info/rfc3651>.

  Authors' Addresses






  Wang, et al.            Expires 22 November 2025               [Page 13]


  Internet-Draft      Data Transmission Security of IR            May 2025


     Bin Wang (editor)
     Hikvision
     555 Qianmo Road, Binjiang District
     Hangzhou
     310051
     China
     Phone: +86 571 8847 3644
     Email: wbin2006@gmail.com


     Kezhang Lin (editor)
     Hikvision
     555 Qianmo Road, Binjiang District
     Hangzhou
     310051
     China
     Phone: +86 571 8847 3644
     Email: lkz_wz98@163.com


     Chonghua Wang (editor)
     IIE, CAS
     Beijing
     100093
     China
     Phone: +86 185 1894 5987
     Email: chonghuaw@live.com


     Xing Wang (editor)
     Hikvision
     555 Qianmo Road, Binjiang District
     Hangzhou
     310051
     China
     Phone: +86 571 8847 3644
     Email: xing.wang.email@gmail.com


     Haonan Yan (editor)
     Xidian University
     No. 8, Qiannong East Road, Xiaoshan District
     Hangzhou
     310051
     China
     Email: yanhaonan.sec@gmail.com





  Wang, et al.            Expires 22 November 2025               [Page 14]


  Internet-Draft      Data Transmission Security of IR            May 2025


     Yinghui Xie (editor)
     Hikvision
     555 Qianmo Road, Binjiang District
     Hangzhou
     310051
     China
     Phone: +86 571 8847 3644
     Email: xieyinghui@hikvision.com











































  Wang, et al.            Expires 22 November 2025               [Page 15]


name: draft-pan-aqm-pie
rev: 02
title: PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem
time: 2024-12-18T18:44:02Z
group_uri: /api/v1/group/group/1324/
expires: 2015-03-22T00:11:57Z
ad: /api/v1/person/person/105519/
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.448200+00:00
source: ietf
abstract:
  Bufferbloat is a phenomenon where excess buffers in the network cause
     high latency and jitter. As more and more interactive applications
     (e.g. voice over IP, real time video streaming and financial
     transactions) run in the Internet, high latency and jitter degrade
     application performance. There is a pressing need to design
     intelligent queue management schemes that can control latency and
     jitter; and hence provide desirable quality of service to users.

     We present here a lightweight design, PIE(Proportional Integral
     controller Enhanced) that can effectively control the average
     queueing latency to a target value. Simulation results, theoretical
     analysis and Linux testbed results have shown that PIE can ensure low
     latency and achieve high link utilization under various congestion
     situations. The design does not require per-packet timestamp, so it
     incurs very small overhead and is simple enough to implement in both
     hardware and software.

full_text:
   



  Internet Draft                                                    R. Pan
  Network Working Group                 P. Natarajan, F. Baker, B.V. Steeg
  Intended Status: Informational    M. Prabhu, V. Subramanian, C. Piglione
                                                             Cisco Systems

  Expires: March 21, 2015                               September 17, 2014


             PIE: A Lightweight Control Scheme To Address the 
                            Bufferbloat Problem 

  		      draft-pan-aqm-pie-02


  Abstract

     Bufferbloat is a phenomenon where excess buffers in the network cause
     high latency and jitter. As more and more interactive applications
     (e.g. voice over IP, real time video streaming and financial
     transactions) run in the Internet, high latency and jitter degrade
     application performance. There is a pressing need to design
     intelligent queue management schemes that can control latency and
     jitter; and hence provide desirable quality of service to users. 

     We present here a lightweight design, PIE(Proportional Integral
     controller Enhanced) that can effectively control the average
     queueing latency to a target value. Simulation results, theoretical
     analysis and Linux testbed results have shown that PIE can ensure low
     latency and achieve high link utilization under various congestion
     situations. The design does not require per-packet timestamp, so it
     incurs very small overhead and is simple enough to implement in both
     hardware and software. 

  Status of this Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

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

   


  Pan et al.               Expires March 21, 2015                 [Page 1]


  INTERNET DRAFT                    PIE                     March 21, 2015


     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html


  Copyright and License Notice

     Copyright (c) 2012 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
     (http://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 Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.



  Table of Contents

     1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3. Design Goals  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4. The PIE Scheme  . . . . . . . . . . . . . . . . . . . . . . . .  5
       4.1 Random Dropping  . . . . . . . . . . . . . . . . . . . . . .  5
       4.2 Drop Probability Calculation . . . . . . . . . . . . . . . .  6
       4.3 Departure Rate Estimation  . . . . . . . . . . . . . . . . .  7
       4.4 Handling Bursts  . . . . . . . . . . . . . . . . . . . . . .  8
     5. Comments and Discussions  . . . . . . . . . . . . . . . . . . .  9
     8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
     9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       9.1  Normative References  . . . . . . . . . . . . . . . . . . . 11
       9.2  Informative References  . . . . . . . . . . . . . . . . . . 11
       9.3  Other References  . . . . . . . . . . . . . . . . . . . . . 11
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12







   


  Pan et al.               Expires March 21, 2015                 [Page 2]


  INTERNET DRAFT                    PIE                     March 21, 2015


  1. Introduction

     The explosion of smart phones, tablets and video traffic in the
     Internet brings about a unique set of challenges for congestion
     control. To avoid packet drops, many service providers or data center
     operators require vendors to put in as much buffer as possible. With
     rapid decrease in memory chip prices, these requests are easily
     accommodated to keep customers happy. However, the above solution of
     large buffer fails to take into account the nature of the TCP
     protocol, the dominant transport protocol running in the Internet.
     The TCP protocol continuously increases its sending rate and causes
     network buffers to fill up. TCP cuts its rate only when it receives a
     packet drop or mark that is interpreted as a congestion signal.
     However, drops and marks usually occur when network buffers are full
     or almost full. As a result, excess buffers, initially designed to
     avoid packet drops, would lead to highly elevated queueing latency
     and jitter. It is a delicate balancing act to design a queue
     management scheme that not only allows short-term burst to smoothly
     pass, but also controls the average latency when long-term congestion
     persists.

     Active queue management (AQM) schemes, such as Random Early Discard
     (RED), have been around for well over a decade. AQM schemes could
     potentially solve the aforementioned problem. RFC 2309[RFC2309]
     strongly recommends the adoption of AQM schemes in the network to
     improve the performance of the Internet. RED is implemented in a wide
     variety of network devices, both in hardware and software. 
     Unfortunately, due to the fact that RED needs careful tuning of its
     parameters for various network conditions, most network operators
     don't turn RED on. In addition, RED is designed to control the queue
     length which would affect delay implicitly. It does not control
     latency directly. Hence, the Internet today still lacks an effective
     design that can control buffer latency to improve the quality of
     experience to latency-sensitive applications. 

     Recently, a new AQM scheme, CoDel[CoDel],  was proposed to control
     the latency directly to address the bufferbloat problem. CoDel
     requires per packet timestamps. Also, packets are dropped at the
     dequeue function after they have been enqueued for a while. Both of
     these requirements consume excessive processing and infrastructure
     resources. This consumption will make CoDel expensive to implement
     and operate, especially in hardware. 

     PIE aims to combine the benefits of both RED and CoDel: easy to
     implement like RED and directly control latency like CoDel. Similar
     to RED, PIE randomly drops a packet at the onset of the congestion.
     The congestion detection, however, is based on the queueing latency
     like CoDel instead of the queue length like RED. Furthermore, PIE
   


  Pan et al.               Expires March 21, 2015                 [Page 3]


  INTERNET DRAFT                    PIE                     March 21, 2015


     also uses the latency moving trends: latency increasing or
     decreasing, to help determine congestion levels. The design
     parameters of PIE are chosen via stability analysis. While these
     parameters can be fixed to work in various traffic conditions, they
     could be made self-tuning to optimize system performance. 

     In addition, we assume any delay-based AQM scheme would be applied
     over a Fair Queueing (FQ) structure or its approximate design, Class
     Based Queueing (CBQ). FQ is one of the most studied scheduling
     algorithms since it was first proposed in 1985 [RFC970]. CBQ has been
     a standard feature in most network devices today[CBQ]. These designs
     help flows/classes achieve max-min fairness and help mitigate bias
     against long flows with long round trip times(RTT). Any AQM scheme
     that is built on top of FQ or CBQ could benefit from these
     advantages. Furthermore, we believe that these advantages such as per
     flow/class fairness are orthogonal to the AQM design whose primary
     goal is to control latency for a given queue. For flows that are
     classified into the same class and put into the same queue, we need
     to ensure their latency is better controlled and their fairness is
     not worse than those under the standard DropTail or RED design.  

     This draft describes the overall design goals, system elements and
     implementation details of PIE. We will also discuss various design
     considerations, including how auto-tuning can be done. 




  2. Terminology

     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 RFC 2119 [RFC2119].


  3. Design Goals

     We explore a queue management framework where we aim to improve the
     performance of interactive and delay-sensitive applications. The
     design of our scheme follows a few basic criteria.  

          * First, we directly control queueing latency instead of
          controlling queue length. Queue sizes change with queue draining
          rates and various flows' round trip times. Delay bloat is the
          real issue that we need to address as it impairs real time
          applications. If latency can be controlled, bufferbloat is not
          an issue. As a matter of fact, we would allow more buffers for
          sporadic bursts as long as the latency is under control. 
   


  Pan et al.               Expires March 21, 2015                 [Page 4]


  INTERNET DRAFT                    PIE                     March 21, 2015


          * Secondly, we aim to attain high link utilization. The goal of
          low latency shall be achieved without suffering link under-
          utilization or losing network efficiency. An early congestion
          signal could cause TCP to back off and avoid queue building up.
          On the other hand, however, TCP's rate reduction could result in
          link under-utilization. There is a delicate balance between
          achieving high link utilization and low latency.

          * Furthermore, the scheme should be simple to implement and
          easily scalable in both hardware and software. The wide adoption
          of RED over a variety of network devices is a testament to the
          power of simple random early dropping/marking. We strive to
          maintain similar design simplicity. 

          * Finally, the scheme should ensure system stability for various
          network topologies and scale well with arbitrary number streams.
          Design parameters shall be set automatically. Users only need to
          set performance-related parameters such as target queue delay,
          not design parameters. 

  In the following, we will elaborate on the design of PIE and its
  operation.

  4. The PIE Scheme

  As illustrated in Fig. 1, our scheme comprises three simple components:
  a) random dropping at enqueing; b) periodic drop probability update; c)
  dequeing rate estimation.

  The following sections describe these components in further detail, and
  explain how they interact with each other.  At the end of this section,
  we will discuss how the scheme can be easily augmented to precisely
  control bursts. 


  4.1 Random Dropping

  Like any state-of-the-art AQM scheme, PIE would drop packets randomly
  according to a drop probability, p, that is obtained from the drop-
  probability-calculation component:

      * upon a packet arrival

          randomly drop a packet with a probability p.




   


  Pan et al.               Expires March 21, 2015                 [Page 5]


  INTERNET DRAFT                    PIE                     March 21, 2015


           Random Drop 
               /               --------------
       -------/  -------------->    | | | | | -------------->     
              /|\                   | | | | |         |
               |               --------------         |
               |                 Queue Buffer         |
               |                     |                | Departure bytes
               |                     |queue           |
               |                     |length          | 
               |                     |                |
               |                    \|/              \|/
               |          -----------------    -------------------
               |          |     Drop      |    |                 |
               -----<-----|  Probability  |<---| Departure Rate  | 
                          |  Calculation  |    | Estimation      |
                          -----------------    ------------------- 



                        Figure 1. The PIE Structure




  4.2 Drop Probability Calculation

  The PIE algorithm periodically updates the drop probability as follows: 

      * estimate current queueing delay using Little's law:

          est_del = qlen/depart_rate; 


      * calculate drop probability p as: 

          p = p + alpha*(est_del-target_del) + beta*(est_del-est_del_old);

          est_del_old = est_del. 


  Here, the current queue length is denoted by qlen. The draining rate of
  the queue, depart_rate, is obtained from the departure-rate-estimation
  block.  Variables, est_del and est_del_old, represent the current and
  previous estimation of the queueing delay. The target latency value is
  expressed in target_del.  The update interval is denoted as Tupdate. 

  Note that the calculation of drop probability is based not only on the
  current estimation of the queueing delay, but also on the direction
   


  Pan et al.               Expires March 21, 2015                 [Page 6]


  INTERNET DRAFT                    PIE                     March 21, 2015


  where the delay is moving, i.e., whether the delay is getting longer or
  shorter. This direction can simply be measured as the difference between
  est_del and est_del_old. This is the classic Proportional Integral
  controller design that is adopted here for controlling queueing latency.
  The controller parameters, in the unit of hz, are designed using
  feedback loop analysis where TCP's behaviors are modeled using the
  results from well-studied prior art[TCP-Models]. 

  We would like to point out that this type of controller has been studied
  before for controlling the queue length [PI, QCN]. PIE adopts the
  Proportional Integral controller for controlling delay and makes the
  scheme auto-tuning. The theoretical analysis of PIE is under paper
  submission and its reference will be included in this draft once it
  becomes available. Nonetheless, we will discuss the intuitions for these
  parameters in Section 5.


  4.3 Departure Rate Estimation

  The draining rate of a queue in the network often varies either because
  other queues are sharing the same link, or the link capacity fluctuates.
  Rate fluctuation is particularly common in wireless networks. Hence, we
  decide to measure the departure rate directly as follows. 


      * we are in a measurement cycle if we have enough data in the queue:

          qlen > deq_threshold


      * if in a measurement cycle:

          upon a packet departure 

          dq_count = dq_count + deque_pkt_size;


      * if dq_count > deq_threshold then 


          depart_rate = dq_count/(now-start);

          dq_count = 0;

          start = now; 


  We only measure the departure rate when there are sufficient data in the
   


  Pan et al.               Expires March 21, 2015                 [Page 7]


  INTERNET DRAFT                    PIE                     March 21, 2015


  buffer, i.e., when the queue length is over a certain threshold,
  deq_threshold. Short, non-persistent bursts of packets result in empty
  queues from time to time, this would make the measurement less accurate.
  The parameter, dq_count, represents the number of bytes departed since
  the last measurement. Once dq_count is over a certain threshold,
  deq_threshold, we obtain a measurement sample. The threshold is
  recommended to be set to 10KB assuming a typical packet size of around
  1KB or 1.5KB. This threshold would allow us a long enough period to
  obtain an average draining rate but also fast enough to reflect sudden
  changes in the draining rate. Note that this threshold is not crucial
  for the system's stability. 

  4.4 Handling Bursts 

  The above three components form the basis of the PIE algorithm. Although
  we aim to control the average latency of a congested queue, the scheme
  should allow short term bursts to pass through the system without
  hurting them. We would like to discuss how PIE manages bursts in this
  section.

  Bursts are well tolerated in the basic scheme for the following reasons:
  first, the drop probability is updated periodically. Any short term
  burst that occurs within this period could pass through without
  incurring extra drops as it would not trigger a new drop probability
  calculation. Secondly, PIE's drop probability calculation is done
  incrementally. A single update would only lead to a small incremental
  change in the probability. So if it happens that a burst does occur at
  the exact instant that the probability is being calculated, the
  incremental nature of the calculation would ensure its impact is kept
  small.

  Nonetheless, we would like to give users a precise control of the burst.
  We introduce a parameter, max_burst, that is similar to the burst
  tolerance in the token bucket design. By default, the parameter is set
  to be 100ms. Users can certainly modify it according to their
  application scenarios. The burst allowance is added into the basic PIE
  design as follows:

      * if p == 0 and est_del < del_ref and est_del_old < del_ref

          burst_allowance = max_burst;

      * upon packet arrival

          if burst_allowance > 0 enqueue packet;

      * upon probability update

   


  Pan et al.               Expires March 21, 2015                 [Page 8]


  INTERNET DRAFT                    PIE                     March 21, 2015


          burst_allowance = burst_allowance - Tupdate;



  The burst allowance, noted by burst_allowance, is initialized to
  max_burst. As long as burst_allowance is above zero, an incoming packet
  will be enqueued bypassing the random drop process. During each update
  instance, the value of burst_allowance is decremented by the update
  period, Tupdate. When the congestion goes away, defined by us as p
  equals to 0 and both the current and previous samples of estimated delay
  are less than target_del, we reset burst_allowance to max_burst. 	

  5. Comments and Discussions

  While the formal analysis will be included later, we would like to
  discuss the intuitions regarding how to determine the key parameters.
  Although the PIE algorithm would set them automatically, they are not
  meant to be magic numbers. We hope to give enough explanations here to
  help demystify them so that users can experiment and explore on their
  own.

  As it is obvious from the above, the crucial equation in the PIE
  algorithm is

       p = p + alpha*(est_del-target_del) + beta*(est_del-est_del_old). 

  The value of alpha determines how the deviation of current latency from
  the target value affects the drop probability.  The beta term exerts
  additional adjustments depending on whether the latency is trending up
  or down. Note that the drop probability is reached incrementally, not
  through a single step. To avoid big swings in adjustments which often
  leads to instability, we would like to tune p in small increments.
  Suppose that p is in the range of 1%. Then we would want the value of
  alpha and beta to be small enough, say 0.1%, adjustment in each step. If
  p is in the higher range, say above 10%, then the situation would
  warrant a higher single step tuning, for example 1%. Finally, the drop
  probability would only be stabilized when the latency is stable, i.e.
  est_del equals est_del_old; and the value of the latency is equal to
  target_del. The relative weight between alpha and beta determines the
  final balance between latency offset and latency jitter. 

  The update interval, Tupdate, also plays a key role in stability. Given
  the same alpha and beta values, the faster the update is, the higher the
  loop gain will be. As it is not showing explicitly in the above
  equation, it can become an oversight. Notice also that alpha and beta
  have a unit of hz. 

  As a further extension, we could introduce weights for flows that are
   


  Pan et al.               Expires March 21, 2015                 [Page 9]


  INTERNET DRAFT                    PIE                     March 21, 2015


  classified into the same queue to achieve differential dropping. For
  example, the dropping probability for flow i could be p(i) =
  p/weight(i). Flows with higher weights would receive proportionally less
  drops; and vice versa. Adding FQ on top, FQ_PIE, is another alternative.

  Also, we have discussed congestion notification via the form of packet
  drops. The algorithm can be easily applied to networks codes where Early
  Congestion Notification (ECN) is enabled. The drop probability, p, above
  would become marking probability. 


  6. Implementation

  PIE can be applied to existing hardware or software solutions. In this
  section, we discuss the implementation cost of the PIE algorithm. There
  are three steps involved in PIE as discussed in Section 4. We examine
  their complexities as follows.

  Upon packet arrival, the algorithm simply drops a packet randomly based
  on the drop probability p. This step is straightforward and requires no
  packet header examination and manipulation. Besides, since no per packet
  overhead, such as a timestamp, is required, there is no extra memory
  requirement. Furthermore, the input side of a queue is typically under
  software control while the output side of a queue is hardware based.
  Hence, a drop at enqueueing can be readily retrofitted into existing
  hardware or software implementations.

  The drop probability calculation is done in the background and it occurs
  every Tudpate interval. Given modern high speed links, this period
  translates into once every tens, hundreds or even thousands of packets.
  Hence the calculation occurs at a much slower time scale than packet
  processing time, at least an order of magnitude slower. The calculation
  of drop probability involves multiplications using alpha and beta. Since
  the algorithm is not sensitive to the precise values of alpha and beta,
  we can choose the values, e.g. alpha
  = 0.25 and beta
  = 2.5 so that
  multiplications can be done using simple adds and shifts. As no
  complicated functions are required, PIE can be easily implemented in
  both hardware and software. The state requirement is only two variables
  per queue: est_del and est_del_old. Hence the memory overhead is small.

  In the departure rate estimation, PIE uses a counter to keep track of
  the number of bytes departed for the current interval. This counter is
  incremented per packet departure. Every Tupdate, PIE calculates latency
  using the departure rate, which can be implemented using a
  multiplication. Note that many network devices keep track an interface's
  departure rate. In this case, PIE might be able to reuse this
  information, simply skip the third step of the algorithm and hence
  incurs no extra cost. We also understand that in some software
   


  Pan et al.               Expires March 21, 2015                [Page 10]


  INTERNET DRAFT                    PIE                     March 21, 2015


  implementations, time-stamped are added for other purposes. In this
  case, we can also make use of the time-stamps and bypass the departure
  rate estimation and directly used the timestamp information in the drop
  probability calculation. 

  In summary, the state requirement for PIE is limited and computation
  overheads are small. Hence, PIE is simple to be implemented. In
  addition, since PIE does not require any user configuration, it does not
  impose any new cost on existing network management system solutions. SFQ
  can be combined with PIE to provide further improvement of latency for
  various flows with different priorities. However, SFQ requires extra
  queueing and scheduling structures. Whether the performance gain can
  justify the design overhead needs to be further investigated.

  7. Incremental Deployment

  One nice property of the AQM design is that it can be independently
  designed and operated without the requirement of being inter-operable. 

  Although all network nodes can not be changed altogether to adopt
  latency-based AQM schemes, we envision a gradual adoption which would
  eventually lead to end-to-end low latency service for real time
  applications.  

  8. IANA Considerations

  There are no actions for IANA.

  9. References

  9.1  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.


  9.2  Informative References

     [RFC970]   Nagle, J., "On Packet Switches With Infinite
                Storage",RFC970, December 1985.



  9.3  Other References

     [CoDel]    	Nichols, K., Jacobson, V., "Controlling Queue Delay", ACM
                    Queue. ACM Publishing. doi:10.1145/2209249.22W.09264.

   


  Pan et al.               Expires March 21, 2015                [Page 11]


  INTERNET DRAFT                    PIE                     March 21, 2015


     [CBQ]      	Cisco White Paper, "http://www.cisco.com/en/US/docs/12_0t
                    /12_0tfeature/guide/cbwfq.html". 

     [TCP-Models] 	Misra, V., Gong, W., and Towsley, D., "Fluid-based 	   
                    Analysis of a Network of AQM Routers Supporting TCP   
                    Flows with an Application to RED", SIGCOMM 2000.

     [PI]		Hollot, C.V., Misra, V., Towsley, D. and Gong, W.,
     		"On Designing Improved Controller for AQM Routers
     		Supporting TCP Flows", Infocom 2001.

     [QCN]		"Data Center Bridging - Congestion Notification",
     		http://www.ieee802.org/1/pages/802.1au.html.


  Authors' Addresses



     Rong Pan
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: ropan@cisco.com

     Preethi Natarajan, 
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: prenatar@cisco.com

     Fred Baker
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: fred@cisco.com

     Mythili Prabhu
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: mysuryan@cisco.com

     Chiara Piglione
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: cpiglion@cisco.com
   


  Pan et al.               Expires March 21, 2015                [Page 12]


  INTERNET DRAFT                    PIE                     March 21, 2015


     Vijay Subramanian
     Cisco Systems
     510 McCarthy Blvd, 
     Milpitas, CA 95134, USA
     Email: vijaynsu@cisco.com

     Bill Ver Steeg
     Cisco Systems
     5030 Sugarloaf Parkway 
     Lawrenceville, GA, 30044, USA
     Email: versteb@cisco.com








































  Pan et al.               Expires March 21, 2015                [Page 13]


name: draft-zhao-detnet-enhanced-use-cases
rev: 05
title: Enhanced Use Cases for Scaling Deterministic Networks
time: 2026-02-24T07:21:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T07:21:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.453214+00:00
source: ietf
abstract:
  This document describes use cases and network requirements for
     scaling deterministic networks which is not covered in RFC8578, such
     as industrial internet, high experience video, intelligent computing,
     and ISAC-enabled smart factory and outlines the common properties
     implied by these use cases.

full_text:
  DETNET                                                           J. Zhao
  Internet-Draft                                                     CAICT
  Intended status: Standards Track                                Q. Xiong
  Expires: 27 August 2026                                  ZTE Corporation
                                                                     Z. Du
                                                              China Mobile
                                                                 M. Jadoon
                                                              InterDigital
                                                            L.M. Contreras
                                                                Telefonica
                                                          23 February 2026


           Enhanced Use Cases for Scaling Deterministic Networks
                  draft-zhao-detnet-enhanced-use-cases-05

  Abstract

     This document describes use cases and network requirements for
     scaling deterministic networks which is not covered in RFC8578, such
     as industrial internet, high experience video, intelligent computing,
     and ISAC-enabled smart factory and outlines the common properties
     implied by these use cases.

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

  Copyright Notice

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






  Zhao, et al.             Expires 27 August 2026                 [Page 1]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Enhanced Use Cases and Network Requirements . . . . . . . . .   4
       3.1.  Industrial Internet . . . . . . . . . . . . . . . . . . .   4
         3.1.1.  Use Case Description  . . . . . . . . . . . . . . . .   4
           3.1.1.1.  Machine Vision  . . . . . . . . . . . . . . . . .   4
           3.1.1.2.  Remote Control  . . . . . . . . . . . . . . . . .   5
           3.1.1.3.  AGV Intelligent Control . . . . . . . . . . . . .   6
           3.1.1.4.  AR Assistance . . . . . . . . . . . . . . . . . .   6
         3.1.2.  Requests to the IETF  . . . . . . . . . . . . . . . .   7
       3.2.  High Experience Video . . . . . . . . . . . . . . . . . .   8
         3.2.1.  Use Case Description  . . . . . . . . . . . . . . . .   8
           3.2.1.1.  Cloud VR and AR . . . . . . . . . . . . . . . . .   8
           3.2.1.2.  Cloud Games . . . . . . . . . . . . . . . . . . .   9
           3.2.1.3.  Cloud Live Streaming  . . . . . . . . . . . . . .  10
         3.2.2.  Requests to the IETF  . . . . . . . . . . . . . . . .  10
       3.3.  Intelligent Computing . . . . . . . . . . . . . . . . . .  10
         3.3.1.  Use Case Description  . . . . . . . . . . . . . . . .  11
           3.3.1.1.  Scientific Research . . . . . . . . . . . . . . .  11
           3.3.1.2.  Autonomous Vehicles . . . . . . . . . . . . . . .  12
         3.3.2.  Requests to the IETF  . . . . . . . . . . . . . . . .  12
       3.4.  ISAC-Enabled Smart Factory  . . . . . . . . . . . . . . .  13
         3.4.1.  Use Case Description  . . . . . . . . . . . . . . . .  13
           3.4.1.1.  Predictive Maintenance  . . . . . . . . . . . . .  14
           3.4.1.2.  Real-Time Process Optimization  . . . . . . . . .  14
           3.4.1.3.  Safety Control and Maintenance  . . . . . . . . .  15
           3.4.1.4.  Interconnection of Time Sensitive Domains . . . .  16
         3.4.2.  Requests to the IETF  . . . . . . . . . . . . . . . .  16
     4.  Use Case Common Themes  . . . . . . . . . . . . . . . . . . .  17
       4.1.  Requirements for DetNet Multi-domains . . . . . . . . . .  17
       4.2.  Requirements for DetNet Service Classification  . . . . .  18
       4.3.  Requirements for Ultra-low or Zero Packet Loss  . . . . .  20
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
     Appendix A.  Simulation Results in Scientific Research  . . . . .  21



  Zhao, et al.             Expires 27 August 2026                 [Page 2]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


       A.1.  Simulation for the Long Distance and Latency  . . . . . .  21
       A.2.  Simulation for the Latency and Packet Loss  . . . . . . .  22
     References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
       Informative References  . . . . . . . . . . . . . . . . . . . .  23
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     According to [RFC8655], Deterministic Networking (DetNet) operates at
     the IP layer and delivers service which provides extremely low data
     loss rates and bounded latency within a network domain.  The bounded
     latency indicates the minimum and maximum end-to-end latency from
     source to destination and bounded jitter (packet delay variation).
     [RFC8578] has presented use cases for diverse industries and these
     use cases differ in their network topologies and requirements.  It
     should provide specific desired behaviors in DetNet.

     [I-D.ietf-detnet-scaling-requirements] focus on the scaling
     deterministic networks and describes the enhanced requirements for
     DetNet enhanced data plane including the deterministic latency
     guarantees and it also mentioned the enhanced DetNet should support
     different levels of application requirements which is important for
     the DetNet deployment.  There are a variety of use cases in scaling
     deterministic networks which is not covered in [RFC8578].  It is
     required to provide the typical use cases for scaling deterministic
     networks and analyze the SLAs requirements and desired behaviors in
     enhanced DetNet.

     The industries covered by the use cases in this document are:

     *  Industrial Internet (section 3.1)

     *  High Experience Video (section 3.2)

     *  Intelligent Computing (section 3.3)

     *  ISAC-Enabled Smart Factory(section 3.4)

     This document describes use cases and network requirements for
     scaling deterministic networks including industrial internet, high
     experience video and intelligent computing and outlines the common
     properties implied by these use cases.

  1.1.  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 RFC 2119 [RFC2119].



  Zhao, et al.             Expires 27 August 2026                 [Page 3]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  2.  Terminology

     The terminology is defined as [RFC8655] and [RFC8578].

  3.  Enhanced Use Cases and Network Requirements

  3.1.  Industrial Internet

  3.1.1.  Use Case Description

     In the industrial internet, the entire industrial process can be
     roughly divided into research and development design, production
     manufacturing, operation and maintenance services.  The typical
     application prospects of deterministic networks mainly include ultra-
     high definition video, cloud-based robots, remote control, machine
     vision, and cloud-based AGV.  The scenarios such as machine vision,
     AGV intelligent control, remote control, and AR assisted robotic arm
     control demand deterministic requirements.

  3.1.1.1.  Machine Vision

     The machine vision system needs to achieve real-time remote
     monitoring function, which requires high-speed and large connectivity
     characteristics.  It can monitor the production process execution
     management system (MES) of manufacturing enterprises through mobile
     and portable terminals without entering the workshop, and obtain the
     operating status of the visual inspection system, such as normal
     operating time, effective operating time, fault cause etc.  It is
     bandwidth sensitive and demand cloud-based deployment and wide area
     networks requirements.

     The following table shows the main network requirements of machine
     vision.(These metrics are based on 3GPP Standard 3GPP TS 22.104, 3GPP
     TR 22.261, and 3GPP TR 22.829.)



     +---------------------------------+---------------------------------+
     |    Machine Vision Requirement   |            Attribute            |
     +---------------------------------+---------------------------------+
     |      Bandwidth                  |   Real time upload of image     |
     |                                 |   information:>50M              |
     |                                 |                                 |
     |     One-way maximum delay       |              10 ms              |
     |                                 |                                 |
     |           Availability          |             99.99%              |
     +---------------------------------+---------------------------------+




  Zhao, et al.             Expires 27 August 2026                 [Page 4]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


                 Figure 1: Requirements of Machine Vision

  3.1.1.2.  Remote Control

     Remote control can ensure personnel safety, improve production
     efficiency, and achieve assistance from multiple production units.
     In order to achieve the effect of remote control, the controller
     needs to send status information to the controller through a
     communication network based on remote perception.  The controller
     analyzes and makes decisions based on the received status
     information, and then sends corresponding action instructions to the
     controller through the communication network.  The controller
     executes the corresponding actions based on the received action
     instructions, completing the remote control process.  In order to
     guarantee control effectiveness, communication network latency,
     jitter, and reliability are even more important.  The typical
     application is cloud-based PLC (Programmable Logic Controller).  It
     is jitter sensitive and cloud-based PLC demand wide area networks
     requirements.

     The following table describes requirements of Cloud-based PLC.
     (These metrics are based on 3GPP Standard 3GPP TS 22.104, 3GPP TR
     22.261, and 3GPP TR 22.829.)



     +-------------------------------+-----------------------------------+
     |  Cloud-based PLC Requirement  |            Attribute              |
     +-------------------------------+-----------------------------------+
     |     Bandwidth                 | Image/video stream upload,        |
     |                               |  upstream>50Mbps;                 |
     |                               | PLC control command issued,       |
     |                               |  downstream>50kbps;               |
     |                               |                                   |
     |      One-way maximum delay    |Within workshop level equipment:1ms|
     |                               |Workshop level equipment room:10ms |
     |                               |Remote operation in the park/city/ |
     |                               |wide area: image upstream:20ms;    |
     |                               |Command issuance:10ms;             |
     |                               |                                   |
     |          Maximum jitter       |      Less than 100 us             |
     |                               |                                   |
     |           Availability        |             99.999%               |
     +-------------------------------+-----------------------------------+


                Figure 2: Requirements of Cloud-based PLC




  Zhao, et al.             Expires 27 August 2026                 [Page 5]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  3.1.1.3.  AGV Intelligent Control

     Automated Guided Vehicle (AGV) is an intelligent device widely used
     in highly automated places such as factory workshops, airports,
     ports, freight warehouses, etc.  It generally consists of three
     parts: walking, navigation, and control systems.  The automated AGV
     is equipped with a camera to capture the scene in front of the
     vehicle and upload it to the MEC and navigation system in real-time
     through a 5G module for image analysis and route planning, achieving
     fully automated logistics transportation.  AGV has a certain driving
     speed and is often used in cluster operation scenarios.  Therefore, a
     network connection with high deterministic delay and jitter is
     required to transmit control signals.

     The following table describes requirements of AGV intelligent
     control.(These metrics are based on 3GPP Standard 3GPP TS 22.104,
     3GPP TR 22.261, and 3GPP TR 22.829.)

     +-----------------------------+--------------------------------------+
     | AGV Intelligent Control     |                                      |
     |              Requirement    |            Attribute                 |
     +-----------------------------+--------------------------------------+
     |     Bandwidth               |Schedule communication:>1Mbps,        |
     |                             |Real time communication:1Mbps~200Mbps |
     |                             |Visual: 10Mbps~1Gbps                  |
     |                             |                                      |
     |    One-way maximum delay    |Schedule communication:100ms          |
     |                             |Dispatching communication:100ms       |
     |                             |Real time communication:20ms~40ms     |
     |                             |Visual: 10ms~100ms                    |
     |     Availability            |             99.9999%                 |
     +-----------------------------+--------------------------------------+


            Figure 3: Requirements of AGV Intelligent Control

  3.1.1.4.  AR Assistance

     With the intelligent and networked transformation and upgrading of
     industrial manufacturing equipment, more and more AR assisted
     intelligent robots will be used in advanced manufacturing.  At the
     same time, there are scenarios where multiple robot systems work
     together, such as welding, stamping, etc.  The robotic arm is the
     most widely used automated mechanical device in the field of robotics
     technology, in areas such as industrial manufacturing, medical
     treatment, entertainment services, military, semiconductor
     manufacturing, and space exploration.  The more axis joints of the AR
     assisted robotic arm, the higher the degree of freedom, and the



  Zhao, et al.             Expires 27 August 2026                 [Page 6]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     larger the angle of the operating range.

     The following table describes requirements of AR Assistance.  (These
     metrics are based on 3GPP Standard 3GPP TS 22.104, 3GPP TR 22.261,
     and 3GPP TR 22.829.)

            +---------------------------+----------------------------+
            |  AR Assistance Requirement|            Attribute       |
            +---------------------------+----------------------------+
            |     Bandwidth             | Maintenance guidance:      |
            |                           |  downstream>50Mbps         |
            |                           |  upstream > 20Mbps         |
            |                           |  downstream>50kbps         |
            |                           | Auxiliary assembly: >50Mbps|
            |                           |  downstream: 1Mbps~30Mbps  |
            |                           |                            |
            |  One-way maximum delay    |Maintenance guidance:20ms   |
            |                           |Auxiliary assembly:10ms     |
            |                           |                            |
            |    Maximum jitter         |      Less than 500 us      |
            |                           |                            |
            |    Availability           |        99.999%             |
            +---------------------------+----------------------------+


                    Figure 4: Requirements of AR Assistance

  3.1.2.  Requests to the IETF

     *  Real-time remote monitoring, which requires high-speed
        connectivity

     *  Cloud-based deployment, which requires transmission through
        multiple heterogeneous networks

     *  Cloud-based centralized management

     *  Remote control is jitter sensitive, e.g. less than 100us

     *  Industrial camera images with high definition, with little or no
        compression, which requires high bandwidth

     *  Low end-to-end delay requirements differ from applications and
        services, such as 10ms and 20ms







  Zhao, et al.             Expires 27 August 2026                 [Page 7]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  3.2.  High Experience Video

  3.2.1.  Use Case Description

     High Experience Video refers to video content that delivers an
     exceptional viewing experience through advanced technologies and
     production techniques.  It demands high-quality transmission to
     ensure that the content is delivered without compromising its
     integrity and impact.  High Experience Video relies on deterministic
     networks to deliver the best possible viewing experience, which
     requires a combination of low latency, low jitter, high bandwidth,
     and high reliability.  The typical scenarios of High Experience Video
     involve applications that have high requirements for video quality,
     transmission speed, and user experience such as cloud VR and AR,
     cloud games and cloud live streaming.

  3.2.1.1.  Cloud VR and AR

     Augmented Reality (AR) or Virtual Reality (VR) media applications,
     collectively called eXtended Reality (XR) applications place
     extremely high demands on network transmission including high
     throughput, low latency, and high reliability.  The key feature of
     cloud VR/AR is that content and rendering is on the cloud.  By
     utilizing the cloud capabilities, VR/AR user experience is improved
     and terminal costs are reduced.  Cloud AR/VR services are latency
     sensitivity, and different levels of experience require
     differentiated latency.  Cloud VR/AR rendering and streaming latency
     are divided into three parts: cloud processing, network transmission,
     and terminal processing.  Cloud VR/AR operation latency is divided
     into cloud rendering latency and terminal secondary rendering and
     refresh rendering processes.

     Moreover, AR/VR applications typically involve a large amount of data
     transmission, such as high-definition video streams, real-time
     rendering data.  For some cases, a single packet loss during
     transmission will it affect the integrity of the entire application.
     So AR/VR applications require ultra-low packet loss such as no more
     then 0.001% and for particular packets, it demands zero packet loss.

     The following table describes requirements of Cloud VR/AR.  (These
     metrics are based on 3GPP TR 22.261).










  Zhao, et al.             Expires 27 August 2026                 [Page 8]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  +----------------------+-----------+---------------------+----------------+
  |    Requirement       | Bandwidth |One-way maximum delay|Packet loss rate|
  +----------------------+-----------+---------------------+----------------+
  | Cloud VR/AR Video    |downstream |  50ms               |no more than    |
  |  comfortable         | >75Mbps   |                     |0.001%          |
  |  experience          |           |                     |                |
  +----------------------+-----------+---------------------+----------------+
  | Cloud VR/AR Video    |downstream |  50ms               |no more than    |
  |comfortable experience|>140Mbps   |                     |0.001%          |
  |full perspective      |           |                     |                |
  +----------------------+-----------+---------------------+----------------+
  | Cloud VR/AR strong   |downstream |  15ms               |no more than    |
  |interaction           |>260Mbps   |                     |0.001%          |
  |comfortable experience|           |                     |                |
  |I frame and P frame   |           |                     |                |
  +----------------------+-----------+---------------------+----------------+
  | Cloud VR/AR strong   |downstream |  8ms                |no more than    |
  |interaction           |1Gbps      |                     |0.0001%         |
  |8K ideal experience   |           |                     |                |
  |I frame and P frame   |           |                     |                |
  +----------------------+-----------+---------------------+----------------+

                Figure 5: The Requirements of Cloud VR/AR

  3.2.1.2.  Cloud Games

     Cloud Game is an online gaming technology based on cloud computing
     technology.  Cloud gaming technology enables lightweight devices with
     relatively limited graphics processing and data computing
     capabilities to run high-quality games.  In cloud game scenarios,
     game related computing is not run on the user terminal, but on a
     cloud server, which renders the game scene as a video and audio
     stream and transmits it to the user terminal through the network.
     The user's cloud gaming experience relies on a high-quality, low
     latency network environment.

     The following table describes requirements of Cloud Games:


  +----------------------+-----------+---------------------+----------------+
  |    Requirement       | Bandwidth |One-way maximum delay|Video resolution|
  +----------------------+-----------+---------------------+----------------+
  | Junior level         | >8Mbps    |  150ms              |720P            |
  +----------------------+-----------+---------------------+----------------+
  | 3A professional level| >12Mbps   |  60ms               |1080P           |
  +----------------------+-----------+---------------------+----------------+
  | Level of esports     | >40Mbps   |  60ms               |4K              |
  +----------------------+-----------+---------------------+----------------+



  Zhao, et al.             Expires 27 August 2026                 [Page 9]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


                  Figure 6: Requirements of Cloud Games

  3.2.1.3.  Cloud Live Streaming

     For scenarios such as concerts, press conferences, sports events, and
     live events, cloud live streaming uses 5G uplink high bandwidth to
     transmit 8K/VR videos.  Combined with various applications such as
     video analysis based on live streaming services, character and scene
     recognition, real-time presentation of athlete and event data, and VR
     live streaming interaction, it provides a brand new and rich event
     viewing experience.

     The following table describes requirements of Cloud live streaming:


                 +------------------------+---------------------+
                 | 8K live streaming      |  Attribute          |
                 | 8K video feedback      |                     |
                 +------------------------+---------------------+
                 |     Bandwidth          |  upstream>100Mbps   |
                 |                        |                     |
                 |  One-way maximum delay |  200ms              |
                 |                        |                     |
                 |    Availability        |  99.9%              |
                 |                        |                     |
                 |   Frame rate           |  60                 |
                 +------------------------+---------------------+

                 Figure 7: Requirements of Cloud Live Streaming

  3.2.2.  Requests to the IETF

     *  High requirements for video quality and transmission speed

     *  Cloud processing with real-time interaction

     *  Cloud-based deployment, which requires transmission through
        multiple heterogeneous networks

     *  No jitter requirements

     *  Packet loss is less than 0.001% or zero

     *  End-to-end delay requirements differ from applications and
        services, such as 8ms, 15ms, 50ms, 150ms, 200ms and so on

  3.3.  Intelligent Computing




  Zhao, et al.             Expires 27 August 2026                [Page 10]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  3.3.1.  Use Case Description

     Intelligent computing refers to the integration of artificial
     intelligence (AI) techniques with computational methods to enhance
     the performance, efficiency, and capabilities of computing systems.
     It involves the use of algorithms, machine learning models, and other
     AI approaches to solve complex problems, analyze large datasets, and
     improve decision-making processes.  Intelligent Computing has
     specific requirements for deterministic networks to ensure reliable
     and predictable performance such as predictable latency, low packet
     loss rate, high throughput and reliability.  The typical scenarios
     involve applications such as AI-based scientific research and
     autonomous vehicles and so on.

  3.3.1.1.  Scientific Research

     Intelligent computing is used to provide computing and data analysis
     capabilities, which are crucial for handling large-scale scientific
     simulations and datasets such as astronomy, climate science, and
     bioinformatics.  In scientific research, a large amount of computing
     power resources such as CPU, GPU, memory, and other P-level or higher
     are usually required.  The network needs to provide services for data
     volume of 10G to 100G or above, which requires high bandwidth, high
     reliability and high throughput with ultra-low packet loss.  Many
     applications in scientific research, such as remote observations,
     real-time data analysis, and distributed computing, require networks
     to provide stable low latency and high reliability.  It must provide
     millisecond or even microsecond level latency and jitter guarantees.
     For example, in nuclear fusion experiments, the carrier network is
     required to have 99.999% availability.

     Furthermore, scientific research may require massive data
     transmission between HPCs.  The scenario of thousands of kilometers
     of big data migration mainly refers to the high-throughput
     transmission of massive data between scientific research
     institutions.  At present, research institutions in some countries,
     such as the US ESnet6 and the EU EuroHPC program, are deploying wide
     area RDMA networks to support the construction and operation of high-
     performance computing and data interconnection infrastructure.  In
     this scenario, data transmission is usually carried out regularly or
     in demand, with each transmission ranging from a few terabytes to
     several hundred terabytes, data transmission costs and security are
     both required.








  Zhao, et al.             Expires 27 August 2026                [Page 11]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  3.3.1.2.  Autonomous Vehicles

     Intelligent computing is used in the development of self-driving
     cars, which rely on AI algorithms for perception, decision-making,
     and control.  Autonomous vehicles refers to the technology of
     vehicles that are capable of navigating without the need for human
     input such as identifying other vehicles, pedestrians, and traffic
     signals.  It relies heavily on deterministic forwarding to ensure
     safe, efficient, and reliable operation.  It is also challenging for
     big data management of autonomous driving.  Vehicles record data from
     4K HD cameras, laser scanners, and radars on the road.  Each vehicle
     can generate 80TB of data per day, which requires data-intensive
     transmission.

     V2X (Vehicle-to-Everything) is a fundamental component of the
     autonomous driving ecosystem, providing the necessary communication
     backbone that enables vehicles to interact with their environment in
     a safe and efficient manner.  V2X provides the communication
     infrastructure that enables vehicles to exchange information with
     each other (V2V), with roadside infrastructure (V2I), with
     pedestrians (V2P), and with the network (V2N).  This exchange of
     information is crucial for autonomous vehicles to make informed
     decisions, improve navigation accuracy, and enhance overall road
     safety.  The following table describes requirements of 5G V2X which
     is divided into four scenarios.  (These metrics are based on 3GPP TR
     22.886)


         +----------------------+---------------------+--------------+
         |    Requirement       | Communication Delay | Availability |
         +----------------------+---------------------+--------------+
         | Vehicles Platooning  |    10~25ms          | 99%~99.99%   |
         +----------------------+---------------------+--------------+
         | Extended Sensors     |    3~100ms          | 99%~99.999%  |
         +----------------------+---------------------+--------------+
         | Advanced Driving     |    3~100ms          | 99%~99.999%  |
         +----------------------+---------------------+--------------+
         | Remote Driving       |    5ms              |  99.999%     |
         +----------------------+---------------------+--------------+


               Figure 8: The Requirements of Autonomous Vehicles

  3.3.2.  Requests to the IETF

     *  Real-time communication





  Zhao, et al.             Expires 27 August 2026                [Page 12]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     *  Data-intensive transmission with high-throughput and ultra-low
        packet loss

     *  Low bounded latency, such as us~ms

     *  High availability, such as 99.999%

  3.4.  ISAC-Enabled Smart Factory

  3.4.1.  Use Case Description

     A Smart Factory enabled by Integrated Sensing and Communication
     (ISAC)-enabled cellular networks utilizes Radio Frequency (RF)
     signals (aka Sensing Signals) to construct an environmental mapping,
     detect and track objects, enable precise localization, and facilitate
     collision avoidance for Autonomous Guided Vehicles (AGVs) and robotic
     systems.  ISAC systems encompass one or more Sensing Transmitters
     (Tx) that transmit sensing signals and one or more Sensing Receivers
     (Rx) that generate Sensing Data.  Sensing Data are used in the
     cellular network to describe the detected target objects in shape,
     location, orientation, material, and spatial relationships among each
     other.  Sensing Data are then exposed to the Sensing Service Consumer
     that requested them and are used for real-time monitoring and
     decision-making by a Sensing Service Consumer.  This reduces reliance
     on dedicated sensors while optimizing communication resources.
     Similar use cases have been considered in ETSI ISG ISAC.  The
     described workflow shown in Figure and illustrates a DetNet-enabled
     cellular network as described in 3GPP TS 23.501, that contains core
     network (CN) and Sensing Rxs, e.g., user equipment (UE) or base
     station (BS), and a Sensing Service Consumer operating.


                        Sensing                                     Sensing
  +------------------+  Data    +---------------------------------+ Data    +---------------+
  | Sensing Service  +----------| Cellular Core Network           +---------| Sensing Rx    |
  |                  |          |                                 |         |  (UE, BS)     |
  | Consumer         |          |                                 |         |               |
  +------------------+          |                                 |         +---------------+
                                +---------------------------------+
  \___________________/        \___________________________________________________________/
    DetNet-Enabled                        DetNet-Enabled
    Data Network                          Cellular System


    Figure 9: Sensing Rx in the smart factory generating Sensing Data
       from the Sensing Signals and sending it to a a cellular core
       network and Sensing Service Consumer for real-time decision
                                  making



  Zhao, et al.             Expires 27 August 2026                [Page 13]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     DetNet is critical for ensuring low-latency, bounded jitter, and
     high-reliability exchange of Sensing Data between Sensing Rxs and the
     network.  The Sensing Data extracted from Sensing Signals at the
     Sensing Rx must be delivered deterministically to enable accurate and
     timely control of factory operations, such as predictive maintenance,
     AGVs coordination, safety enforcement, and autonomous route planning
     for AGVs.

  3.4.1.1.  Predictive Maintenance

     Predictive maintenance in a Smart Factory leverages ISAC to detect
     early signs of equipment wear, misalignment, or failures by analyzing
     environmental changes.  The system can monitor machine vibrations,
     structural integrity, and operational anomalies.

     To enable real-time fault detection and proactive maintenance, the
     network must support low-latency, high-reliability, and deterministic
     data delivery to ensure timely analysis and decision-making.  Delays
     or packet loss in Sensing Data transmission can result in missed
     failure indicators, leading to unplanned downtime and costly repairs.


      +--------------+--------------------------------------------------+
      |  Requirement |                Attributes                        |
      +--------------+--------------------------------------------------+
      |Bandwidth     |10Mbps~1Gbps (depending on sensing resolution)    |
      +--------------+--------------------------------------------------+
      |One-way delay |less than 5ms (for real-time anomaly detection)   |
      +--------------+--------------------------------------------------+
      |Maximum jitter|less than 50us(to ensure stable data transmission)|
      +--------------+--------------------------------------------------+
      |Availability  |99.999%(to prevent data loss and ensure           |
      |              |continuous monitoring)                            |
      +-----------------------------------------------------------------+


             Figure 10: The Requirements of Predictive Maintenance

  3.4.1.2.  Real-Time Process Optimization

     In a Smart Factory, real-time process optimization relies on sensing
     to dynamically adjust production parameters, robotic operations, and
     workflow scheduling based on real-time environmental and operational
     data.  Processed Sensing Data measured from Sensing Signals are used
     to provide instantaneous feedback on equipment status, material flow,
     and environmental conditions, enabling adaptive decision-making to
     maximize efficiency and reduce downtime.




  Zhao, et al.             Expires 27 August 2026                [Page 14]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     To ensure precise control and automation, the network must provide
     ultra-low latency, deterministic jitter, and high availability to
     support time-sensitive end-to-end data exchange between sensing
     receivers and the cellular network and between the cellular network
     and the control systems.  Any delay or jitter in data transmission
     can lead to inefficiencies, product defects, or production line
     disruptions.


      +--------------+--------------------------------------------------+
      |  Requirement |                Attributes                        |
      +--------------+--------------------------------------------------+
      |Bandwidth     |100 Mbps~10 Gbps (depending on sensing resolution)|
      +--------------+--------------------------------------------------+
      |One-way delay |less than 1ms (for closed-loop process control)   |
      +--------------+--------------------------------------------------+
      |Maximum jitter|less than 10us(for precise synchronization)       |
      +--------------+--------------------------------------------------+
      |Availability  |99.999%                                           |
      +-----------------------------------------------------------------+


         Figure 11: The Requirements of Real-Time Process Optimization

  3.4.1.3.  Safety Control and Maintenance

     Safety control in a Smart Factory relies on ISAC-enabled RF-based
     sensing to detect potential hazards, such as worker proximity to
     dangerous machinery, unexpected obstacles in AGV paths, or emergency
     situations like fires or equipment failures.  Unlike traditional
     sensor-based systems, ISAC uses Sensing Signals (RF or non-RF) to
     track moving objects, monitor workspaces, and trigger real-time
     safety mechanisms without requiring additional sensing
     infrastructure.

     To ensure instantaneous hazard detection and response, the network
     must support ultra-low latency, high availability, and deterministic
     jitter in and end-to-end fashion to guarantee timely activation of
     emergency protocols, such as stopping machines, rerouting AGVs, or
     alerting human operators.  Any delay or packet loss when exchanging
     Sensing Data between Sensing Rxs and the cellular network or
     exchanging Sensing Results between the cellular network and the
     application could result in serious safety risks, including workplace
     accidents and equipment damage.







  Zhao, et al.             Expires 27 August 2026                [Page 15]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


      +--------------+--------------------------------------------------+
      |  Requirement |                Attributes                        |
      +--------------+--------------------------------------------------+
      |Bandwidth     |100 Mbps~10 Gbps (for real-time updates)          |
      +--------------+--------------------------------------------------+
      |One-way delay |less than 1ms (for immediate hazard response)     |
      +--------------+--------------------------------------------------+
      |Maximum jitter|less than 10us(for precise situation)             |
      +--------------+--------------------------------------------------+
      |Availability  |99.999999%                                        |
      +-----------------------------------------------------------------+


         Figure 12: The Requirements of Real-Time Process Optimization

  3.4.1.4.  Interconnection of Time Sensitive Domains

     Some industrial production environments are basing their internal
     communications on layer-2 Time Sensitive Networking.  The
     deterministic behavior is then constrained into the boundaries of the
     factory domains.

     However, is can be of interest to interconnect such domains for
     centralizing applications or functions relevant to the production
     context.  In order to do so, it is necessary to guarantee
     deterministic behavior as well in the network used for
     interconnecting such domains.

     [5G-ACIA] describes some initial scenarios of DetNet and TSN
     interworking.  The purpose of this use case is to allow the practical
     interconnection of such domains.  The expectation is that the
     interconnection of those domains handle the flows exiting the TSN
     domains providing bounded latency and extremely low losses when
     passing through the DetNet domain in a transparent manner.

  3.4.2.  Requests to the IETF

     To support Smart Factory ISAC use cases, the following enhancements
     to DetNet are required:

     *  Ultra-low latency networking (as low as 1ms) for closed-loop
        control and real-time process optimization.

     *  Stringent jitter requirements (as low as 10us) to support precise
        sensing-based control.

     *  High bandwidth support (up to 10Gbps) for high-resolution sensing
        data transmission.



  Zhao, et al.             Expires 27 August 2026                [Page 16]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     *  High availability (up to 99.999999%) to ensure robust industrial
        operations.

     *  Provide bounded latency for TSN flows

     *  Provide low packet losses, as low as the frame losses in TSN

     *  Requires DetNet and TSN interworking

     DetNet should provide predictable and deterministic communication for
     ISAC-enabled Smart Factories, ensuring timely and precise Sensing
     Data delivery for industrial automation and control operations.

  4.  Use Case Common Themes

  4.1.  Requirements for DetNet Multi-domains

     Many applications require deterministic connectivity that spans
     multiple networks such as industrial automation, professional audio/
     video and electrical utilities described in [RFC8578].  And the
     applications mentioned in this document also have the multi-domains
     requirements for DetNet such as remote control, cloud VR and AR and
     ISAC-enabled smart factory.  These networks may be operated by
     different administrative domains, utilize varying underlying link-
     layer technology domains (e.g.IP/MPLS, TSN, and RAW), or be deployed
     as different control areas to ensure scalability through multiple
     centralized controllers.

     The networks and nodes in local area networks may be interconnected
     with heterogeneous wide area networks such as DetNet and TSN
     interworking.  For example, in ISAC-enabled smart factory, factory
     domains may be interconnected for centralizing applications or
     functions relevant to the production context.  The cross-domain
     scenarios are also particularly important in industrial internet,
     where control systems need to span multiple facilities or production
     lines.  The different administrative domains need to be
     interconnected to achieve unified control over distributed systems,
     enabling efficient resource management and real-time decision-making.
     And cloud-based deployment also requires transmission through
     multiple heterogeneous networks when when organizations need to
     integrate distributed resources and applications across different
     network environments, enabling unified management and seamless
     operation of hybrid cloud architectures.








  Zhao, et al.             Expires 27 August 2026                [Page 17]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     The primary challenge lies in maintaining deterministic behavior
     across domain boundaries, where traffic from one domain must
     seamlessly flow through another domain while preserving bounded
     latency and low packet loss rates.  The
     [I-D.bernardos-detnet-multi-domain-pce] discusses the framework and
     the specific requirements on multi-domain DetNet solutions.

  4.2.  Requirements for DetNet Service Classification

     The above applications differ in the network ranges and SLAs
     requirements such as bounded latency, jitter, bandwidth, availability
     and packet loss.  The classification should consider the
     characteristics such as traffic specification and service
     requirements.  The following table summarizes deterministic
     requirements of industrial internet, cloud video and intelligent
     computing applications, etc.



































  Zhao, et al.             Expires 27 August 2026                [Page 18]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  +---+------------+--------------------+---------------------------------------------------------+
  |   | Use Cases  | Typical            |       Differentiated Deterministic Requirements         |
  |   |            | Applications       +----------+----------+---------+-------------------------+
  |   |            |                    |Bandwidth | Delay    |  Jitter |Packet Loss| Availability|
  +---+------------+--------------------+----------+----------+---------+-----------+-------------+
  | 1 |Industrial  |Machine Vision      |  Low     |  Low     |   N/A   |    N/A    |   Medium    |
  |   |Internet    +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |Remote Control      |  Low     |  Low     |Ultra-low|    N/A    |   High      |
  |   |            +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |AGV Control         |Low~High  |Low~Medium| N/A     |    N/A    | Ultra-high  |
  |   |            +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |AR Assistance       | Low      | Low      |Ultra-low|    N/A    |   High      |
  +---+------------+--------------------+----------+----------+---------+-----------+-------------+
  | 2 |High        |Cloud VR and AR     |Medium    | Low      |  N/A    | Ultra-low |    N/A      |
  |   |Experience  |                    | ~High    |          |         | or zero   |             |
  |   |Video       +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |Cloud Games         | Low      | High     |   N/A   |    N/A    |   N/A       |
  |   |            +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |Cloud Live Streaming| Medium   | High     |   N/A   |    N/A    |   Medium    |
  +---+------------+--------------------+----------+----------+---------+-----------+-------------+
  | 3 |Intelligent |Scientific Research |Ultra-high|  Low     |   N/A   | Ultra-low |  Ultra-high |
  |   |Computing   |                    |          |          |         | or zero   |             |
  |   |            +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |Autonomous Vehicles |Ultra-high|  Low     |   N/A   | Ultra-low |  Ultra-high |
  |   |            |                    |          |          |         | or zero   |             |
  +---+------------+--------------------+----------+----------+---------+-----------+-------------+
  | 4 |ISAC-Enabled|Predictive          | Medium   | Ultra-low|Ultra-low| Ultra-low |    High     |
  |   |Smart       |Maintenance         | ~High    |          |         |           |             |
  |   |Factory     +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |Real-Time Process   | Medium   | Ultra-low|Ultra-low| Ultra-low |    High     |
  |   |            |Optimization        | ~High    |          |         |           |             |
  |   |            +--------------------+----------+----------+---------+-----------+-------------+
  |   |            |Safety Control      | Medium   | Ultra-low|Ultra-low| Ultra-low |    High     |
  |   |            |and Maintenance     | ~High    |          |         |           |             |
  +---+------------+--------------------+----------+----------+---------+-----------+-------------+


            Figure 13: Characteristics of Typical Applications













  Zhao, et al.             Expires 27 August 2026                [Page 19]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     Since the DetNet applications differ in their requirements, it
     demands specific desired deterministic behaviors.  The DetNet flows
     MAY be classified based on the service SLAs requirements of
     applications in scaling networks as per
     [I-D.xiong-detnet-differentiated-detnet-qos].  The flow aggregation
     based on the classification of deterministic services should be taken
     into considerations as discussed in
     [I-D.xiong-detnet-flow-aggregation].  It is required to provide
     latency, bounded jitter and packet loss dynamically and flexibly in
     all scenarios for each characterized flow.

  4.3.  Requirements for Ultra-low or Zero Packet Loss

     Some high-throughput, low-latency applications such as intelligent
     computing demand ultra-low packet loss which is critical to ensure
     real-time data processing, maintain data integrity, optimize resource
     utilization, and support scalable and reliable operations.  And some
     applications such as AR/VR do not fit as payload into a single IP
     packet and may be fragmented into multiple smaller chunks as
     discussed in [I-D.rc-detnet-data-unit-groups].  It demands zero
     packet loss for some chunks while a single packet loss can lead to
     the loss of the whole application.  The DetNet node should provide
     the deterministic behavior to perform any DetNet queuing, shaping,
     scheduling, ordering or dropping to guarantee the packet loss on
     particular packets.

  5.  Security Considerations

     Security considerations for DetNet are covered in the DetNet
     Architecture [RFC8655] and DetNet use cases [RFC8578] and DetNet
     security considerations [RFC9055].

  6.  IANA Considerations

     This document makes no requests for IANA action.

  7.  Acknowledgements

     The authors would like to acknowledge Aihua Liu, Bin Tan, Lou Berger
     and Janos Farkas for their thorough review and very helpful comments.











  Zhao, et al.             Expires 27 August 2026                [Page 20]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  Appendix A.  Simulation Results in Scientific Research

     The throughput of RDMA over network in scientific research
     application is verified with different performances such as distance,
     message size, latency and packet loss.  The simulation result shows
     that, the throughput of RDMA over 1000 kilometers is directly
     proportional to the length of message size, and inversely
     proportional to the network packet loss rate and latency.  To ensure
     80% throughput of links over 100Gbps and 1000 kilometers, the message
     length needs to be greater than 512KB, resulting in extremely strict
     packet loss rate indicators due to increased latency.

  A.1.  Simulation for the Long Distance and Latency

     The impact of long distance and latency on throughput performance is
     shown in Figure 14.  The selection of delay parameters in this
     experiment is mainly aimed at wide area scenarios of 100-2000 km,
     with round trip time (RTT) of 1-20 ms.

     As latency increases (1-20 ms), the RDMA message size needs to be
     continuously increased to achieve high-performance transmission with
     100% throughput.  Due to the maximum message length of 2 GB, a
     bandwidth of 100 Gbit/s can be achieved without loss, satisfying the
     throughput theoretical calculation equation (1).

     Throughput = Window_Size/RTT (1)

     The overall analysis shows that by adjusting RDMA parameters (such as
     message length), high-performance transmission of 1000km (with over
     90% throughput) can be achieved.  The message length setting is
     actually related to the specific network application, device buffer,
     and buffer threshold settings, and the increase of message length is
     unlimited.


















  Zhao, et al.             Expires 27 August 2026                [Page 21]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


   +-------------+--------------------+---------------+--------------------+
   |RTT latency  |message length(byte)|  distance     |Throughput(Gbps)    |
   +-------------+--------------------+---------------+--------------------+
   |less than 1ms|less than 1024      |less than 100km|more than90%@100Gbps|
   +-------------+--------------------+---------------+--------------------+
   |     1ms     |   256K             |     100km     |more than90%@100Gbps|
   +-------------+--------------------+---------------+--------------------+
   |     2ms     |   512K             |     200km     |more than90%@100Gbps|
   +-------------+--------------------+---------------+--------------------+
   |     5ms     |   1M               |     500km     |more than90%@100Gbps|
   +-------------+--------------------+---------------+--------------------+
   |     10ms    |   8M               |     1000km    |more than90%@100Gbps|
   +-------------+--------------------+---------------+--------------------+


        Figure 14: The Impact of Long-distance Delay on Throughput

  A.2.  Simulation for the Latency and Packet Loss

     The traditional RDMA adopts the Go-Back-N retransmission mechanism,
     which retransmits all data packets after the dropped data packet N.
     Loss of packets can cause significant performance degradation in
     RDMA.  However, TCP only needs to retransmit lost individual packets,
     and the latest RDMA network cards have started using selective
     repeat.  Therefore, the calculation formulas for TCP packet loss rate
     (p), latency, and bandwidth can be referred to:

     Throughput = Min{MSS/RTT*C*(1/P)} (2)

     The actual testing performance of RDMA differs from that of TCP, and
     the main impact of wide area networks is latency, with retransmission
     and congestion control algorithm models being similar.  Therefore,
     the theoretical rate of RDMA is empirically judged by adjusting the
     value of parameter C in equation (2) (TCP empirical value C is 1.0).

     When both bigger delay and packet loss coexist and over 80%
     throughput of a 100G link, the packet loss rate in the data center
     must be less than 0.005%. In the scenario of wide area
     interconnection in DCs, due to the increase in retransmission cost
     and response time caused by basical line delay, the packet loss
     threshold is more strict and harsh in the data center, requiring the
     network to achieve lossless as much as possible.  In a wide area
     scenario, even with the optimization algorithm of selective
     retransmission, it is difficult to achieve a bandwidth utilization
     rate of over 70% when the packet loss rate is less than 0.001%.

  References




  Zhao, et al.             Expires 27 August 2026                [Page 22]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


  Informative References

     [I-D.bernardos-detnet-multi-domain-pce]
                Bernardos, C. J., Contreras, L. M., Xiong, Q., and A.
                Mourad, "A PCE-based Control Plane Framework for Multi-
                Domain Deterministic Networking (DetNet)", Work in
                Progress, Internet-Draft, draft-bernardos-detnet-multi-
                domain-pce-00, 16 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-bernardos-
                detnet-multi-domain-pce-00>.

     [I-D.ietf-detnet-scaling-requirements]
                Liu, P., Li, Y., Eckert, T. T., Xiong, Q., Ryoo, J.,
                zhushiyin, and X. Geng, "Requirements for Scaling
                Deterministic Networks", Work in Progress, Internet-Draft,
                draft-ietf-detnet-scaling-requirements-09, 7 September
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                detnet-scaling-requirements-09>.

     [I-D.rc-detnet-data-unit-groups]
                Robitzsch, S. and L. M. Contreras, "Data Unit Groups for
                DetNet-Enabled Networks", Work in Progress, Internet-
                Draft, draft-rc-detnet-data-unit-groups-00, 21 October
                2024, <https://datatracker.ietf.org/doc/html/draft-rc-
                detnet-data-unit-groups-00>.

     [I-D.xiong-detnet-differentiated-detnet-qos]
                Xiong, Q., Zhao, J., Du, Z., Zeng, Q., and C. Liu,
                "Differentiated DetNet QoS for Deterministic Services",
                Work in Progress, Internet-Draft, draft-xiong-detnet-
                differentiated-detnet-qos-01, 27 June 2024,
                <https://datatracker.ietf.org/doc/html/draft-xiong-detnet-
                differentiated-detnet-qos-01>.

     [I-D.xiong-detnet-flow-aggregation]
                Xiong, Q., Jiang, T., and J. Joung, "Flow Aggregation for
                Enhanced DetNet", Work in Progress, Internet-Draft, draft-
                xiong-detnet-flow-aggregation-03, 14 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-xiong-detnet-
                flow-aggregation-03>.

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






  Zhao, et al.             Expires 27 August 2026                [Page 23]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


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

     [RFC8578]  Grossman, E., Ed., "Deterministic Networking Use Cases",
                RFC 8578, DOI 10.17487/RFC8578, May 2019,
                <https://www.rfc-editor.org/info/rfc8578>.

     [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
                "Deterministic Networking Architecture", RFC 8655,
                DOI 10.17487/RFC8655, October 2019,
                <https://www.rfc-editor.org/info/rfc8655>.

     [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
                and J. Hardwick, "Path Computation Element Communication
                Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
                DOI 10.17487/RFC8664, December 2019,
                <https://www.rfc-editor.org/info/rfc8664>.

     [RFC9055]  Grossman, E., Ed., Mizrahi, T., and A. Hacker,
                "Deterministic Networking (DetNet) Security
                Considerations", RFC 9055, DOI 10.17487/RFC9055, June
                2021, <https://www.rfc-editor.org/info/rfc9055>.

     [RFC9320]  Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J.,
                and B. Varga, "Deterministic Networking (DetNet) Bounded
                Latency", RFC 9320, DOI 10.17487/RFC9320, November 2022,
                <https://www.rfc-editor.org/info/rfc9320>.

  Authors' Addresses

     Junfeng Zhao
     CAICT
     China
     Email: zhaojunfeng@caict.ac.cn


     Quan Xiong
     ZTE Corporation
     China
     Email: xiong.quan@zte.com.cn


     Zongpeng Du
     China Mobile
     China
     Email: duzongpeng@chinamobile.com




  Zhao, et al.             Expires 27 August 2026                [Page 24]


  Internet-Draft  Enhanced Use Cases for Scaling Determini   February 2026


     Muhammad Awais Jadoon
     InterDigital
     Email: Muhammad.AwaisJadoon@InterDigital.com


     Luis M. Contreras
     Telefonica
     Email: luismiguel.contrerasmurillo@telefonica.com











































  Zhao, et al.             Expires 27 August 2026                [Page 25]


name: draft-xsaopig-nmop-service-flow-modal-mapping
rev: 04
title: Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol
time: 2025-10-16T06:24:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T06:24:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.458883+00:00
source: ietf
abstract:
  This Internet-Draft specifies a comprehensive framework for mapping
     service flow characteristics to network modal resources in multi-
     modal intelligent computing networks.  It introduces the use of the
     ALTO protocol for collecting service flow data and leverages an SDN
     architecture to separate control and data planes.  The ALTO protocol
     facilitates the acquisition of diverse network state information,
     including data from several SDN domains and dynamic network
     environments, directly from controllers while keeping the provider's
     internal details confidential.  It then transmits the controller's
     decisions using a proven method.  The document details methods for
     characteristic identification, intelligent mapping, and continuous
     optimization, enabling dynamic resource allocation and improved
     network performance.  The framework is designed to support scalable,
     efficient, and secure operations in environments with complex network
     loads and diverse service requirements.

full_text:
  Internet Engineering Task Force                                   H. Zhu
  Internet-Draft             Huazhong University of Science and Technology
  Intended status: Informational                           16 October 2025
  Expires: 19 April 2026


  Architecture for Service Flow Characteristics and Modal Mapping Based on
                           SDN and ALTO Protocol
              draft-xsaopig-nmop-service-flow-modal-mapping-04

  Abstract

     This Internet-Draft specifies a comprehensive framework for mapping
     service flow characteristics to network modal resources in multi-
     modal intelligent computing networks.  It introduces the use of the
     ALTO protocol for collecting service flow data and leverages an SDN
     architecture to separate control and data planes.  The ALTO protocol
     facilitates the acquisition of diverse network state information,
     including data from several SDN domains and dynamic network
     environments, directly from controllers while keeping the provider's
     internal details confidential.  It then transmits the controller's
     decisions using a proven method.  The document details methods for
     characteristic identification, intelligent mapping, and continuous
     optimization, enabling dynamic resource allocation and improved
     network performance.  The framework is designed to support scalable,
     efficient, and secure operations in environments with complex network
     loads and diverse service 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 19 April 2026.







  Zhu                       Expires 19 April 2026                 [Page 1]


  Internet-Draft            Service Flow Mapping              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.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
     2.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     5.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   4
     6.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
       8.1.  Infrastructure Layer  . . . . . . . . . . . . . . . . . .   6
       8.2.  Data Collection Layer . . . . . . . . . . . . . . . . . .   7
       8.3.  Data Processing Layer . . . . . . . . . . . . . . . . . .   7
       8.4.  Analysis & Optimization Layer . . . . . . . . . . . . . .   7
     9.  Service Feature-Network Modal Mapping . . . . . . . . . . . .   7
       9.1.  Service Feature Definition  . . . . . . . . . . . . . . .   7
       9.2.  Modal Definition  . . . . . . . . . . . . . . . . . . . .   7
       9.3.  Mapping Workflow  . . . . . . . . . . . . . . . . . . . .   7
     10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       12.1.  Normative References . . . . . . . . . . . . . . . . . .   8
       12.2.  Informative References . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9











  Zhu                       Expires 19 April 2026                 [Page 2]


  Internet-Draft            Service Flow Mapping              October 2025


  1.  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 available at
     https://datatracker.ietf.org/drafts/current/. Internet-Drafts are
     draft documents valid for a maximum of six months and may be updated,
     replaced, or obsoleted by other documents at any time.  It is
     inappropriate to use Internet-Drafts as reference material or to cite
     them other than as "work in progress."  This Internet-Draft will
     expire on 17 August 2025.

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

  3.  Introduction

     This standard aims to provide a comprehensive and systematic
     specification for mapping service flow characteristics to network
     modal resources in multi-modal intelligent computing networks.  By
     introducing the ALTO protocol to collect service flow characteristic
     data and adopting an SDN architecture that separates the control
     plane from the data plane, this standard supports the creation of
     stable and efficient mapping templates between application service
     flows and modal resources.

  4.  Scope

     This standard applies to designers, developers, and operators of
     multi-modal intelligent computing networks, particularly those
     requiring handling of complex network loads, computing resource
     demands, and data transmission efficiency in vertical industries.  It
     defines methods for extracting critical service flow characteristics
     from applications and achieving effective mapping to network modal
     resources based on these characteristics.




  Zhu                       Expires 19 April 2026                 [Page 3]


  Internet-Draft            Service Flow Mapping              October 2025


  5.  Terms and Definitions

     Intelligent Computing: AI-oriented computing capabilities for
     training and executing AI models.

     Multi-Modal Intelligent Computing Network: A network integrating
     multiple modalities to serve diverse application scenarios, with
     computing as the core and network as the foundation.

     Service Flow: A continuous data transmission process generated by an
     application or service, including unidirectional (e.g., client-server
     requests) or multi-directional interactions (e.g., video
     conferencing).

     Service Flow Characteristics: Metrics describing application
     behavior, including throughput, latency, packet loss rate, CPU/GPU
     utilization, and storage capacity usage across three dimensions:
     storage, network forwarding, and computing.

     Elastic Perception Feature Vector: A scalable vector representation
     dynamically adjusting granularity to characterize multi-dimensional
     service flow characteristics for flexible resource allocation.

     Network Modality: A specific network type or configuration optimized
     for functions such as high bandwidth, low latency, or concurrency.

     Modal Resource: Basic units constituting multi-modal networks (e.g.,
     computing nodes, switching devices).

     Feature-Modal Mapping Mechanism: A technical framework for matching
     service flow characteristics with optimal modal resource
     combinations.

  6.  Abbreviations

     SDN: Software-Defined Networking

     ALTO: Application-Layer Traffic Optimization Protocol

  7.  Overview

     This standard addresses challenges in multi-modal intelligent
     computing networks, including dynamic workloads, heterogeneous
     service requirements, and frequent resource state changes.  Key
     objectives:






  Zhu                       Expires 19 April 2026                 [Page 4]


  Internet-Draft            Service Flow Mapping              October 2025


     1.  Characteristic Identification: Use AI algorithms (e.g., graph
         matching, reinforcement learning) to analyze service flow
         characteristics.

     2.  Intelligent Mapping: Build an SDN/ALTO-based framework for
         dynamic resource allocation.

     3.  Continuous Optimization: Implement feedback loops to refine
         configurations based on real-time monitoring.

  8.  Architecture

     The architecture design refers to[SDN_ALTO_MPTCP].  The architecture
     comprises four layers:





































  Zhu                       Expires 19 April 2026                 [Page 5]


  Internet-Draft            Service Flow Mapping              October 2025


  +------------------------+                   +-------------------------+
  | Data Collection Layer  |                   |      Infrastructure     |
  |  +---------------+     |  (Polling/Event   |  +-------------------+  |
  |  |  ALTO Server  |     |    Triggering)    |  | Computing Network |  |
  |  +---------------+     |<-Monitoring data->|  |  Resource Nodes   |  |
  |  ( Network topology,   |                   |  +-------------------+  |
  | traffic distribution,  |                   |      ( Monitoring/      |
  | link delay/bandwidth,  |                   | configuring resources ) |
  | resource utilization ) |                   +-------------------------+
  +------------------------+                                      ^
    ^                                                             |
    |                                                             |
    +-Service Flow Characteristics-+     +--Configuring policies--+
                                   |     |
                                   v     v
  +-----------------Control Plane ( ALTO Client )-----------------+
  |  +---------------------------+ +---------------------------+  |
  |  |   Data Processing Layer   | | Analysis & Decision Layer |  |
  |  | +-----------------------+ | |   +------------------+    |  |
  |  | | Flow Rules generation | | |   | Analytical Model |    |  |
  |  | +-----------------------+ | |   +------------------+    |  |
  |  | |   Link management     | | |   |  Decision Module |    |  |
  |  | +-----------------------+ | |   +------------------+    |  |
  |  +---------------------------+ +---------------------------+  |
  +---------------------------------------------------------------+
                              ^
                              |
               +--Flow rules--+
               |
               v
      +-------------Data Plane-----------+
      | +------------------------------+ |
      | |        Infrastructure        | |
      | |        +------------+        | |
      | |        | SDN switch |        | |
      | |        +------------+        | |
      | |   ( Forwarding flow rules    | |
      | |  and obtain network status ) | |
      | +------------------------------+ |
      +----------------------------------+

                                 Figure 1

  8.1.  Infrastructure Layer

     Provides hardware resources (computing nodes, switches) to support
     feature extraction and configuration.




  Zhu                       Expires 19 April 2026                 [Page 6]


  Internet-Draft            Service Flow Mapping              October 2025


  8.2.  Data Collection Layer

     Collects real-time metrics: network topology, traffic distribution,
     link latency, CPU/GPU utilization, and storage I/O.  Supports
     polling/event-driven mechanisms via SNMP, NetFlow, etc.

  8.3.  Data Processing Layer

     Constructs service feature topology graphs using adjacency matrices.
     Nodes represent computing/storage metrics; edges represent network
     forwarding metrics.  Employs distributed stream processing and graph
     databases.

  8.4.  Analysis & Optimization Layer

     Performs deep analysis using graph neural networks and reinforcement
     learning to identify optimization strategies (e.g., topology
     adjustments, load balancing).

  9.  Service Feature-Network Modal Mapping

  9.1.  Service Feature Definition

     Defined as three vectors:

     *  Storage: Node-level metrics (e.g., disk I/O).

     *  Network Forwarding: Link-level metrics (e.g., latency).

     *  Compute: Node-level metrics (e.g., CPU utilization).

  9.2.  Modal Definition

     A three-dimensional tensor: {Service Capability, Controllable
     Resources, Operational Logic}.

  9.3.  Mapping Workflow

     The mapping workflow consists of:

     1.  Feature Extraction: Collect real-time metrics across storage,
         compute, and network dimensions.

     2.  Topology Construction: Generate feature graphs with node/edge
         attributes.

     3.  Modal Matching: Align service features with modal resources using
         graph-matching algorithms.



  Zhu                       Expires 19 April 2026                 [Page 7]


  Internet-Draft            Service Flow Mapping              October 2025


     4.  Optimization: Adjust configurations (e.g., path rerouting, load
         migration).

     5.  Feedback: Continuously monitor performance and update mapping
         rules.

     Technical Requirements:

     *  Use distributed optimization frameworks for real-time
        coordination.

     *  Apply reinforcement learning for adaptive decision-making.

  10.  Security Considerations

     The transmission control model employed in this document relies on
     the default security mechanisms provided by SDN and ALTO protocols.
     This draft does not alter the default encryption and authentication
     models as specified in [RFC7149], [RFC7285], [RFC7286] and [RFC7971].
     Therefore, the overall security of the service flow mapping system
     depends on the secure configuration and proper deployment of these
     underlying protocols.

  11.  IANA Considerations

     This memo includes no request to IANA.

  12.  References

  12.1.  Normative References

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

     [RFC7285]  Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
                Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
                Traffic Optimization (ALTO) Protocol", RFC 7285, September
                2014, <http://www.rfc-editor.org/info/rfc7285>.

     [RFC7286]  Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
                H. Song, "Application-Layer Traffic Optimization (ALTO)
                Server Discovery", RFC 7286, November 2014,
                <http://www.rfc-editor.org/info/rfc7286>.






  Zhu                       Expires 19 April 2026                 [Page 8]


  Internet-Draft            Service Flow Mapping              October 2025


     [RFC7971]  Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
                S. Previdi, "Application-Layer Traffic Optimization (ALTO)
                Deployment Considerations", RFC 7971, October 2016,
                <https://www.rfc-editor.org/info/rfc7971>.

  12.2.  Informative References

     [SDN_ALTO_MPTCP]
                Xing, Z., Di, X., and H. Qi, "The SDN-based MPTCP-aware
                and MPQUIC-aware Transmission Control Model using ALTO",
                IEEE ICC 2012, 2024, <https://datatracker.ietf.org/doc/
                draft-xing-nmop-sdn-controller-aware-mptcp-mpquic/>.

     [SDN_ALTO] Gurbani, V. K., Scharf, M., Lakshman, T. V., Hilt, V., and
                E. Marocco, "Abstracting network state in Software Defined
                Networks (SDN) for rendezvous services", IEEE ICC 2012,
                2012, <https://doi.org/10.1109/ICC.2012.6364858>.

  Authors' Addresses

     Huanxing Zhu, Huazhong University of Science and Technology, Wuhan,
     China, Email: huanxingzhu@hust.edu.cn

  Acknowledgements

     This work was supported by the National Key Research and Development
     Program of China under Grant 2023YFB2904100

  Author's Address

     Huanxing Zhu
     Huazhong University of Science and Technology
     Wuhan
     China
     Email: huanxingzhu@hust.edu.cn
















  Zhu                       Expires 19 April 2026                 [Page 9]


name: draft-han-anima-ai-asa
rev: 01
title: Considerations of AI-powered Autonomic Service Agent Communication
time: 2026-01-16T07:22:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-20T07:22:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.463196+00:00
source: ietf
abstract:
  ANIMA defined Autonomic Service Agent to build intelligent management
     functions into network devices, and could interact with each other
     through a standard protocol (aka GRASP).With the rapid advancement of
     Large Language Model (LLM)-driven AI technologies, there is now a
     potential opportunity to enhance the ASA to be AI-powered, thereby
     elevating the intelligence of device-built-in management functions to
     a whole new level.This document analyzes the impact of the AI-powered
     ASA, mostly from the perspective of the ASA communication protocol.

full_text:
  ANIMA                                                        M. Han, Ed.
  Internet-Draft                                             N. Zhang, Ed.
  Intended status: Standards Track                            J. Zhao, Ed.
  Expires: 20 July 2026                                       China Unicom
                                                           16 January 2026


     Considerations of AI-powered Autonomic Service Agent Communication
                         draft-han-anima-ai-asa-01

  Abstract

     ANIMA defined Autonomic Service Agent to build intelligent management
     functions into network devices, and could interact with each other
     through a standard protocol (aka GRASP).With the rapid advancement of
     Large Language Model (LLM)-driven AI technologies, there is now a
     potential opportunity to enhance the ASA to be AI-powered, thereby
     elevating the intelligence of device-built-in management functions to
     a whole new level.This document analyzes the impact of the AI-powered
     ASA, mostly from the perspective of the ASA communication protocol.

  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 20 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



  Han, et al.               Expires 20 July 2026                  [Page 1]


  Internet-Draft  Considerations of AI-powered Autonomic S    January 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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Definition of ASA . . . . . . . . . . . . . . . . . . . .   3
       3.2.  Emergence of AI-powered Agent . . . . . . . . . . . . . .   4
     4.  The Vision of AI-powered ASA  . . . . . . . . . . . . . . . .   4
     5.  Scenarios of AI-powered ASA Communication between Network
             Devices . . . . . . . . . . . . . . . . . . . . . . . . .   4
       5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.2.  Possible Examples . . . . . . . . . . . . . . . . . . . .   5
         5.2.1.  AI Agent based Router for Automatic Congestion
                 Relief  . . . . . . . . . . . . . . . . . . . . . . .   5
         5.2.2.  AI Agent based Router for Automatic Network DDoS
                 Attacks Defense . . . . . . . . . . . . . . . . . . .   5
     6.  Scenarios of AI-powered ASA Communication between Network
             Management Systems and Devices  . . . . . . . . . . . . .   5
       6.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   6
       6.2.  Possible Examples . . . . . . . . . . . . . . . . . . . .   6
         6.2.1.  Coordinated IPv6 Monitoring . . . . . . . . . . . . .   6
     7.  Potential New Requirements of GRASP . . . . . . . . . . . . .   6
       7.1.  The interface and model extension for Prompt with AI
             agent . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       7.2.  Defination of Option for AI-ASA . . . . . . . . . . . . .   7
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
       10.2.  Informative References . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     The ANIMA provides a vision of a network that configures, heals,
     optimizes, and protects itself.  An ASA is defined in [RFC7575] as
     "An agent implemented on an autonomic node that implements an
     autonomic function, either in part (in the case of a distributed
     function) or whole.








  Han, et al.               Expires 20 July 2026                  [Page 2]


  Internet-Draft  Considerations of AI-powered Autonomic S    January 2026


     [RFC9222] proposes guidelines for the design of Autonomic Service
     Agents for autonomic networks.  Autonomic Service Agents, together
     with the Autonomic Network Infrastructure, the Autonomic Control
     Plane, and the GeneRic Autonomic Signaling Protocol, constitute the
     base elements of an autonomic networking ecosystem.

     Large-scale network models have attracted much attention in the field
     of artificial intelligence in recent years.  They integrate the
     advantages of network technology and LLMs and show great potential in
     many fields.  Especially for network operation and maintenance, it is
     demonstrating huge enabling potential and providing innovative
     approaches to solve increasingly complex network operation and
     maintenance problems.

     AI-ASA can achieve more intelligent management functions.  Embedding
     AI-ASA into network devices can enhance operation and maintenance
     efficiency with LLMs.

     This draft analyzes AI-ASA vision and potential functions and
     describes the scenarios of AI-powered ASA Communication between
     Network Devices and Network Management Systems.  The potential new
     requirements of GRASP are also discussed.

  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.

  3.  Background

  3.1.  Definition of ASA

     In [RFC8993], ASA is a process that makes use of the features
     provided by the ANI to achieve its own goals, usually including
     interaction with other ASAs via GRASP [RFC8990] or otherwise.  Of
     course, it also interacts with the specific targets of its function,
     using any suitable mechanism.  Unless its function is very simple,
     the ASA will need to handle overlapping asynchronous operations.  It
     may therefore be a quite complex piece of software in its own right,
     forming part of the application layer above the ANI.

     Autonomic Service Agents, together with the Autonomic Network
     Infrastructure, the Autonomic Control Plane, and the GeneRic
     Autonomic Signaling Protocol, constitute the base elements of an
     autonomic networking ecosystem.



  Han, et al.               Expires 20 July 2026                  [Page 3]


  Internet-Draft  Considerations of AI-powered Autonomic S    January 2026


  3.2.  Emergence of AI-powered Agent

     [I-D.rosenberg-ai-protocols] Intelligent agent, as an important
     concept in the field of artificial intelligence, refers to a system
     that can autonomously perceive the environment, make decisions, and
     execute actions.  It has basic characteristics such as autonomy,
     interactivity, reactivity, and adaptability, and can independently
     complete tasks in complex and changing environments.  Intelligent
     agents can learn and make decisions.

     [I-D.chuyi-nmrg-ai-agent-network] Al Agent, an automated intelligent
     entity capable of interacting with its environment, acquiring
     contextual informationreasoning, self-learning, decision-making,
     executing tasks (autonomously or in collaboration with other Al
     Agents) to achieve

     There are a few examples of AI Agents.

     A travel AI Agent that can help users search for travel destinations
     based on preferences, compare flight and hotel costs, make bookings,
     and adjust plans

     A loan handling agent that can help users take out a loan.  The AI
     Agent can access a user's salary information, credit history, and
     then interact with the user to identify the right loan for the target
     use case the customer has in mind

     A shopping agent for clothing that can listen to user preferences and
     interests, look at prior purchases, and show users different options,
     ultimately helping a user find the right sports coat for an event

     AI Agent in 3GPP, an automated intelligent entity capable of
     interacting with its environment, acquiring contextual
     informationreasoning, self-learning, decision-making, executing tasks
     autonomously or in collaboration with other AI Agents to achieve a
     specific goal

  4.  The Vision of AI-powered ASA

     The AI-powered ASA provides more intelligent operation and management
     of network devices to achieve the Intention-driven network and Auto-
     driven network.

  5.  Scenarios of AI-powered ASA Communication between Network Devices







  Han, et al.               Expires 20 July 2026                  [Page 4]


  Internet-Draft  Considerations of AI-powered Autonomic S    January 2026


  5.1.  General

     The network devices to communicate with other network devices through
     anima's interface.

  5.2.  Possible Examples

  5.2.1.  AI Agent based Router for Automatic Congestion Relief

     In the automatic congestion relief use case, the traditional solution
     relies on built-in intelligent modules in devices to implement
     traffic rerouting via traditional protocols (BGP-LS/BGP-RPD).  Device
     interactions are constrained by predefined protocol rules (e.g.,
     policy triggering based on fixed bandwidth thresholds), lacking
     cross-device historical data sharing and AI model collaboration.
     Policy generation depends solely on local TOP-N traffic modeling,
     unable to adaptively optimize based on real-time traffic patterns.

     When AI-powered Agents are introduced into network devices, AI-
     powered ASA Communication can be established between devices.
     Devices extend BGP-LS to synchronize real-time link bandwidth and
     TOP-N traffic characteristics.  The AI-powered Agents dynamically
     define congestion thresholds based on traffic data, replacing manual
     threshold configuration.  Upon detecting congestion, devices use the
     GRASP protocol to negotiate AI-generated policies (e.g., dynamic
     adjustment of Multi-Exit Discriminator (MED) values) and route
     traffic precisely to lightly loaded links via the BGP Routing Process
     Daemon (BGP RPD).  Reinforcement learning is applied to dynamically
     optimize policy parameters during this process.

  5.2.2.  AI Agent based Router for Automatic Network DDoS Attacks Defense

     With the evolution of attack forms, the Distributed Denial of Service
     (DDoS) Attacks present the features of short-term and high-frequency
     outbreaks, and the attack peak value keeps rising year by year,
     imposing an extreme challenge on the defense response speed.  In
     response to the above attack problems, this document innovatively
     puts forward an edge defense architecture: deploy attack detection
     functions to end devices, achieve second-level flash defense against
     DDoS attacks via intelligent service traffic monitoring, and
     establish an autonomous network DDoS attack defense system.  In the
     meantime, rely on the AI Agent based Router to support the second-
     level discovery and real-time interception of attack behaviors, so as
     to strengthen the network security barrier.

  6.  Scenarios of AI-powered ASA Communication between Network Management
      Systems and Devices




  Han, et al.               Expires 20 July 2026                  [Page 5]


  Internet-Draft  Considerations of AI-powered Autonomic S    January 2026


  6.1.  General

     The network controller communicates with other netwok devices by the
     anima interface or protocol.

  6.2.  Possible Examples

  6.2.1.  Coordinated IPv6 Monitoring

     In the current IPv6 end-to-end traffic monitoring scenario, traffic
     data collection and analysis rely on manual intervention, while the
     large volume of live network traffic data results in high resource
     requirements.  When AI-powered Agents are deployed in network
     controllers and devices, AI-powered ASA communication can be
     established between IDC controllers and edge devices to enable
     hierarchical collaboration.

     The controller's AI-powered Agent module discovers network devices
     via the GRASP protocol, initiates multi-threaded real-time collection
     and monitoring of IPv6/IP traffic data, and performs preliminary
     analysis including flow pattern recognition and IPv6/IPv4 traffic
     ratio trending.  Concurrently, the device-side AI-powered Agent
     collects customer traffic data, decomposes traffic distribution
     characteristics to identify high-value business scenarios, and
     synchronizes these insights to the controller via the GRASP protocol.
     The controller's AI-powered Agent integrates provincial-level traffic
     ingress/egress data to construct regional traffic matrices and
     uploads preliminary analysis results (e.g., internal IDC traffic
     distribution, inter-provincial link utilization) to the IPv6 end-to-
     end monitoring platform.

     The IPv6 end-to-end monitoring platform leverages multi-dimensional
     data models to conduct in-depth analysis on the uploaded traffic data
     and preliminary results, generating final operational decisions such
     as inter-provincial link bandwidth expansion plans and CDN node
     deployment recommendations.  These decisions are then disseminated to
     the controller, which issues configuration instructions to the
     device-side AI-powered Agents via the GRASP API.  Upon receiving the
     instructions, the device's intelligent module invokes relevant
     interfaces to adjust server resources and verifies operational
     effectiveness through self-monitoring threads.

  7.  Potential New Requirements of GRASP

     TBD






  Han, et al.               Expires 20 July 2026                  [Page 6]


  Internet-Draft  Considerations of AI-powered Autonomic S    January 2026


  7.1.  The interface and model extension for Prompt with AI agent

     TBD

  7.2.  Defination of Option for AI-ASA

     TBD

  8.  Security Considerations

     Uncertainty of Current AI Technologies.

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

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

  10.2.  Informative References

     [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
                L., and J. Nobre, "A Reference Model for Autonomic
                Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
                <https://www.rfc-editor.org/info/rfc8993>.

     [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
                Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
                Networking: Definitions and Design Goals", RFC 7575,
                DOI 10.17487/RFC7575, June 2015,
                <https://www.rfc-editor.org/info/rfc7575>.

     [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
                Autonomic Signaling Protocol (GRASP)", RFC 8990,
                DOI 10.17487/RFC8990, May 2021,
                <https://www.rfc-editor.org/info/rfc8990>.





  Han, et al.               Expires 20 July 2026                  [Page 7]


  Internet-Draft  Considerations of AI-powered Autonomic S    January 2026


     [RFC9222]  Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso,
                "Guidelines for Autonomic Service Agents", RFC 9222,
                DOI 10.17487/RFC9222, March 2022,
                <https://www.rfc-editor.org/info/rfc9222>.

     [I-D.rosenberg-ai-protocols]
                Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
                and Requirements for AI Agent Protocols", Work in
                Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
                5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
                rosenberg-ai-protocols-00>.

     [I-D.chuyi-nmrg-ai-agent-network]
                Guo, C., "Large Model based Agents for Network Operation
                and Maintenance", Work in Progress, Internet-Draft, draft-
                chuyi-nmrg-ai-agent-network-02, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-chuyi-nmrg-
                ai-agent-network-02>.

  Authors' Addresses

     Mengyao Han (editor)
     China Unicom
     Beijing
     China
     Email: hanmy12@chinaunicom.cn


     Naihan Zhang (editor)
     China Unicom
     Beijing
     China
     Email: zhangnh12@chinaunicom.cn


     Jing Zhao (editor)
     China Unicom
     Beijing
     China
     Email: zhaoj501@chinaunicom.cn











  Han, et al.               Expires 20 July 2026                  [Page 8]


name: draft-traffic-analysis-and-network-mode-mapping
rev: 01
title: Network Traffic Analysis and Network Modal Mapping Method
time: 2025-09-26T08:22:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-30T08:22:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.467447+00:00
source: ietf
abstract:
  This document presents a framework for network traffic classification
     and modality mapping based on large language models (LLMs),
     addressing the inefficiencies of traditional methods in dynamic
     network environments.  The proposed approach automates multi-
     dimensional traffic feature extraction and intelligent decision-
     making to achieve precise alignment between traffic patterns and
     computing-storage-transmission requirements.  The framework comprises
     two phases: pre-training (generating multi-modal traffic
     representations from pcap data) and mapping (dynamically formulating
     resource allocation strategies).  It supports anomaly detection, QoS
     assurance, and multi-service collaboration, thereby significantly
     enhancing resource utilization efficiency and network service
     performance.

full_text:
  Internet Engineering Task Force                                    H. Yu
  Internet-Draft             Huazhong University of Science and Technology
  Intended status: Experimental                          25 September 2025
  Expires: 29 March 2026


         Network Traffic Analysis and Network Modal Mapping Method
             draft-traffic-analysis-and-network-mode-mapping-01

  Abstract

     This document presents a framework for network traffic classification
     and modality mapping based on large language models (LLMs),
     addressing the inefficiencies of traditional methods in dynamic
     network environments.  The proposed approach automates multi-
     dimensional traffic feature extraction and intelligent decision-
     making to achieve precise alignment between traffic patterns and
     computing-storage-transmission requirements.  The framework comprises
     two phases: pre-training (generating multi-modal traffic
     representations from pcap data) and mapping (dynamically formulating
     resource allocation strategies).  It supports anomaly detection, QoS
     assurance, and multi-service collaboration, thereby significantly
     enhancing resource utilization efficiency and network service
     performance.

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

  Copyright Notice

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





  Yu                        Expires 29 March 2026                 [Page 1]


  Internet-Draft     Traffic Analysis and Modal Mapping     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.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
     2.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       4.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     5.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
     6.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Framework Overview  . . . . . . . . . . . . . . . . . . . . .   5
     8.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       8.1.  Dynamic Resource Allocation . . . . . . . . . . . . . . .   6
       8.2.  Anomaly Detection . . . . . . . . . . . . . . . . . . . .   6
       8.3.  Application-Aware Networking  . . . . . . . . . . . . . .   6
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  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).  This draft
     will expire on 15 July 2025.

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








  Yu                        Expires 29 March 2026                 [Page 2]


  Internet-Draft     Traffic Analysis and Modal Mapping     September 2025


  3.  Introduction

     This document presents a novel framework that employs Large Language
     Models (LLMs) to automate network traffic classification and resource
     mapping.  As network traffic experiences exponential growth,
     infrastructure complexity increases, and vertical industries exhibit
     converged requirements for storage, transmission, and computing
     resources in intelligent computing applications, traditional
     approaches relying on manual feature engineering and static
     classification methods have become inefficient and inadequate for
     dynamic network environments.

     The proposed framework addresses these challenges through the
     following methodology: Raw pcap traffic data is first transformed
     into multi-dimensional feature representations.  These features are
     then processed by LLMs to generate adaptive traffic classification
     models capable of recognizing diverse network flow patterns.
     Subsequently, the framework performs intelligent resource allocation
     by mapping classified traffic types to corresponding network
     requirements (e.g., bandwidth, latency, reliability).  Finally, the
     framework establishes accurate and dynamic mappings between network
     traffic patterns and their corresponding resource requirements
     through continuous learning and optimization mechanisms.

  4.  Scope

     This framework applies to network operators and service providers
     requiring dynamic Quality of Service(QoS) management, anomaly
     detection, and application-aware resource allocation.  It defines
     methodologies for integrating LLMs into traffic analysis pipelines
     and mapping multi-dimensional SFC features to network modalities.

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

  5.  Terms and Definitions

     Pre-training: Pre-training refers to the initial training process of
     a model on large-scale unsupervised data, aiming to learn general
     features and patterns within the data.  This stage typically adopts
     self-supervised learning methods, such as masked language modeling
     (MLM) or autoregressive language modeling (AR).




  Yu                        Expires 29 March 2026                 [Page 3]


  Internet-Draft     Traffic Analysis and Modal Mapping     September 2025


     Fine-tuning: Fine-tuning involves training a pre-trained model on
     supervised data specific to a particular task, allowing it to adapt
     to specialized datasets and improve performance for specific
     applications.

     Pcap: A file format used to store network traffic data for analysis.
     Pcap files record packets transmitted in a network, including source
     and destination addresses, protocol types, payload content, and other
     key information.

     CSV: A file format used for storing structured tabular data.  CSV
     files use commas to separate fields, making them suitable for data
     analysis, machine learning training datasets, and information
     exchange between different applications.

     Large Language Model-A deep learning model with billions or even
     trillions of parameters capable of processing and generating natural
     language text.  LLMs are trained on large-scale text datasets and
     possess abilities such as comprehension, summarization, translation,
     and reasoning.  They are widely used in question-answering systems,
     dialogue generation, text summarization, and other natural language
     processing tasks.

     Multi-level Flow Representation-A method for representing and
     processing network traffic data by extracting features at multiple
     levels, such as packet level, flow level, and session level.  MFR
     enables a more comprehensive analysis of network traffic
     characteristics.

     Low-Rank Adaptation-An efficient fine-tuning method for LLMs that
     introduces low-rank matrices in the parameter space of a pre-trained
     model.  LoRA reduces computational and storage costs while
     maintaining model performance.

     Quality of Service-A network mechanism that ensures performance
     metrics such as throughput, latency, jitter, and packet loss rate
     during data transmission.  QoS is critical for applications that
     require stable and predictable network performance.

     Guaranteed Bit Rate-A QoS mechanism that ensures a minimum bit rate
     for a specific data flow.  GBR is used in applications requiring
     stable bandwidth allocation, such as voice calls and video
     conferencing, to maintain consistent service quality.

     Non-Guaranteed Bit Rate-A QoS mechanism where no minimum bit rate is
     guaranteed for data flows.  Non-GBR is suitable for applications with
     flexible bandwidth needs, such as web browsing and social media.




  Yu                        Expires 29 March 2026                 [Page 4]


  Internet-Draft     Traffic Analysis and Modal Mapping     September 2025


     5G QoS Identifier-A QoS identifier in 5G networks used to
     differentiate various types of traffic and define QoS requirements
     for different services. 5QI helps ensure appropriate network resource
     allocation for applications like high-definition video streaming,
     cloud gaming, and industrial automation.

  6.  Abbreviations

     LLM: Large Language Model

     MFR: Multi-level Flow Representation

     LoRA: Low-Rank Adaptation

     Qos: Quality of Service

     GBR: Guaranteed Bit Rate

     Non-GBR: Non-Guaranteed Bit Rate

     5QI: 5G QoS Identifier

  7.  Framework Overview

     The framework operates in two phases:

     1.  Pre-training Phase: Converts raw pcap data into byte streams, CSV
         features, MFR matrices, and traffic graphs.  Fine-tunes an LLM
         using LoRA to generate a traffic classification model.

     2.  Demand Mapping Phase: Applies the model to classify live traffic
         and maps categories to network modalities (e.g., GBR/Non-GBR) via
         predefined rules.  Continuously optimizes configurations based on
         real-time feedback.

















  Yu                        Expires 29 March 2026                 [Page 5]


  Internet-Draft     Traffic Analysis and Modal Mapping     September 2025


  +-------------+   +-------------------------+  +---------------------+    +--------------------------+
  | Raw Traffic | --> | Byte Stream CSV Features | --> | Large Language Model |  --> | Traffic Classification Model |
  | Data     |       |  MFR Matrix Traffic Graph |   | (Low-Rank Adaptation) |     +--------------------------+
  +-------------+  +--------------------------+  +---------------------+
            |                             |
            V                            V
  +-----------------------------+          +----------------------+
  | Pre-collected Knowledge Base |           | Modal Network Demand |
  | Traffic Characteristics      |     -->   | Mapping Rules        |
  +-----------------------------+          +----------------------+
                          |
                          V
  +------------------+  +------------------+    +-----------------------+  +--------------------------+
  | Demand Mapping  | <--| Traffic Classification |    | Byte Stream, CSV Features | <-- | Raw  Traffic Data |
  | Configuration   |   |   Model                |    | MFR Matrix Traffic Graph  |   +--------------------------+
  +------------------+  +------------------+    +------------------------+
                                                      |
                                                      V
  +-----------------------+     +---------------------------+     +----------------------+
  | Based on User Demand  |      | Traffic Analysis Storage |     | Network Verification |
  | Estimation            |  +   | Transmission Computation |     +----------------------+
  +-----------------------+     +----------------------------+

                                 Figure 1

  8.  Use Cases

  8.1.  Dynamic Resource Allocation

     Prioritizes high-QoS traffic (e.g., video conferencing) by allocating
     guaranteed bandwidth via GBR, while deprioritizing Non-GBR traffic
     (e.g., file downloads).

  8.2.  Anomaly Detection

     Identifies deviations from learned traffic patterns (e.g., DDoS
     attacks) and triggers alerts for mitigation.

  8.3.  Application-Aware Networking

     Maps application-specific traffic (e.g., streaming video) to
     predefined 5QI profiles for optimized QoS.









  Yu                        Expires 29 March 2026                 [Page 6]


  Internet-Draft     Traffic Analysis and Modal Mapping     September 2025


  9.  Security Considerations

     Implementations MUST anonymize pcap data to prevent leakage of
     sensitive information.  LLM models and knowledge bases SHOULD be
     protected against unauthorized access.  Real-time monitoring is
     RECOMMENDED to detect adversarial inputs.

  10.  IANA Considerations

     This document makes no requests to IANA.

  11.  References

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

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

  Authors' Addresses

     Hui Yu Huazhong University of Science and Technology Wuhan, China
     Email: hui_yu@hust.edu.cn

  Author's Address

     Hui Yu
     Huazhong University of Science and Technology
     Wuhan
     China
     Email: hui_yu@hust.edu.cn
















  Yu                        Expires 29 March 2026                 [Page 7]


name: draft-liu-rtgwg-mdt-in-high-bdp
rev: 02
time: 2025-10-11T07:25:50Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-14T07:25:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.471601+00:00
source: ietf
title:
  Use Cases and Requirements of Massive Data Transmission(MDT) in High Bandwidth-delay Product (BDP) Network

abstract:
  This document describes the use cases and related requirements of
      Massive Data Transmission（MDT）in High Bandwidth-delay Product (BDP)
      Network. The MDT framework enables efficient use of nighttime idle
      bandwidth to provide services such as same-day or next-day delivery.
      To meet these objectives, the system introduces a terminal-driven
      intelligent parameter optimization method that adjusts local
      configurations (e.g., disk I/O, NIC bandwidth, TCP buffer) to match
      transmission goals. This document outlines the end-to-end
      architecture and key mechanisms including service identification and
      traffic statistics, network layer load balancing, transmission
      protocol optimization, collaboration between terminal APP, network
      device and controller, etc.

full_text:
  Network Working Group                                       Y. Liu
  Internet Draft                                             R. Pang
  Intended status: Standards Track                      China Unicom 
  Expires: April 10, 2026                           October 11, 2025 
                                                           


           Use Cases and Requirements of Massive Data Transmission（MDT） 
  		       in High Bandwidth-delay Product (BDP) Network
                      
  			      draft-liu-rtgwg-mdt-in-high-bdp-02


  Abstract

      This document describes the use cases and related requirements of 
      Massive Data Transmission（MDT）in High Bandwidth-delay Product (BDP)
      Network. The MDT framework enables efficient use of nighttime idle 
      bandwidth to provide services such as same-day or next-day delivery. 
      To meet these objectives, the system introduces a terminal-driven 
      intelligent parameter optimization method that adjusts local 
      configurations (e.g., disk I/O, NIC bandwidth, TCP buffer) to match 
      transmission goals. This document outlines the end-to-end 
      architecture and key mechanisms including service identification and 
      traffic statistics, network layer load balancing, transmission 
      protocol optimization, collaboration between terminal APP, network 
      device and controller, etc. 
     
  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), its areas, and its working groups.  Note that 
      other groups may also distribute working documents as Internet-
      Drafts.
      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."
      
      The list of current Internet-Drafts can be accessed at 
      http://www.ietf.org/ietf/1id-abstracts.txt
      The list of Internet-Draft Shadow Directories can be accessed at 
      http://www.ietf.org/shadow.html

  Liu, et al.              Expire April 10, 2026              [Page 1]


  Internet-Draft           MDT in High BDP Network            October 2025

  This Internet-Draft will expire on April 10, 2026.

  Copyright Notice

      Copyright (c) 2023 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
      (http://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 Simplified BSD License text as described in
      Section 4.e of the Trust Legal Provisions and are provided without
      warranty as described in the Simplified BSD License.

  Table of Contents
    
  	1. Introduction..................................................2
  	1.1. Requirements Language.......................................3
  	2. Massive data transmission in high BDP network.................3
  	3. Use Cases and Requirements....................................4
  	3.1. Service Identification and Traffic Record...................4
  	3.2. Load Balancing at Network Level.............................5
  	3.3. Optimization of Transmission Protocols......................5
  	3.4. Collaboration Requirements..................................6
  	3.4.1. Collaboration Between Terminal APP and Controller.........6
  	3.4.2. Collaboration Between Network Device and Controller.......6
  	3.4.3. Collaboration Between Network Device and Terminal APP.....6
  	3.4.4. Interface Requirements....................................7
  	4. Security Considerations.......................................7
  	5. IANA Considerations...........................................7
  	6. References....................................................7
  	6.1. Normative References........................................7
  	6.2. Informational References....................................8
  	Authors' Addresses...............................................9

  1. Introduction

  	With the continuous development of industries such as autonomous 
  	driving, AI intelligent computing, and enterprise cloud, the demand 
  	for massive data transmission across wide area networks from edge 
  	data centers/enterprises to core data centers has become 
  	increasingly common, and higher requirements have been put forward 
  	for existing carrier network architectures.In particular, the 
  	implementation of the national "East-to-West Computing Resource
  	
  	
  Liu, et al.              Expire April 10, 2026              [Page 2]


  Internet-Draft           MDT in High BDP Network            October 2025

      Transfer" strategy has significantly increased the frequency and 
      scale of long-distance data migration. Typical scenarios involve the 
      transfer of massive scientific computing data—such as irregularly 
      generated film production materials, periodically uploaded 
      enterprise backup data, and daily astronomical data from facilities 
      like FAST—over thousands of kilometers to intelligent computing 
      centers located in western regions. These data flows are often 
      insensitive to real-time latency but are highly sensitive to overall 
      delivery deadlines.

      Taking the scenarios of supercomputing and intelligent computing as 
  	example, data transmission usually includes two requirements:
  	
  	1) The transmission of training data between intelligent computing 
  	centers, supercomputing centers, and between intelligent computing 
  	centers and supercomputing centers is usually carried by optical
  	networks due to high bandwidth requirements and high connection 
  	stability.
  	
  	2) The transmission of training data and result feedback between 
  	users and intelligent computing centers/supercomputing centers can 
  	be carried through IP networks due to their strong suddenness and 
  	cost sensitivity.
  	
  	While traditional private leased lines can support such Massive Data 
  	Transmission (MDT) demands with reliable bandwidth guarantees, they 
  	often involve rigid billing (e.g., daily/monthly rates), high costs, 
  	and underutilized fixed capacity. As a result, they fail to meet the 
  	flexibility requirements for transmitting large-scale cold or semi-
  	cold data that prioritize cost efficiency and deadline-based 
  	delivery. This leads many data providers to resort to physical 
  	shipment of hard disks as a practical alternative.
  	
  	To address these limitations, MDT is proposed as a flexible, time-
  	sensitive service model that utilizes idle network bandwidth (such 
  	as during nighttime) to deliver large-scale data efficiently—
  	enabling offerings like same-day or next-day delivery guarantees. 
  	Furthermore, terminal-side configuration (including disk type, 
  	network interface card, and TCP buffer size) is found to 
  	significantly affect transmission performance in high Bandwidth-
  	Delay Product (BDP) networks.
  	
  	This draft mainly describes the overall architecture of feasible 
  	solutions for MDT in high BDP network, typical problems that may be 
  	encountered, and proposes potential solutions, including but not 
  	limited to how to perform load balancing scheduling at the global 
  	level of the network to avoid the impact of massive data 
  	transmission on existing network services; how to identify MDT
  	
  Liu, et al.              Expire April 10, 2026              [Page 3]


  Internet-Draft           MDT in High BDP Network            October 2025	
  	
  	services for traffic record and billing purposes; how to 
  	optimize the congestion control algorithm of the transport layer 
  	protocol to ensure that the throughput of TCP protocol can be 
  	improved in long-distance lossy networks.Based on this, this draft 
  	introduces an architecture and supporting mechanisms for MDT, 
  	including: a terminal-driven intelligent parameter tuning method 
  	that dynamically adjusts local configurations to meet transmission 
  	goals; adaptive transmission protocol optimizations (e.g., 
  	congestion control tuning); collaborative scheduling and decision-
  	making mechanisms across endpoints, network controllers, and 
  	transport devices.
  	
  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.
  	
  2. Massive data transmission in high BDP network

      Figure 1 show schematic diagram of the network architecture of MDT in 
      high BDP network, where key functional units include:

      DC/User APP：APP can be deployed on DC/personal terminal devices, 
  	which can be traditional file transfer tools or customized apps
  	developed for MDT scenarios, which implements enhanced functions 
  	such as intelligent data compression, intelligent partitioning, 
  	encryption, etc.
  	
  	Network：existing service carrier networks of current operators, such 
  	as metropolitan area networks, backbone networks, etc.
  	
  	Controller：existing network management system includes controllers, 
  	collaborators, orchestrators, etc, responsible for real-time 
  	resource scheduling, configuration orchestration, and feedback loops.
  	
  Liu, et al.               Expire April 10, 2026              [Page 4]

   
  Internet-Draft           MDT in High BDP Network             October 2025

  	+-----+                             +-----------+            +------+
  	| DC  |<--------------------------->|           |            |Center|
  	| APP |                       |---->|Controller |<-----|     | DC2  |
  	+-----+                       |     +-----------|      |  |->+------+
  	   |                          |             ^          |  |           
  	   |    +------+          |             |          |      |             
  	   |    | Edge |          V             V          V      |            
  	   |--->| DC1  |-\    +-------+   +-------+   +-------+ /         
  		    +------+  \-> |  Edge |   | Core  |   |  Edge |/
  			       		  |       |-->|       |-->|       |
  				 /------> |Network|   |Network|   |Network|    
  				/         +-------+   +-------+   +-------+\   
  	+------+   /                                            \    +------+
  	| User1|--/                                              \-> | User2|
  	| APP  |                                                     | APP  |
  	+------+                                                     +------+
         Figure 1: Architecture of MDT in high BDP network

  3. Use Cases and Requirements

  	MDT service is a predictable time-efficient service that requires 
  	data transmission to be completed within a specified time, not 
  	sensitive to transmission delay, but requires a considerable amount 
  	of network resources. Compared with traditional Internet and private 
  	line services, how to improve transmission efficiency, achieve 
  	service identification, complete scheduling and billing for services 
  	are key issues to be considered.
  	
  3.1. Service Identification and Traffic Record 

  	Before starting transmission, the terminal client collects 
  	environmental parameters (disk speed, NIC bandwidth, TCP buffer 
  	size) and interacts with the controller to communicate task 
  	objectives (data volume, completion time).The controller will 
  	dynamically adjust the network path calculation and private line 
  	bandwidth based on transmission requirements and the current 
  	available link resources of the network, and distribute the 
  	configuration to network nodes.

  	After the transmission task is initiated, network devices need to be 
  	able to identify MDT services and corresponding account information 
  	based on certain identifiers, perform traffic record, and report 
  	the statistical results to the controller. The controller can get 
  	the overall MDT usage of the network, as well as the specific 
  	resource completion status for a particular user, and make 
  	corresponding strategy adjustments. This feedback enables real-time 
  	adjustment and facilitates multi-path selection based on residual 
  	bandwidth rather than only latency.
  	
  	From the above use cases, it can be seen that the billing of MDT 
  	services and the scheduling and allocation of available bandwidth 
  	resources in the current network require network devices to 
  	recognize the current MDT services. APNID defined in [I-D.li-apn-
  	problem-statement-usecases] may be a potential solution to meet the 
  	identification requirements of MDT service.
  	
  Liu, et al.               Expire April 10, 2026              [Page 5]


  Internet-Draft           MDT in High BDP Network             October 2025

  3.2. Load Balancing at Network Level

  	The bandwidth requirement for MDT service is generally between 500M-
  	10G, and the launch of each service requires a huge consumption of 
  	network resources. With the continuous increase of service 
  	launching, how to make reasonable use of network idle resources, 
  	allocate global network resources and data express tasks, and 
  	minimize the impact on existing services have become necessary 
  	issues to consider.
  	
  	The controller notifies the APP of available network resource 
  	information, and the APP dynamically adjusts the data sending 
  	strategy based on the available network bandwidth, and cooperates 
  	with network devices to improve the overall resource utilization of 
  	the network. When the controller discovers a shortage of available 
  	network resources or predicts a rapid growth in future network 
  	traffic, it should notify the APP side in advance to make policy 
  	adjustments.

  	Instead of defaulting to shortest-latency paths, MDT optimizes for 
  	highest bottleneck bandwidth. For example, if two routes exist 
  	between Shanghai and Ningxia—one with lower latency but 1Gbps 
  	bottleneck, and another with 5Gbps bottleneck—the MDT system prefers 
  	the latter to minimize transmission time. This route selection 
  	strategy is influenced by application-level QoS constraints, such as 
  	delivery deadlines, which are translated into required average 
  	throughput. The controller provides resource-aware path evaluations, 
  	and the terminal selects paths that satisfy task goals under cost 
  	constraints.
  	
  	This approach allows MDT services to maximize bandwidth utilization 
  	during off-peak hours, reduce transmission costs, and avoid 
  	contention with latency-sensitive services such as video streaming 
  	or real-time communications.
  	
  3.3. Optimization of Transmission Protocols

  	In most scenarios, the two ends of MDT services need to cross a wide 
  	area network, with a distance of over 1000 km. RTT is in the tens of 
  	MS range, and there is a small amount of packet loss in the network, 
  	which poses new challenges to the traditional TCP [RFC7805]. 
  	Based on current test results, the traditional TCP congestion 
  	control algorithm [RFC2581] may not achieve the expected 
  	transmission rate for MDT. Therefore, an efficient, secure 
  	transmission protocol that can adapt to the current network state 
  	and resource status is needed to solve these problems. The current 
  	network satae, including bandwidth, congestion state, path, etc, can 
  	be measured by ippm and other network state measurement
  	
  Liu, et al.               Expire April 10, 2026              [Page 6]


  Internet-Draft           MDT in High BDP Network             October 2025
  	
  	technologies. The network state can be carried by the ack of 
  	transmission protocols (TCP or QUIC) and also processed in reciever. 
  	By using the network state information, the transmission protocols 
  	can achieve congestion control and traffic control to optimize the 
  	network throughput. 
  	A key innovation is dynamic adjustment of the TCP buffer size using 
  	an iterative algorithm. The system compares the actual average 
  	throughput Ro with the target throughput, and iteratively adjusts 
  	buffer size until the transmission completion time meets the 
  	requirement. Cost estimation is also incorporated, using the 
  	formula: C = β·t + τ·B / 50MB, where β is the unit time cost, and 
  	τ is the per-50MB bandwidth cost. These parameters are selected from 
  	environment configurations such as network interface speed, disk 
  	read/write rate, and measured RTT, and refined through historical 
  	samples and machine learning.
  	
  	The adjustment process supports both static initialization at the 
  	start of the task and dynamic updates during transmission. This 
  	ensures that TCP/QUIC can reach near-optimal throughput even in high 
  	BDP networks with limited user configuration effort.
  		
  3.4. Collaboration Requirements

  	To meet the resource requirements of MDT business while not 
  	affecting existing network services, efficient collaboration between 
  	controllers, terminal APPs, and network devices is required.

  3.4.1. Collaboration Between Terminal APP and Controller

  	The terminal APP needs to authenticate and authorize the controller 
  	to accept scheduling. The APP reports the request for transmission 
  	tasks to the controller, such as the size of the data to be 
  	transmitted, the transmission completion time, the service priority, 
  	etc. The controller recommends one or more configurations, each 
  	including disk/NIC combo, TCP buffer size, start time, estimated 
  	time, and cost. Users may accept risk reminders and receive alerts 
  	during execution to switch plans when necessary.

  3.4.2. Collaboration Between Network Device and Controller
  	
  	The controller needs to get the real-time status of the network 
  	devices and the available bandwidth resources of all links, perform 
  	global routing and bandwidth configuration changes based on the 
  	service demands reported by the APP, and distribute the 
  	configuration to network devices. Network devices report their 
  	operational status, available resource information, and specific MDT
  	
  Liu, et al.              Expire April 10, 2026               [Page 7]


  Internet-Draft           MDT in High BDP Network             October 2025
  	
  	service information to the controller, and receive policy 
  	information provided by the controller.

  3.4.3. Collaboration Between Network Device and Terminal APP

  	The host-network coordination scheme has been increasingly widely 
  	discussed. In this scheme, the network side needs to use some status 
  	information of network nodes, such as CIR, MTU, Link Usage (defined 
  	in RFC 9473), status information of Segment list, etc., and 
  	interprets traffic class markers to prioritize MDT vs. background 
  	flows,to guide the host(APP) to adjust the sending strategy. 

  	The overall principle is that in the scenario of massive data 
  	transmission, the host can select the idle network paths and the 
  	most economical transmission mode flexibly based on the information 
  	provided by the network side, then improve the load utilization of 
  	the network.

  	At the same time, the host needs to notify the network side through 
  	some identification to indicate the APP status ,  and the key 
  	demands for the network node. The network devices can adjust the 
  	strategy based on this information. For example, in order to reduce 
  	the impact on the existing services of the current network, the 
  	priority of some less important service messages should be marked as 
  	not very important. Thus, when congestion occurs, the network 
  	equipment will preferentially discard these messages.

  3.4.4.  Interface Requirements

  	TBD.

  4. Security Considerations

  	TBD.
  	
  5. IANA Considerations

  	TBD.
  	
  Liu, et al.              Expire April 10, 2026               [Page 8]


  Internet-Draft           MDT in High BDP Network             October 2025

  6. References

  6.1. Normative References
  	[RFC7805] Zimmermann, A., Eddy, W., and L. Eggert, "Moving Outdated 
  			  TCP Extensions and TCP-Related Documents to Historic or 
  			  Informational Status", RFC 7805, DOI 10.17487/RFC7805, 
  			  April 2016, <https://www.rfc-editor.org/info/rfc7805>.
  	[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 
  			  Control", RFC 2581, DOI 10.17487/RFC2581, April 1999, 
  			  <https://www.rfc-editor.org/info/rfc2581>.
  	[RFC 9526] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, 
  			  A., and P. Mattes, "Segment Routing Policy Architecture", 
  			  RFC 9256, DOI 10.17487/RFC9256, July 2022, 
  			  <https://www.rfc-editor.org/info/rfc9256>.


  Liu, et al.              Expire April 10, 2026               [Page 7]


  Internet-Draft           MDT in High BDP Network             October 2025


  6.2. Informational References
  	[I-D.li-apn-problem-statement-usecases] Li, Z., Peng, S., Voyer, D., 
  			  Xie, C., Liu, P., Qin, Z., and G. S. Mishra, "Problem 
  			  Statement and Use Cases of Application-aware Networking 
  			  (APN)", Work in Progress, Internet-Draft, draft-li-apn-
  			  problem-statement-usecases-08, 3 April 2023, 
  			  <https://datatracker.ietf.org/doc/html/draft-li-apn-
  			  problem-statement-usecases-08>.
     [I-D.li-apn-header] Li, Z., Peng, S., and S. Zhang, "Application-
                aware Networking (APN) Header", Work in Progress,
                Internet-Draft, draft-li-apn-header-04, 12 April 2023,
                <https://datatracker.ietf.org/doc/html/draft-li-apn-
                header-04>.


  Liu, et al.              Expire April 10, 2026               [Page 9]


  Internet-Draft           MDT in High BDP Network             October 2025


  Authors' Addresses

  	Ying Liu
  	China Unicom
  	China
  	Email: liuy619@chinaunicom.cn
  	
  	Mengyao Han
  	China Unicom
  	China
  	Email: hanmy12@chinaunicom.cn

  	Zheng Ruan
  	China Unicom
  	China
  	Email: ruanz6@chinaunicom.cn



























  Liu, et al.             Expire September 4, 2024              [Page 10]



name: draft-templin-6man-aero3
rev: 60
title: Automatic Extended Route Optimization (AERO)
time: 2026-02-28T17:06:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-01T17:06:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:22.476373+00:00
source: ietf
abstract:
  This document specifies an Automatic Extended Route Optimization
     (AERO) and mobility service for IP internetworking over Overlay
     Multilink Network (OMNI) Interfaces.  AERO/OMNI use IPv6 Neighbor
     Discovery (IPv6 ND) control plane messaging over the OMNI virtual
     link to support secured network admission and OMNI link forwarding.
     Flow-based secure multilink path selection, multinet traversal,
     mobility management, multicast forwarding, multihop operation and
     route optimization are naturally supported through dynamic neighbor
     cache updates.  AERO is a widely-applicable service well-suited for
     air/land/sea/space secure global mobile Internetworking applications
     including aviation, intelligent transportation systems, mobile end
     user devices, space exploration and many others.

full_text:
  Network Working Group                                 F. L. Templin, Ed.
  Internet-Draft                                        The Boeing Company
  Intended status: Standards Track                            1 March 2026
  Expires: 2 September 2026


                Automatic Extended Route Optimization (AERO)
                        draft-templin-6man-aero3-60

  Abstract

     This document specifies an Automatic Extended Route Optimization
     (AERO) and mobility service for IP internetworking over Overlay
     Multilink Network (OMNI) Interfaces.  AERO/OMNI use IPv6 Neighbor
     Discovery (IPv6 ND) control plane messaging over the OMNI virtual
     link to support secured network admission and OMNI link forwarding.
     Flow-based secure multilink path selection, multinet traversal,
     mobility management, multicast forwarding, multihop operation and
     route optimization are naturally supported through dynamic neighbor
     cache updates.  AERO is a widely-applicable service well-suited for
     air/land/sea/space secure global mobile Internetworking applications
     including aviation, intelligent transportation systems, mobile end
     user devices, space exploration and many others.

  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 2 September 2026.

  Copyright Notice

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






  Templin                 Expires 2 September 2026                [Page 1]


  Internet-Draft                    AERO                        March 2026


     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 . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  17
     4.  Automatic Extended Route Optimization (AERO)  . . . . . . . .  17
       4.1.  AERO Node Types . . . . . . . . . . . . . . . . . . . . .  18
       4.2.  The AERO Service over OMNI Links  . . . . . . . . . . . .  19
         4.2.1.  AERO/OMNI Reference Model . . . . . . . . . . . . . .  19
         4.2.2.  AERO Addressing . . . . . . . . . . . . . . . . . . .  23
         4.2.3.  AERO Overlay Routing System . . . . . . . . . . . . .  23
         4.2.4.  Segment Routing Topologies (SRTs) . . . . . . . . . .  24
       4.3.  OMNI Interface Characteristics  . . . . . . . . . . . . .  25
       4.4.  OMNI Interface Initialization . . . . . . . . . . . . . .  28
         4.4.1.  AERO Gateway Behavior . . . . . . . . . . . . . . . .  28
         4.4.2.  AERO Proxy/Server and Relay Behavior  . . . . . . . .  28
         4.4.3.  AERO Client Behavior  . . . . . . . . . . . . . . . .  29
       4.5.  OMNI Interface Neighbor Cache Maintenance . . . . . . . .  29
         4.5.1.  AERO/OMNI Control Plane Messages  . . . . . . . . . .  31
         4.5.2.  OMNI Neighbor Window Synchronization  . . . . . . . .  33
       4.6.  OMNI Interface Encapsulation and Fragmentation  . . . . .  34
       4.7.  OMNI Interface Decapsulation  . . . . . . . . . . . . . .  36
       4.8.  OMNI Interface Data Origin Authentication . . . . . . . .  37
       4.9.  OMNI Interface MTU  . . . . . . . . . . . . . . . . . . .  37
       4.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . .  38
         4.10.1.  Client Forwarding Algorithm  . . . . . . . . . . . .  40
         4.10.2.  Proxy/Server and Relay Forwarding Algorithm  . . . .  41
         4.10.3.  Gateway Forwarding Algorithm . . . . . . . . . . . .  44
       4.11. OMNI Interface Error Handling . . . . . . . . . . . . . .  45
       4.12. AERO Mobility Service Coordination  . . . . . . . . . . .  48
         4.12.1.  AERO Service Model . . . . . . . . . . . . . . . . .  48
       4.13. AERO Address Resolution, Multilink Forwarding and Route
              Optimization . . . . . . . . . . . . . . . . . . . . . .  50
         4.13.1.  Multilink Address Resolution . . . . . . . . . . . .  51
         4.13.2.  Multilink Forwarding . . . . . . . . . . . . . . . .  58
         4.13.3.  Mobile Ad-hoc Network (MANET) Forwarding . . . . . .  64
         4.13.4.  AERO Route Optimization  . . . . . . . . . . . . . .  66
       4.14. Neighbor Unreachability Detection (NUD) . . . . . . . . .  69
       4.15. Mobility Management and Quality of Service (QoS)  . . . .  70



  Templin                 Expires 2 September 2026                [Page 2]


  Internet-Draft                    AERO                        March 2026


         4.15.1.  Registering Link-Layer Information Changes . . . . .  70
         4.15.2.  Deactivating Existing Links  . . . . . . . . . . . .  71
         4.15.3.  Moving Between Proxy/Servers . . . . . . . . . . . .  72
         4.15.4.  Mobility Update Messaging  . . . . . . . . . . . . .  73
         4.15.5.  Accommodating Path Changes . . . . . . . . . . . . .  74
       4.16. Multicast . . . . . . . . . . . . . . . . . . . . . . . .  75
         4.16.1.  Source-Specific Multicast (SSM)  . . . . . . . . . .  75
         4.16.2.  Any-Source Multicast (ASM) . . . . . . . . . . . . .  76
         4.16.3.  Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . .  77
       4.17. Operation over Multiple OMNI Links  . . . . . . . . . . .  77
       4.18. Transition/Coexistence Considerations . . . . . . . . . .  78
       4.19. Proxy/Server-Gateway Bidirectional Forwarding
              Detection  . . . . . . . . . . . . . . . . . . . . . . .  79
       4.20. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . .  79
     5.  Implementation Status . . . . . . . . . . . . . . . . . . . .  79
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  80
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  80
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  83
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  85
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  85
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  87
     Appendix A.  Non-Normative Considerations . . . . . . . . . . . .  93
       A.1.  Implementation Strategies for Route Optimization  . . . .  93
       A.2.  Implicit Mobility Management  . . . . . . . . . . . . . .  94
       A.3.  Direct Underlying Interfaces  . . . . . . . . . . . . . .  94
       A.4.  AERO Critical Infrastructure Considerations . . . . . . .  95
       A.5.  AERO Server Failure Implications  . . . . . . . . . . . .  96
       A.6.  AERO Client / Server Architecture . . . . . . . . . . . .  96
     Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  98
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  99

  1.  Introduction

     Automatic Extended Route Optimization (AERO) fulfills the
     requirements of route optimization [RFC5522] and Distributed Mobility
     Management (DMM) [RFC7333] for air/land/sea/space secure global
     mobile Internetworking applications including aeronautical
     networking, intelligent transportation systems, home network users,
     enterprise mobile device users, space exploration and many others.
     AERO employs the Overlay Multilink Network Interface (OMNI)
     [I-D.templin-6man-omni3] with its Non-Broadcast, Multiple Access
     (NBMA) virtual link model.

     The OMNI link is an adaptation layer virtual overlay manifested by
     IPv6 encapsulation over a network-of-networks concatenation of
     underlay Internetworks.  Nodes on the link can exchange original IP
     packets as single-hop neighbors; both IP protocol versions (IPv4 and
     IPv6) are supported.  The OMNI Adaptation Layer (OAL) supports



  Templin                 Expires 2 September 2026                [Page 3]


  Internet-Draft                    AERO                        March 2026


     multilink operation for increased reliability and path optimization
     while providing fragmentation and reassembly services to support
     performance optimization and Maximum Transmission Unit (MTU)
     diversity.  This specification provides a route optimization and
     mobility service architecture companion to the OMNI specification.

     The AERO service connects Clients as OMNI link end systems via Proxy/
     Servers and Relays as intermediate systems; AERO further employs
     Gateways that interconnect diverse Internetworks as OMNI link
     segments through OAL forwarding at a layer below IP.  Each node's
     OMNI interface supports the operation of IPv6 Neighbor Discovery
     (IPv6 ND) [RFC4861] as the mobility service control message protocol.
     A Client's OMNI interface can be configured over multiple underlay
     interfaces, and therefore appears as a single interface with multiple
     underlay addresses.  These underlay addresses are subject to change
     due to mobility and/or multilink fluctuations, with changes
     propagated by ND messaging the same as for any IPv6 link.

     Clients engage the AERO service according to either the "on-link" or
     "off-link" models for IPv6 Neighbor Discovery over OMNI links as
     discussed in [I-D.templin-6man-omni3].  For destinations that match
     an on-link prefix, the Client performs address resolution and
     neighbor unreachability detection as a network layer function that
     requires IPv6 ND messaging and neighbor cache state coordination
     between the network and adaptation layers.  For destinations that
     match an off-link prefix, the Client forwards packets to a virtual
     router function within the OMNI interface.  The OMNI interface then
     performs IPv6 ND messaging and neighbor state management as an
     adaptation layer service without disturbing the network layer.

     AERO provides a secure virtual link management service where mobile
     node Clients use Proxy/Servers acting as proxys and/or designated
     routers while correspondent nodes on foreign networks use any Relay
     on the link for efficient communications.  Foreign network
     correspondent nodes forward original IP packets destined to other
     AERO nodes via the nearest Relay, which forwards them through the
     cloud.  Mobile node Clients discover shortest paths to OMNI link
     neighbors through AERO route optimization.  Both unicast and
     multicast communications are supported.

     Correspondent nodes on foreign networks configure IP addresses from
     Foreign Network Prefixes (FNPs) advertised by Relays.  Mobile node
     Clients register Mobile Network Prefixes (MNPs) with Mobility Anchor
     Point (MAP) Proxy/Servers to support global mobile Internetworking.

     AERO Gateways peer with Proxy/Servers in a secured private BGP
     overlay routing instance to establish a Segment Routing Topology
     (SRT) virtual spanning tree over the underlay Internetworks of one or



  Templin                 Expires 2 September 2026                [Page 4]


  Internet-Draft                    AERO                        March 2026


     more disjoint administrative domains concatenated as a single unified
     OMNI link.  Each OMNI link instance is characterized by a set of
     Mobility Service Prefixes (MSPs) common to all mobile nodes and from
     which MNP sub-prefixes are derived.  Relays provide an optimal route
     from correspondent nodes on foreign links/networks to mobile or fixed
     nodes on the local OMNI link.  From the perspective of underlay
     Internetworks, each Relay appears as the source of a route to the
     MSP; uplink traffic to mobile nodes is therefore naturally routed to
     the nearest Relay.

     AERO operates over OMNI links that span private-use Internetworks
     and/or the global public IPv4 and IPv6 Internets.  In both cases,
     Clients may be located behind Network Address Translators (NATs) on
     the path to their associated Proxy/Servers and/or peers.  A means for
     supporting robust NAT traversal while avoiding "triangle routing" and
     critical infrastructure traffic concentration is therefore provided
     through a service known as route optimization.

     AERO assumes the use of PIM Sparse Mode in support of multicast
     communication.  In support of Source Specific Multicast (SSM) when a
     Mobile Node is the source, AERO route optimization ensures that a
     shortest-path multicast tree is established with provisions for
     mobility and multilink operation.  In all other multicast scenarios
     there are no AERO dependencies.

     AERO provides a secure aeronautical Internetworking service for both
     manned and unmanned aircraft, where the aircraft is treated as a
     mobile node (MN) that can connect airborne Internet of Things (IoT)
     sub-networks.  AERO is also applicable to a wide variety of other use
     cases.  For example, it can be used to coordinate the links of mobile
     nodes (e.g., cellphones, tablets, laptop computers, etc.) that
     connect into a home enterprise network via public access networks
     with Virtual Private Network (VPN) or open Internetwork services
     enabled according to the appropriate security model.  AERO also
     supports terrestrial vehicular, urban air mobility and mobile
     pedestrian communication services for intelligent transportation
     systems [RFC9365].  Other applicable use cases including home and
     small office networks, enterprise networks and many others represent
     additional large classes of potential AERO/OMNI users.

     Together with OMNI, AERO supports secured optimal routing for the "6
     M's of Modern Internetworking", including:

     1.  Multilink - a mobile node's ability to coordinate multiple
         diverse underlay data links as a single logical unit (i.e., the
         OMNI interface) to achieve the required communications
         performance and reliability objectives.




  Templin                 Expires 2 September 2026                [Page 5]


  Internet-Draft                    AERO                        March 2026


     2.  Multinet - the ability to span the OMNI link over an end to end
         topology connecting multiple diverse administrative domain
         network segments while maintaining seamless communications
         between mobile Clients and correspondents such as air traffic
         controllers, fleet administrators, other mobile Clients, etc.

     3.  Mobility - a mobile node's ability to change network points of
         attachment (e.g., moving between wireless base stations) which
         may result in an underlay interface address change, but without
         disruptions to ongoing communication sessions with peers over the
         OMNI link.

     4.  Multicast - the ability to send a single network transmission
         that reaches multiple nodes belonging to the same interest group,
         but without disturbing other nodes not subscribed to the interest
         group.

     5.  Multihop - a mobile Client peer-to-peer relaying capability
         useful when multiple forwarding hops between peers may be
         necessary to reach a target peer or an infrastructure access
         point connection to the OMNI link.

     6.  (Performance) Maximization - the ability to exchange packets of
         all sizes between peers without loss due to a link size
         restriction, and to adaptively adjust packet sizes to maintain
         the best performance profile for each independent traffic flow.

     The following numbered sections present the AERO specification.  The
     appendices at the end of the document are non-normative.

  2.  Terminology

     The terminology in the normative references applies; especially, the
     OMNI specification terminology [I-D.templin-6man-omni3] and the IPv6
     Neighbor Discovery (IPv6 ND) [RFC4861] node variables, protocol
     constants and message types (including Router Solicitation (RS),
     Router Advertisement (RS), Neighbor Solicitation (NS), Neighbor
     Advertisement (NA), unsolicited NA (uNA) and Redirect) are cited
     extensively throughout.  AERO further introduces a new control
     message termed "Multilink Pilot (MP)" that consists of an ordinary IP
     packet for a flow with an OMNI option trailer.  MP messages are used
     to control adaptation layer functions only and are never exposed to
     the network layer.

     Throughout the document, the simple terms "(Proxy/)Client", "Proxy/
     Server", "Gateway" and "Relay" refer to "AERO/OMNI (Proxy/)Client",
     "AERO/OMNI Proxy/Server", "AERO/OMNI Gateway" and "AERO/OMNI Relay",
     respectively.  Capitalization is used to distinguish these terms from



  Templin                 Expires 2 September 2026                [Page 6]


  Internet-Draft                    AERO                        March 2026


     other common Internetworking uses in which they appear in lower case,
     and implies that the node in question both configures an OMNI
     interface and engages the OMNI Adaptation Layer (OAL).

     The terms "All-Routers multicast", "All-Nodes multicast", "Solicited-
     Node multicast" and "Subnet-Router anycast" are defined in [RFC4291].

     The term "IP" refers generically to either Internet Protocol version
     (IPv4 [RFC0791] or IPv6 [RFC8200]) for specification elements that
     apply equally to both.

     The terms "application layer (L5 and higher)", "transport layer
     (L4)", "network layer (L3)", "(data) link layer (L2)" and "physical
     layer (L1)" are used consistently with common Internetworking
     terminology, with the understanding that reliable delivery protocol
     users of UDP are considered as transport layer elements.  The OMNI
     specification further introduces an "adaptation layer" positioned
     below the network layer but above the link layer, which may include
     physical links and Internet- or higher-layer tunnels.  A (network)
     interface is a node's attachment to a link (via L2), and an OMNI
     interface is therefore a node's attachment to an OMNI link (via the
     adaptation layer).

     The following terms are defined within the scope of this document:

     IPv6 Neighbor Discovery (IPv6 ND)
        a control message service for coordinating neighbor relationships
        between nodes connected to a common link.  AERO uses the IPv6 ND
        messaging service specified in [RFC4861] in conjunction with the
        OMNI extensions specified in [I-D.templin-6man-omni3].

     IPv6 Prefix Delegation (IPv6 PD)
        a networking service for delegating IPv6 prefixes to nodes on the
        link.  AERO nodes apply the IPv6 PD service provided by DHCPv6
        [RFC8415] [RFC9762] in conjunction with OMNI interface IPv6 ND.

     GUA, ULA, LLA, MLA
        A Globally-Unique (GUA), Unique-Local (ULA) or Link-Local (LLA)
        Address per the IPv6 addressing architecture [RFC4193] [RFC4291],
        or a Multilink-Local Address (MLA) per [I-D.templin-6man-mla].
        IPv4 prefixes other than those reserved for special purposes
        [RFC6890] are also considered as GUA prefixes.

     L3
        The Network layer in the OSI reference model, also known as "layer
        3" or the "IP layer".  The Network layer engages the Adaptation
        layer via OMNI interfaces.




  Templin                 Expires 2 September 2026                [Page 7]


  Internet-Draft                    AERO                        March 2026


     Adaptation layer
        An IPv6 encapsulation and fragmentation mid-layer that adapts L3
        to a diverse collection of underlay interfaces.  The adaptation
        layer then engages an underlay network that performs UDP/IP, IP,
        or NULL encapsulation for transmission over underlay interface
        attachments to L2 media.

     L2
        The Data Link layer in the OSI reference model, also known as
        "layer 2" or "link layer".

     Access Network (ANET)
        a connected network region (e.g., an aviation radio access
        network, corporate enterprise network, satellite service provider
        network, cellular operator network, residential WiFi network,
        etc.) that connects Clients to the Mobility Service over the OMNI
        link.  Physical and/or data link level security is assumed and
        sometimes referred to as "protected spectrum" for wireless
        domains.  Private enterprise networks and ground domain aviation
        service networks may provide multiple secured IP hops between the
        Client's point of connection and the nearest Proxy/Server.

     Mobile Ad-hoc NETwork (MANET)
        a connected ANET region for which links often have undetermined
        connectivity properties, lower layer security services cannot
        always be assumed and multihop forwarding between Clients acting
        as MANET routers may be necessary.  AERO and the OMNI link model
        naturally support MANET Internetworking [I-D.templin-manet-inet].

     Internetwork (INET)
        a connected network region with a coherent IP addressing plan that
        provides transit forwarding services between (M)ANETs and AERO/
        OMNI nodes that coordinate with the Mobility Service over
        unprotected media.  No physical and/or data link level security is
        assumed, therefore security must be applied by the network and/or
        higher layers.  The global public Internet itself is an example.

     End-user Network (EUN)
        a simple or complex "downstream" network tethered to a Client as a
        single logical unit that travels together.  The EUN could be as
        simple as a single link connecting a single end system, or as
        complex as a large network with many links, routers, bridges and
        end user devices.  The EUN provides an "upstream" link for
        arbitrarily many low-, medium- or high-end devices dependent on
        the Client for their upstream connectivity, i.e., as Internet of
        Things (IoT) entities.  EUNs can also support a recursively-
        descending chain of additional Clients such that the EUN of an
        upstream Client appears as the (M)ANET of a downstream Client.



  Templin                 Expires 2 September 2026                [Page 8]


  Internet-Draft                    AERO                        March 2026


     *NET
        a "wildcard" term used when a given specification applies equally
        to all MANET/ANET/INET cases.  From the Client's perspective, *NET
        interfaces are "upstream" interfaces that connect the Client to
        the Mobility Service, while EUN interfaces are "downstream"
        interfaces that the Client uses to connect downstream *NETs which
        may connect other Clients.  Local communications between
        correspondents within the same *NET can often be conducted based
        on IPv6 ULAs [RFC4193] or MLAs [I-D.templin-6man-mla].

     underlay network/interface
        a *NET interface over which an OMNI interface is configured.  The
        network layer engages the OMNI interface as an ordinary network
        interface, and the adaptation layer engages each underlay
        interface as a link layer conduit.  The underlay includes UDP/IP,
        IP or NULL encapsulations for data units transferred between the
        adaptation and link layers.

     MANET Interface
        a node's underlay interface to a local network with indeterminant
        neighborhood properties over which multihop relaying may be
        necessary.  All MANET interfaces used by AERO/OMNI are IPv6
        interfaces and therefore must configure a Maximum Transmission
        Unit (MTU) no smaller than the IPv6 minimum MTU (1280 octets) even
        if lower-layer fragmentation is needed.

     OMNI link
        the same as defined in [I-D.templin-6man-omni3].  The OMNI link
        employs IPv6 encapsulation to traverse intermediate systems in a
        spanning tree over underlay network segments the same as a bridged
        campus LAN.  AERO nodes on the OMNI link appear as single-hop
        neighbors at the network layer even though they may be separated
        by many underlay network hops; AERO nodes can employ Segment
        Routing [RFC8402][RFC8754] to cause packets to visit selected
        waypoints within the same OMNI link limited domain.

     OMNI link segment
        a Proxy/Server and all of its constituent Clients within any
        attached *NETs is considered as a leaf OMNI link segment, with
        each leaf interconnected via links and "bridge" nodes in
        intermediate OMNI link segments.  When the *NETs of multiple leaf
        segments overlap (e.g., due to network mobility), they can combine
        to form larger *NETs with no changes to Client-to-Proxy/Server
        relationships.  The OMNI link consists of the concatenation of all
        OMNI link leaf and intermediate segments as a loop-free spanning
        tree.





  Templin                 Expires 2 September 2026                [Page 9]


  Internet-Draft                    AERO                        March 2026


     OMNI interface
        a node's virtual interface to an OMNI link, and configured over
        one or more underlay interfaces.  If there are multiple OMNI links
        in an OMNI domain, a separate OMNI interface is configured for
        each link.  The OMNI interface configures a Maximum Transmission
        Unit (MTU) and an Effective MTU to Receive (EMTU_R) the same as
        any interface.  The OMNI interface assigns an "external" LLA and
        Ethernet link-layer address the same as for any IPv6 interface,
        assigns a different "internal" LLA and link-layer address to
        support a virtual internal router entity, and assigns an MLA for
        adaptation layer addressing over underlay interfaces.  Since OMNI
        interface MLAs are managed for uniqueness and LLAs are used for
        node-local operations only, OMNI interfaces assume Optimistic
        Duplicate Address Detection (DAD) per [RFC4429].

     OMNI Adaptation Layer (OAL)
        an OMNI interface sublayer service that encapsulates original IP
        packets admitted into the interface in an IPv6 header and/or
        subjects them to fragmentation and reassembly.  The OAL is also
        responsible for generating MTU-related control messages as
        necessary, and for providing addressing context for spanning
        multiple segments of an extended OMNI link.

     OMNI Option
        a pseudo IPv6 ND option providing multilink parameters for the
        OMNI interface.  The OMNI option is appended to the end of a
        control message during OAL encapsulation such that it appears
        immediately following the final message option or composite packet
        extension.

     (network) partition
        frequently, underlay networks such as large corporate enterprise
        networks are sub-divided internally into separate isolated
        partitions (a technique also known as "network segmentation").
        Each partition is fully connected internally but disconnected from
        other partitions, and there is no requirement that separate
        partitions maintain consistent Internet Protocol and/or addressing
        plans.  (Each partition appears as a separate OMNI link segment as
        discussed throughout this document.)

     underlay network encapsulation
        OMNI protocol encapsulation of OAL packets/fragments in an outer
        header or headers to form carrier packets that can be routed
        within the scope of the local *NET underlay network partition.
        Common underlay network encapsulation combinations include UDP,
        IP, Ethernet, etc. using a port/protocol/type number for OMNI.





  Templin                 Expires 2 September 2026               [Page 10]


  Internet-Draft                    AERO                        March 2026


     underlay-extended (UNX) address
        an address that appears in encapsulations for an underlay
        interface and also in control message OMNI options.  UNX can be
        either an IP address for IP encapsulations or an IEEE EUI address
        [EUI] for direct data link encapsulation.  (When UDP/IP
        encapsulation is used, the UDP port number is regarded as an
        extension of the IP UNX.)

     original IP packet
        a whole IP packet or fragment admitted into the OMNI interface by
        the network layer prior to OAL encapsulation/fragmentation, or an
        IP packet delivered to the network layer by the OMNI interface
        following OAL reassembly/decapsulation.

     OAL packet
        an original IP packet encapsulated in an OAL IPv6 header with an
        IPv6 Extended Fragment Header extension that includes an 8-octet
        (64-bit) OAL Identification value.  Each OAL packet is then
        subject to fragmentation by the source and reassembly by the
        destination.

     OAL fragment
        a portion of an OAL packet following fragmentation but prior to
        underlay encapsulation, or following underlay decapsulation but
        prior to OAL reassembly.

     OAL atomic fragment
        an OAL packet that can be forwarded without fragmentation, but
        still includes an IPv6 Extended Fragment Header with an 8-octet
        (64-bit) OAL Identification value and with Index and More
        Fragments both set to 0.  (Note that control message atomic
        fragments also omit the Extended Fragment Header over secured
        spanning tree links.)

     carrier packet
        an OAL packet or fragment submitted for underlay interface
        encapsulation.  OAL nodes exchange carrier packets over underlay
        interfaces in a hop-by-hop fashion beginning with the OAL source,
        then continuing over any OAL intermediate nodes and ending with
        the OAL destination.  Each intermediate hop removes the underlay
        encapsulations of the previous hop and inserts underlay
        encapsulations appropriate for the next hop.  Carrier packets may
        themselves be subject to fragmentation and reassembly in some IPv4
        underlay networks at a layer below the OAL.  Carrier packets sent
        over unsecured paths use OMNI protocol underlay encapsulations,
        while those sent over secured paths use security encapsulations
        such as IPsec [RFC4301].




  Templin                 Expires 2 September 2026               [Page 11]


  Internet-Draft                    AERO                        March 2026


     OAL source
        a node that configures an OMNI interface acts as an OAL source
        when it encapsulates original IP packets to form OAL packets, then
        performs OAL fragmentation and underlay encapsulation to create
        carrier packets.  Every OAL source is also an OAL end system.

     OAL destination
        a node that configures an OMNI interface acts as an OAL
        destination when it decapsulates carrier packets, then performs
        OAL reassembly/decapsulation to restore the original IP packet.
        Every OAL destination is also an OAL end system.

     OAL intermediate system
        a node that configures an OMNI interface acts as an OAL
        intermediate system when it decapsulates carrier packets received
        from a first segment to obtain the OAL packet/fragment, then re-
        encapsulates in new underlay headers and sends these new carrier
        packets into the next segment.  OAL intermediate systems decrement
        the Hop Limit in OAL packets/fragments during forwarding, and
        discard the OAL packet/fragment if the Hop Limit reaches 0.  OAL
        intermediate systems do not decrement the TTL/Hop Limit of the
        original IP packet, which can only be updated by the network and
        higher layers.  OAL intermediate systems along the path explicitly
        addressed by the OAL IPv6 Destination (e.g., Proxys, etc.) are
        regarded as "endpoint" intermediate systems while those not
        explicitly addressed (e.g., MANET routers, AERO Gateways, etc.)
        are regarded as "transit" intermediate systems.

     Mobility Service Prefix (MSP)
        an aggregated IP GUA prefix (e.g., 2001:db8::/32,
        2002:192.0.2.0::/40, etc.) assigned to the OMNI link and from
        which more-specific Mobile Network Prefixes (MNPs) are delegated,
        where IPv4 MSPs are represented as "6to4 prefixes" per [RFC3056].
        OMNI link administrators typically obtain MSPs from an Internet
        address registry, however private-use prefixes can alternatively
        be used subject to certain limitations (see:
        [I-D.templin-6man-omni3]).  OMNI links that connect to the global
        Internet advertise their MSPs to interdomain routing peers.

     Mobile Network Prefix (MNP)
        a longer IP GUA prefix derived from an MSP (e.g.,
        2001:db8:1000:2000::/56, 2002:192.0.2.8::/48, etc.) and delegated
        to an AERO Client.








  Templin                 Expires 2 September 2026               [Page 12]


  Internet-Draft                    AERO                        March 2026


     Foreign Network Prefix (FNP)
        a global IP prefix not covered by a MSP and assigned to a link or
        network outside of the AERO/OMNI domain.  Relays advertise any of
        their associated FNPs into the AERO/OMNI routing system and
        forward packets between MNP mobile or fixed nodes on the OMNI link
        and FNP correspondent nodes on other links.

     Subnet Router Anycast (SRA) Address
        An IPv6 address taken from an FNP/MNP in which the remainder of
        the address beyond the final bit of the prefix is set to the value
        "all-zeros".  For example, the SRA for 2001:db8:1::/64 is simply
        2001:db8:1:: (i.e., with the 64 least significant bits set to 0).
        For IPv4, the IPv6 SRA corresponding to the IPv4 prefix
        192.0.2.0/24 is 2002:192.0.2.0::/40 per [RFC3056].

     Interface Identifier (IID)
        the least significant 64 bits of an IPv6 address, as specified in
        the IPv6 addressing architecture [RFC4291].

     AERO node
        a node that is connected to an OMNI link and participates in the
        AERO internetworking and mobility service.

     (AERO) (Proxy/)Client
        an AERO node that configures an OMNI interface over one or more
        underlay interfaces and requests MNP prefix delegations from AERO
        Proxy/Servers.  The Client assigns LLAs and an MLA to the OMNI
        interface for use in IPv6 ND exchanges with other AERO nodes and
        forwards original IP packets to correspondents according to OMNI
        interface neighbor cache state.  The Client coordinates with
        Proxy/Servers and/or other Clients over upstream (M)ANET/INET
        interfaces and may also provide Proxy services for other Clients
        over downstream interfaces.

     (AERO) Proxy/Server
        an AERO node that provides a proxying service between AERO Clients
        and external peers on its Client-facing (M)ANET interfaces (i.e.,
        in the same fashion as for an enterprise network proxy) as well as
        designated router services for coordination with correspondents on
        its INET-facing interfaces.  (Proxy/Servers in the open INET
        instead configure only a single INET interface and no (M)ANET
        interfaces.)  The Proxy/Server configures an OMNI interface and
        maintains BGP peerings with Gateways to provide a local anchor
        point for its stable and/or mobile Clients.

     (AERO) Relay
        an AERO Proxy/Server that provides forwarding services between
        nodes reached via the OMNI link and correspondents on foreign



  Templin                 Expires 2 September 2026               [Page 13]


  Internet-Draft                    AERO                        March 2026


        links/networks.  AERO Relays maintain BGP peerings with Gateways
        the same as Proxy/Servers.  Relays also run a dynamic routing
        protocol to discover any Foreign Network Prefix (FNP) routes in
        service on other links/networks, advertise OMNI link MSP(s) to
        other links/networks, and redistribute FNPs discovered on other
        links/networks into the OMNI link BGP routing system.  (Relays
        that connect to major Internetworks such as the global IPv6 or
        IPv4 Internets can also be configured to advertise "default"
        routes into the OMNI link BGP routing system.)

     (AERO) Gateway
        a BGP hub autonomous system node that also provides OAL forwarding
        services for nodes on an OMNI link.  Gateways forward OAL packets/
        fragments between OMNI link segments as OAL intermediate systems
        while decrementing the OAL IPv6 header Hop Limit but without
        decrementing the network layer IP TTL/Hop Limit.  Gateways peer
        with Proxy/Servers and other Gateways to form an IPv6-based OAL
        spanning tree over all OMNI link segments and to discover the set
        of all FNP/MNP prefixes in service.  Gateways process OAL packets/
        fragments received over the secured spanning tree that are
        addressed to themselves, while forwarding all other OAL packets/
        fragments to the next hop also via the secured spanning tree.
        Gateways forward OAL packets/fragments received over the unsecured
        spanning tree to the next hop either via the unsecured spanning
        tree or via direct encapsulation if the next hop is on the same
        OMNI link segment.  It is important to note that all Gateways are
        also Proxy/Servers, but only those Proxy/Servers configured as
        intermediate nodes in the spanning tree are considered Gateways.

     First-Hop Segment (FHS) Client
        a Client that initiates communications with a target peer by
        sending control messages to establish reverse-path multilink
        forwarding state in OMNI link intermediate systems on the path to
        the target.  Note that in some arrangements the Client's (FHS)
        Proxy/Server (and not the Client itself) initiates the exchange.

     Last-Hop Segment (LHS) Client
        a Client that responds to a communications request from a source
        peer's initiation by returning a response message to establish
        forward-path multilink forwarding state in OMNI link intermediate
        systems on the path to the source.  Note that in some arrangements
        the Client's (LHS) Proxy/Server (and not the Client itself)
        returns the response.








  Templin                 Expires 2 September 2026               [Page 14]


  Internet-Draft                    AERO                        March 2026


     First-Hop Segment (FHS) Proxy/Server
        a Proxy/Server for an FHS Client's underlay interface that
        forwards the Client's OAL packets into the segment management
        topology.  FHS Proxy/Servers also act as intermediate forwarding
        systems to facilitate RS/RA exchanges between a Client and its MAP
        Proxy/Server.

     Last-Hop Segment (LHS) Proxy/Server
        a Proxy/Server for an underlay interface of an LHS Client that
        forwards OAL packets received from the segment management topology
        to the Client over that interface.

     Mobility Anchor Point (MAP) Proxy/Server
        a Proxy/Server selected by a Client that injects the Client's MNP
        into the BGP routing system and provides both forwarding and
        mobility services for any *NET underlay interfaces that register
        the MNP.  Clients often select the first FHS Proxy/Server they
        coordinate with to serve in the MAP role as all FHS Proxy/Servers
        are equally capable candidates to serve as a MAP.  The Client can
        instead select any available Proxy/Server for the OMNI link as
        there is no requirement that the MAP must also be one of the
        Client's FHS Proxy/Servers.  This flexible arrangement supports a
        fully distributed mobility management service.

     Segment Routing Topology (SRT)
        a Multinet OMNI link forwarding region between FHS and LHS Proxy/
        Servers.  FHS/LHS Proxy/Servers and SRT Gateways span the OMNI
        link on behalf of communicating peer nodes.  The SRT maintains a
        spanning tree established through BGP peerings between Gateways
        and Proxy/Servers.  Each SRT leaf segment includes Gateways in a
        "hub" and Proxy/Servers in "spokes", while adjacent segments are
        interconnected by Gateway-Gateway peerings.  The BGP peerings are
        configured over both secured and unsecured underlay network paths
        such that a secured spanning tree is available for critical
        control messages while other messages can use the unsecured
        spanning tree.

     Address Resolution Source (ARS)
        the node nearest the original source that initiates OMNI link
        address resolution.  The ARS may be a Proxy/Server or Relay for
        the source, or may be the source Client itself.  The ARS is often
        (but not always) also the same node that becomes the FHS source
        during route optimization.








  Templin                 Expires 2 September 2026               [Page 15]


  Internet-Draft                    AERO                        March 2026


     Address Resolution Target (ART)
        the node toward which address resolution is directed.  The ART may
        be a Relay or the target Client itself.  The ART is often (but not
        always) also the same node that becomes the LHS target during
        route optimization.

     Address Resolution Responder (ARR)
        the node that responds to address resolution requests on behalf of
        the ART.  The ARR may be a Relay, the ART itself, or the ART's
        current MAP Proxy/Server.  Note that a MAP Proxy/Server can assume
        the ARR role even if it is located on a different SRT segment than
        the ART.  The MAP Proxy/Server assumes the ARR role only when it
        receives an RS message from the ART with the 'ARR' flag set (see:
        [I-D.templin-6man-omni3]).

     Potential Router List (PRL)
        a geographically and/or topologically referenced list of addresses
        of all Proxy/Servers within the same OMNI link segment.  Each OMNI
        link segment has its own PRL.

     Distributed Mobility Management (DMM)
        a BGP-based overlay routing service coordinated by Proxy/Servers
        and Gateways that tracks all Proxy/Server-to-Client associations.

     Mobility Service (MS)
        the collective set of all Proxy/Servers, Gateways and Relays that
        provide the AERO Service to Clients.

     flow
        a sequence of packets sent from a particular source to a
        particular unicast, anycast, or multicast destination that a node
        desires to label as a flow.  The 3-tuple of (Source Address,
        Destination Address, Flow Label) enables efficient IPv6 flow
        classification.  The IPv6 Flow Label Specification is observed per
        [RFC6437] [RFC6438].

     AERO Flow Information Base (AFIB)
        A multilink forwarding table on each OAL source, destination and
        intermediate system that includes AERO Flow Vectors (AFV) with
        both next hop forwarding instructions and context for
        reconstructing compressed headers for specific underlay interface
        pairs used to transport flows from a source to a destination.

     AERO Flow Vector (AFV)
        An AFIB entry that includes soft state for each underlay interface
        pairwise communication flow from source to destination.  AFVs are
        identified by an AFV Index (AFVI) paired with the previous hop
        underlay address, with the pair established based on adaptation



  Templin                 Expires 2 September 2026               [Page 16]


  Internet-Draft                    AERO                        March 2026


        layer control messaging.  The AFV also caches underlay interface
        pairwise Identification sequence number parameters to support
        carrier packet filtering.

     AERO Flow Vector Index (AFVI)
        A 2-octet or 4-octet integer value supplied by a previous hop OAL
        node when it requests a next hop OAL node to create an AFV.  (The
        AFVI is always processed as a 4-octet value, but compressed
        headers may omit the 2 most significant octets when they encode
        the value 0.)  The next hop OAL node caches the AFVI and underlay
        address supplied by the previous hop as header compression/
        decompression state for future OAL packets with compressed
        headers.  The previous hop OAL node must ensure that the AFVI
        values it assigns to the next hop via a specific underlay
        interface are distinct and reused only after their useful
        lifetimes expire.  The special value 0 means that no AFVI is
        asserted.

  3.  Requirements

     OMNI interfaces should limit the size of their control plane messages
     to the adaptation layer path MTU which may be as small as the minimum
     IPv6 link MTU minus encapsulation overhead.  If there are sufficient
     OMNI parameters and/or IP packet attachments that would exceed this
     size, the OMNI interface forwards the information as multiple smaller
     control messages and the recipient accepts the union of all
     information received.  This allows the messages to travel without
     loss due to a size restriction over secured control plane paths that
     include IPsec tunnels [RFC4301], secured direct point-to-point links
     and/or unsecured paths that require an authentication signature.

     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.

  4.  Automatic Extended Route Optimization (AERO)

     The following sections specify the operation of IP over OMNI links
     using the AERO service:










  Templin                 Expires 2 September 2026               [Page 17]


  Internet-Draft                    AERO                        March 2026


  4.1.  AERO Node Types

     AERO (Proxy/)Clients can be deployed as fixed infrastructure nodes
     close to end systems, or as Mobile Nodes (MNs) that can change their
     network attachment points dynamically.  AERO Clients configure OMNI
     interfaces over underlay interfaces with addresses that may change
     due to mobility.  AERO Clients that obtain MNPs register them with
     the AERO service, and distribute the MNPs to EUNs (which may connect
     other Clients).  AERO Clients can also provide Proxy services for
     other Clients on downstream-attached networks.

     AERO Gateways, Proxy/Servers and Relays are infrastructure elements
     in *NET boundary (or standalone INET) deployments and hence have INET
     addresses that rarely (if ever) change.  Together, they provide
     access to the AERO service OMNI link virtual overlay for connecting
     AERO Clients.  AERO Gateways (together with Proxy/Servers and Relays)
     provide the secured backbone supporting infrastructure for an OMNI
     link Segment Routing Topology (SRT) spanning tree.

     AERO Gateways are Proxy/Servers deployed as OMNI link intermediate
     systems that forward packets both within the same SRT segment and
     between disjoint SRT segments based on an IPv6 encapsulation mid-
     layer known as the OMNI Adaptation Layer (OAL).  The OMNI interface
     and OAL provide an adaptation layer forwarding service that the
     network layer perceives as L2 bridging, since the inner IP TTL/Hop
     Limit is not decremented.  Each Gateway peers with Proxy/Servers,
     Relays and other Gateways in a dynamic routing protocol instance as a
     Distributed Mobility Management (DMM) service for the list of active
     MLAs and MNPs (see: Section 4.2.3).  Gateways assign one or more
     Mobility Service Prefixes (MSPs) to the OMNI link and configure IPsec
     tunnels with Proxy/Servers, Relays and other Gateways; they further
     maintain forwarding table entries for each MLA/FNP/MNP in service on
     the OMNI link.

     AERO Proxy/Servers distributed across one or more SRT segments
     provide default forwarding and mobility/multilink services for AERO
     Client mobile nodes.  Each Proxy/Server acts as either an OMNI link
     intermediate system or end system according to the service model
     selected by the Client.  Each Proxy/Server also peers with Gateways
     in an adaptation layer dynamic routing protocol instance to advertise
     its list of associated MLAs/MNPs (see: Section 4.2.3).  MAP Proxy/
     Servers provide prefix delegation services and track the mobility/
     multilink profiles of each of their associated Clients, where each
     delegated prefix becomes an MNP taken from an MSP.  Proxy/Servers at
     *NET boundaries provide a primary forwarding service for (M)ANET
     Client communications with peers in external INETs.  Proxy/Servers in
     open INETs provide an authentication service for control messages but
     should be considered as a less preferred data plane forwarding



  Templin                 Expires 2 September 2026               [Page 18]


  Internet-Draft                    AERO                        March 2026


     service when a Client cannot forward directly to an INET peer.
     Source Clients securely coordinate with target Clients by sending
     control messages via a First-Hop Segment (FHS) Proxy/Server which
     forwards them over the SRT spanning tree to a Last-Hop Segment (LHS)
     Proxy/Server which finally forwards them to the target.

     AERO Relays are Proxy/Servers that provide forwarding services to
     exchange original IP packets between the OMNI link and fixed or
     mobile nodes on other links/networks.  Relays run a dynamic routing
     protocol to discover any FNP prefixes in service on foreign links/
     networks, and Relays that connect to larger Internetworks (such as
     the Internet) may originate default routes.  The Relay redistributes
     OMNI link MSP(s) into other links/networks, and redistributes FNPs
     via OMNI link Gateway BGP peerings.

  4.2.  The AERO Service over OMNI Links

  4.2.1.  AERO/OMNI Reference Model

     Figure 1 presents the basic OMNI link reference model:

                           +-----------------+
                           | AERO Gateway G1 |
                           | Nbr: S1, S2, P1 |
                           |(X1->S1; X2->S2) |
                           |      MSP M1     |
                           +--------+--------+
         +--------------+           |            +--------------+
         |  AERO P/S S1 |           |            |  AERO P/S S2 |
         |  Nbr: C1, G1 |           |            |  Nbr: C2, G1 |
         |  default->G1 |           |            |  default->G1 |
         |    X1->C1    |           |            |    X2->C2    |
         +-------+------+           |            +------+-------+
                 |       OMNI link  |                   |
         X===+===+==================+===================+===+===X
             |                                              |
       +-----+--------+                            +--------+-----+
       |AERO Client C1|                            |AERO Client C2|
       |    Nbr: S1   |                            |   Nbr: S2    |
       | default->S1  |                            | default->S2  |
       |    MNP X1    |                            |    MNP X2    |
       +------+-------+                            +-----+--------+
              |                                          |
             .-.                                        .-.
          ,-(  _)-.     +-------+     +-------+      ,-(  _)-.
       .-(_  IP   )-.   |IP end |     |IP end |    .-(_  IP   )-.
     (__     EUN     )--|system |     |system |--(__     EUN     )
        `-(______)-'    +-------+     +-------+     `-(______)-'



  Templin                 Expires 2 September 2026               [Page 19]


  Internet-Draft                    AERO                        March 2026


                      Figure 1: AERO/OMNI Reference Model

     In this model:

     *  the OMNI link is an overlay network service configured over one or
        more underlay SRT segments which may be managed by diverse
        administrative domains using incompatible protocols and/or
        addressing plans.

     *  AERO Gateway G1 aggregates Mobility Service Prefix (MSP) M1,
        discovers Mobile Network Prefixes (MNPs) X* and advertises the MSP
        via BGP peerings over secured tunnels to other Gateways in the SRT
        (not shown).  Together, the set of all Gateways provide the
        backbone for an SRT spanning tree for the OMNI link.

     *  AERO Proxy/Servers S1 and S2 configure secured tunnels with
        Gateway G1 and also provide mobility, multilink, multicast and
        default router services for the MNPs of their associated Clients
        C1 and C2.  (Proxy/Servers that act as Relays can also advertise
        FNP routes for non-mobile correspondent nodes the same as for MNP
        Clients.)

     *  AERO Clients C1 and C2 associate with Proxy/Servers S1 and S2,
        respectively.  They receive MNP delegations X1 and X2, and also
        act as default routers for their associated physical or internal
        virtual EUNs.  (While not shown, AERO Clients can also be
        recursively nested in an arbitrarily-deep chain of (Proxy/)Clients
        between a Proxy/Server and the ultimate IP end systems.)

     *  IP end systems attach to the EUNs served by Clients C1 and C2,
        respectively.  (Although not depicted here, there may be multiple
        Proxy/Client intermediate systems between Clients C1 and C2 and
        the ultimate IP end systems.)

     An OMNI link configured over a single underlay network appears as a
     single unified link with a consistent addressing plan; all nodes on
     the link can exchange carrier packets via simple underlay
     encapsulation (i.e., following any necessary NAT traversal) since the
     underlay is connected.  In common practice, however, OMNI links are
     often configured over an SRT spanning tree that bridges multiple
     distinct underlay network segments managed under different
     administrative authorities (e.g., as for worldwide aviation service
     providers such as ARINC, SITA, Inmarsat, etc.).  Individual underlay
     networks may also be partitioned internally, in which case each
     internal partition appears as a separate segment.






  Templin                 Expires 2 September 2026               [Page 20]


  Internet-Draft                    AERO                        March 2026


     The addressing plan of each SRT segment is consistent internally but
     will often bear no relation to the addressing plans of other
     segments.  Each segment is also likely to be separated from others by
     network security devices (e.g., firewalls, proxys, packet filtering
     gateways, etc.), and disjoint segments often have no common physical
     link connections.  Therefore, nodes can only be assured of exchanging
     carrier packets directly with correspondents in the same segment, and
     not with those in other segments.  The only means for joining the
     segments therefore is through inter-domain peerings between AERO
     Gateways.

     The OMNI link spans multiple SRT segments using the OAL to provide
     the network layer with a virtual abstraction similar to a bridged
     campus LAN.  The OAL is an OMNI interface sublayer that inserts a
     mid-layer IPv6 encapsulation header for inter-segment forwarding
     (i.e., bridging) without decrementing the network layer TTL/Hop Limit
     of the original IP packet.  An example OMNI link SRT is shown in
     Figure 2:

      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
    .                                                                           .
   .                                                                             .
   .     .-(::::::::)                .-(::::::::)               .-(::::::::)     .
   .  .-(::::::::::::)-.   +-+    .-(::::::::::::)-.   +-+   .-(::::::::::::)-.  .
   . (::::    FHS    :::)--|G|--(::: Intermediate ::)--|G|--(::::    LHS    :::) .
   .  `-(::::::::::::)-'   +-+    `-(::Segments::)-'   +-+   `-(::::::::::::)-'  .
   .     `-(::::::)-'                `-(::::::)-'               `-(::::::)-'     .
   .           |                                                      |          .
   .         +---+                                                  +---+        .
   .         |P/S|                                                  |P/S|        .
   .         +---+                                                  +---+        .
   .           |                                                      |          .
   .     .-(::::::::)                                          .-(::::::::)      .
   .  .-(: First Hop :)-.  +-------+             +-------+   .-(: Last Hop :)-.  .
   . (::::  Access  ::::)--| Source|             | Target|--(::::  Access  ::::) .
   .  `-(:: Network ::)-'  | Client|             | Client|     (:: Network ::)-' .
   .     `-(::::::)-'      +-------+             +-------+      `-(::::::)-'     .
   .                                                                             .
   .                                                                             .
   .         <--  Segment Routing Topology (SRT) Spanned by OMNI Link -->        .
     .                                                                          .
       . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

            Figure 2: OMNI Link Segment Routing Topology (SRT)

     In the Segment Routing Topology, a source Client connects via a first
     hop access network served by a First Hop Segment (FHS) Proxy/Server.
     The FHS Proxy/Server then forwards to an FHS Gateway which connects



  Templin                 Expires 2 September 2026               [Page 21]


  Internet-Draft                    AERO                        March 2026


     to an arbitrarily complex set of Intermediate Segments.  Adjacent
     intermediate Segments are joined by intermediate Gateways (not shown)
     that serve as adaptation layer IPv6 routers, with the final segment
     connected by a Last Hop Segment (LHS) Gateway.  The LHS Gateway then
     forwards to an LHS Proxy/Server which in turn connects to the last
     hop access network where the target Client resides.

     Gateway, Proxy/Server and Relay OMNI interfaces are configured over
     both secured tunnels and open INET underlay interfaces within their
     respective SRT segments.  Within each segment, Gateways configure
     "hub-and-spokes" BGP peerings with Proxy/Servers and Relays as
     "spokes".  Adjacent SRT segments are joined by Gateway-to-Gateway
     peerings to collectively form a spanning tree over the entire SRT.
     The "secured spanning tree" supports authentication and integrity for
     critical control plane messages (and any trailing data plane message
     extensions).  The "unsecured spanning tree" conveys ordinary carrier
     packets without security codes and that must be examined by
     destinations according to data origin authentication procedures.
     AERO nodes can employ route optimization to cause carrier packets to
     take more direct paths between OMNI link neighbors without having to
     follow strict spanning tree paths.

     The network of networks concept emerged from the earliest days of
     Internetworking [CERF1][KAHN][POUZIN].  The concept has carried
     forward to the present day where the Internet has become successful
     beyond measure.  The AERO Multinet service concatenates SRT segments
     through Gateway-to-Gateway peerings as first suggested in
     "Interconnection of Packet switching Networks" [POUZIN] and later
     formalized in the "Catenet Model for Internetworking (IEN48)"
     [CERF2].  The catenet model in particular suggests an interconnection
     of independent and diverse packet switching network "segments" to
     form a much larger Internetwork supporting end-to-end services.

     The catenet vision faded into obscurity as the Internet evolved in
     the decades that followed, and the adaptation layer was omitted from
     the architecture.  As a result, the Internet has flourished as a
     monolithic public routing and addressing service interconnecting
     private domains leading to the rise of the middle (including NATs)
     and a diminished role for end-to-end [RFC3724].  The adaptation layer
     manifested by AERO and OMNI now promises to restore the best aspects
     of end-to-end through incremental deployment of catenet constructs in
     the modern Internet.









  Templin                 Expires 2 September 2026               [Page 22]


  Internet-Draft                    AERO                        March 2026


  4.2.2.  AERO Addressing

     AERO nodes on OMNI links assign an external Link-Local Address (LLA)
     and link-layer address on the OMNI interface as required by
     [RFC4861].  AERO nodes also assign different internal LLA and link-
     layer addresses to support the operation of an adaptation layer
     internal virtual router entity.

     AERO nodes assign a Multilink Local Address (MLA) to the OMNI
     interface per [I-D.templin-6man-mla].  The node assigns an MLA to an
     OMNI interface the same as suggested for "sites" in the IPv6 scoped
     addressing architecture [RFC4007], i.e., as a single adaptation layer
     address assigned to a virtual interface configured over potentially
     multiple underlying interfaces.

     MLAs are considered as adaptation layer addresses in the architecture
     and can appear as OAL encapsulation addresses, but nodes may also use
     them as the Source and Destination Addresses of original IP packets
     exchanged between peers within the same OMNI link limited domain.
     Each original IP packet with MLA addresses is subject to OAL
     encapsulation with an IPv6 header that also uses MLA addresses.

     AERO Clients receive Mobile Network Prefix (MNP) delegations during
     Proxy/Server RS/RA exchanges and assign the MNPs to EUN interfaces.

     AERO MSPs, MNPs and Foreign Network Prefixes (FNPs) are typically
     based on GUAs, but in some cases may be based on IPv4 private
     addresses [RFC1918] or IPv6 ULA-C's [RFC4193].

     AERO address selection rules are conducted per [RFC6724] as updated
     by [I-D.ietf-6man-rfc6724-update].

     See [I-D.templin-6man-omni3] for a full discussion of the various
     unicast, anycast and multicast addresses used by AERO nodes on OMNI
     links.

  4.2.3.  AERO Overlay Routing System

     The AERO routing system comprises a private Border Gateway Protocol
     (BGP) [RFC4271] service coordinated between Gateways as interior
     nodes and Proxy/Servers and Relays as leaf nodes of a spanning tree.
     The service supports OAL packet/fragment forwarding at a layer below
     IP and does not interact with the public Internet BGP routing system,
     but supports redistribution of information for other networks
     connected by Relays.






  Templin                 Expires 2 September 2026               [Page 23]


  Internet-Draft                    AERO                        March 2026


     In a reference deployment, each Proxy/Server is configured as an
     Autonomous System Border Router (ASBR) for a stub Autonomous System
     (AS) using a 32-bit AS Number (ASN) [RFC4271] that is unique within
     the BGP instance, and each Proxy/Server further uses eBGP to peer
     with one or more Gateways but does not peer with other Proxy/Servers.
     Each SRT segment in the OMNI link must include one or more Gateways
     in a "hub" AS, which peer with the Proxy/Servers within that segment
     as "spoke" ASes.  All Gateways within the same segment are members of
     the same hub AS, and use iBGP to maintain a consistent view of all
     active routes currently in service.  The Gateways of different
     segments peer with one another using eBGP.

     Gateways maintain forwarding table entries for the set of all MLAs
     and FNP/MNP routes that are currently active for the OMNI link;
     Gateways also maintain black-hole routes for the OMNI link MSPs so
     that OAL packets/fragments destined to non-existent more-specific
     routes are flushed from the routing system.  In this way, Proxy/
     Servers and Relays have only partial topology knowledge (i.e., they
     only maintain routing information for their directly associated
     Clients and foreign links) and they forward all other OAL packets/
     fragments to Gateways which have full topology knowledge.

     MLAs and FNP/MNP routes are dynamically advertised in the AERO
     routing system by Proxy/Servers and Relays that provide anchor points
     for their corresponding prefixes.  For example, if three Proxy/
     Servers ('D', 'E' and 'F') service the MNPs 2001:db8:1000:1::64/,
     2001:db8:1000:2::/64 and 2001:db8:1000:2::/48 then the routing system
     would include:

     D:  2001:db8:1000:1::/64

     E:  2001:db8:1000:2::/64

     F:  2001:db8:1000:3::/64

     A full discussion of the BGP-based routing system used by AERO is
     found in [I-D.ietf-rtgwg-atn-bgp].

  4.2.4.  Segment Routing Topologies (SRTs)

     The distinct GUA prefixes in an OMNI link domain identify distinct
     Segment Routing Topologies (SRTs).  Each SRT is a mutually-exclusive
     OMNI link overlay instance using a distinct set of GUAs, and emulates
     a bridged campus LAN service for the OMNI link.  In some cases (e.g.,
     when redundant topologies are needed for fault tolerance and
     reliability) it may be beneficial to deploy multiple SRTs that act as
     independent overlay instances.  A communication failure in one
     instance therefore will not affect communications in other instances.



  Templin                 Expires 2 September 2026               [Page 24]


  Internet-Draft                    AERO                        March 2026


     Each SRT is identified by a distinct MSP prefix and assigns an IPv6
     SRA address used for OMNI interface determination in Safety-Based
     Multilink (SBM) as discussed in [I-D.templin-6man-omni3].  Each OMNI
     interface further applies Performance-Based Multilink (PBM)
     internally.

     The Gateways and Proxy/Servers of each independent SRT engage in BGP
     peerings to form a spanning tree with the Gateways in non-leaf nodes
     and the Proxy/Servers in leaf nodes.  The spanning tree is configured
     over both secured and unsecured underlay network paths.  The secured
     spanning tree is used to convey secured control messages (and
     sometimes data message extensions) between Proxy/Servers and
     Gateways, while the unsecured spanning tree forwards bulk data
     messages and/or unsecured control messages.

     Each SRT segment is identified by a unique MSP prefix used by all
     Proxy/Servers and Gateways in the segment.  Each AERO node must
     therefore discover an SRT prefix that correspondents can use to
     determine the correct segment, and must publish the SRT prefix in
     control messages.

     Note: The distinct MSP prefixes in an OMNI link domain can be carried
     either in a common BGP routing protocol instance for all OMNI links
     or in distinct BGP routing protocol instances for different OMNI
     links.  In some SBM environments, such separation may be necessary to
     ensure that distinct OMNI links do not include any common
     infrastructure elements as single points of failure.  In other
     environments, carrying the MSPs of multiple OMNI links within a
     common routing system may be acceptable.

  4.3.  OMNI Interface Characteristics

     OMNI interfaces are virtual interfaces configured over one or more
     underlay interfaces classified as follows:

     *  (M)ANET interfaces connect to a protected and secured ANET or an
        open MANET that connects to an INET via Proxy/Servers.  The
        (M)ANET interface may be either on the same L2 link segment as a
        Proxy/Server, or separated from a Proxy/Server by multiple IP
        hops.  (Note that NATs may appear internally within a (M)ANET and
        may require NAT traversal on the path to the Proxy/Server the same
        as for the INET case.)  MANETs are special cases of ANETs in which
        adaptation layer multihop forwarding may be necessary, and
        protected secured underlay links cannot always be assumed.

     *  INET interfaces connect to an INET either natively or through one
        or several IPv4 Network Address Translators (NATs).  Native INET
        interfaces have global IP addresses that are reachable from



  Templin                 Expires 2 September 2026               [Page 25]


  Internet-Draft                    AERO                        March 2026


        correspondent on the same INET.  NATed INET interfaces typically
        have private IP addresses and connect to a private network behind
        one or more NATs with the outermost NAT providing INET access.

     *  EUN interfaces connect a Client's downstream-attached networks,
        where the Client provides forwarding services for EUN end system
        communications to remote peers.  An EUN can be as simple as a
        small IoT sub-network that travels with a mobile Client to as
        complex as a large private enterprise network that the Client
        connects to a larger ANET or INET.

     *  VPN interfaces use security encapsulations (e.g. IPsec tunnels)
        over underlay networks to connect Clients, Proxy/Servers and/or
        Gateways.  VPN interfaces provide security services at lower
        layers of the architecture the same as for Direct point-to-point
        interfaces.

     *  Direct point-to-point interfaces securely connect Clients, Proxy/
        Servers and/or Gateways over physical or virtual media that does
        not transit any open Internetwork paths.  Examples include a line-
        of-sight link between a remote pilot and an unmanned aircraft, a
        fiberoptic link between Gateways, etc.

     OMNI interfaces use OAL encapsulation and fragmentation as discussed
     in Section 4.6.  OMNI interfaces use underlay encapsulation (see:
     Section 4.6) to exchange carrier packets with OMNI link neighbors
     over INET interfaces and IPsec tunnels as well as over ANET
     interfaces for which the Client and neighbor may be multiple IP hops
     away.  OMNI interfaces use link layer encapsulation only (i.e., and
     no other underlay encapsulations) over Direct underlay interfaces or
     (M)ANET interfaces when the Client and neighbor are known to be on
     the same underlay link.

     OMNI interfaces maintain an adaptation layer view of the neighbor
     cache for tracking per-neighbor state.  IP nodes that configure OMNI
     interfaces use IPv6 ND messages to manage both the network and
     adaptation layer views of the neighbor cache.  The adaptation layer
     further uses MP multilink forwarding control messages which consist
     of an ordinary packet for a flow with an OMNI option trailer.  OMNI
     neighbors invoke per-flow OAL Identification window synchronization
     in their control message exchanges to enable Source Address
     verification, header compression and robust fragmentation/reassembly.

     OMNI interfaces include OMNI options formatted as specified in
     [I-D.templin-6man-omni3] in the control messages they forward.  The
     OMNI option includes parameters for coordinating the OMNI interface's
     underlay interfaces.




  Templin                 Expires 2 September 2026               [Page 26]


  Internet-Draft                    AERO                        March 2026


     A Client's OMNI interface may be configured over multiple *NET
     underlay interfaces.  For example, common mobile handheld devices
     have both wireless local area network ("WLAN") and cellular wireless
     links.  These links are often used "one at a time" with low-cost WLAN
     preferred and highly-available cellular wireless as a standby, but a
     simultaneous-use capability could provide benefits.  In a more
     complex example, aircraft frequently have many wireless data link
     types (e.g.  satellite-based, cellular, terrestrial, air-to-air
     directional, etc.) with diverse performance and cost properties.

     If a Client's multiple *NET underlay interfaces are used "one at a
     time" (i.e., all other interfaces are in standby mode while one
     interface is active), then successive control messages all include
     OMNI option Interface Attributes, Traffic Selector and/or Neighbor
     Synchronization sub-options with the same underlay interface ifIndex.
     In that case, the Client would appear to have a single underlay
     interface but with a dynamically changing underlay address.

     If the Client has multiple active *NET underlay interfaces, then from
     the perspective of IPv6 ND it would appear to have multiple underlay
     addresses.  In that case, control message OMNI options MAY include
     multiple Interface Attribute sub-options; each with a different
     underlay interface ifIndex.

     Proxy/Servers on the open Internet include only a single INET
     underlay interface.  INET Clients therefore discover only the UNX
     information for the Proxy/Server's INET interface.  Proxy/Servers on
     a (M)ANET/INET boundary include both (M)ANET and INET underlay
     interfaces.  (M)ANET Clients therefore must discover both the (M)ANET
     and INET UNX information for their Proxy/Servers.

     Gateway and Proxy/Server OMNI interface connections to the SRT are
     configured over both secured IPsec tunnels for carrying IPv6 ND and
     BGP protocol control plane messages and open INET paths for carrying
     unsecured data plane messages.  The OMNI interface configures an MLA
     and acts as an OAL source to encapsulate original IP packets, then
     fragments the resulting OAL packets, performs underlay encapsulation
     and sends the resulting carrier packets over the secured or unsecured
     underlay paths.  Note that Gateway and Proxy/Server end-to-end
     transport protocol sessions used by the BGP run directly over the
     OMNI interface and use MLA IPv6 Source and Destination Addresses.










  Templin                 Expires 2 September 2026               [Page 27]


  Internet-Draft                    AERO                        March 2026


  4.4.  OMNI Interface Initialization

     AERO Proxy/Servers and Clients configure OMNI interfaces as their
     point of attachment to the OMNI link.  AERO nodes assign the MSPs for
     the link to their OMNI interfaces (i.e., as a "route-to-interface")
     to ensure that original IP packets with Destination Addresses covered
     by an MNP not explicitly associated with another interface are
     directed to an OMNI interface where address resolution is applied.

     OMNI interface initialization procedures for Gateways, Proxy/Servers
     and Clients are discussed in the following sections.

  4.4.1.  AERO Gateway Behavior

     AERO Gateways configure an OMNI interface and assign an MLA.
     Gateways configure underlay interface secured tunnels with Proxy/
     Servers in the same SRT segment and other Gateways in the same (or an
     adjacent) SRT segment.  Gateways then engage in an adaptation layer
     BGP routing protocol session with neighbors over the secured spanning
     tree (see: Section 4.2.3).

  4.4.2.  AERO Proxy/Server and Relay Behavior

     When a Proxy/Server enables an OMNI interface, it assigns both an LLA
     and MLA.  The Proxy/Server also configures secured underlay interface
     tunnels and engages in adaptation layer BGP routing protocol sessions
     over the OMNI interface with one or more neighboring Gateways.

     The OMNI interface provides a single interface abstraction to the
     network layer, but internally serves as an NBMA nexus for exchanging
     carrier packets with other OMNI nodes over underlay interfaces and/or
     secured tunnels.  The Proxy/Server further configures a service to
     facilitate control message exchanges with AERO Clients and manages
     per-Client Neighbor Cache Entries (NCEs) and IP forwarding table
     entries based on control message exchanges.

     Relays are simply Proxy/Servers that run a dynamic routing protocol
     to redistribute routes between the OMNI interface and foreign
     networks/links (see: Section 4.2.3).  The Relay provisions MNPs and
     advertises the MSP(s) for the OMNI link over its foreign network
     interface attachments.  The Relay further provides an OMNI link
     attachment point for FNP-based topologies.









  Templin                 Expires 2 September 2026               [Page 28]


  Internet-Draft                    AERO                        March 2026


  4.4.3.  AERO Client Behavior

     When a Client enables an OMNI interface, it assigns different
     administratively assigned internal and external LLAs and link-layer
     addresses as well as a globally unique MLA to the OMNI interface.
     The adaptation layer within the interface then issues an internally-
     generated RA message to the network layer to establish itself as a
     (virtual) default router for the OMNI link.  The network layer then
     issues a DHCPv6 Prefix Delegation (PD) request per [RFC9762].  When
     it receives the PD request (or after a brief timeout), the adaptation
     layer then sends OMNI-encapsulated RS messages to FHS Proxy/Servers
     which optionally coordinate with a MAP Proxy/Server that delegates
     one or more MNPs.  The MAP/FHS Proxy/Servers then return an RA
     message to the Client which may pass through one or more NATs in the
     path.

     When the Client sends initial RS messages, it will discover MNPs in
     the corresponding RAs that it receives from FHS Proxy/Servers and can
     then associate them with the OMNI interface.  If the Client is
     operating outside the context of AERO infrastructure, however, it may
     continue using MLAs over its underlay or OMNI interfaces for peer-to-
     peer communications within the local *NET.

  4.5.  OMNI Interface Neighbor Cache Maintenance

     Each Client and Proxy/Server OMNI interface maintains a network layer
     conceptual Neighbor and Destination Cache per [RFC1256][RFC4861] the
     same as for any IP interface.  The OMNI interface network layer
     neighbor cache (NLNC) is maintained through static and/or dynamic
     neighbor cache entry (NLNCE) configurations.  The IP layer initiates
     and terminates IP ND messaging exchanges to manage the network layer
     view of the neighbor cache.

     Each OMNI interface also maintains an internal adaptation layer view
     of the neighbor cache (ALNC) that includes an entry (ALNCE) for each
     of its active OAL neighbors.  ALNCE state is managed according to
     neighbor cache entry states per Section 7.3.2 of [RFC4861] the same
     as the NLNC.  The adaptation layer indexes the ALNC by the neighbor's
     MLA and includes routing information for any of the neighbor's FNPs/
     MNPs.  Control messages that update the ALNC include an OMNI option
     with zero or more sub-options.

     Each OMNI interface ALNCE is indexed by the IPv6 MLA of a neighbor
     found in an ND message and determines the context for Identification
     verification.  Clients and Proxy/Servers maintain NCEs through
     dynamic RS/RA message exchanges, and also maintain NCEs for any
     active correspondent peers through dynamic IPv6 NS/NA message
     exchanges.



  Templin                 Expires 2 September 2026               [Page 29]


  Internet-Draft                    AERO                        March 2026


     Clients establish NCEs and establish adaptation layer service
     profiles for their associated FHS and MAP Proxy/Servers through the
     exchange of RS/RA messages as specified in [I-D.templin-6man-omni3].
     When a Client and Proxy/Server establish NCEs, they set a
     ReachableTime timer to REACHABLE_TIME seconds.

     Both the Client and its MAP Proxy/Server have full knowledge of the
     Client's current underlay Interface Attributes and Traffic Selectors,
     while FHS Proxy/Servers acting in "proxy" mode have knowledge of only
     the individual Client underlay interfaces they service.

     When an Address Resolution Source (ARS) sends an NS(AR) message
     toward an Address Resolution Target (ART) Client/Relay, the OMNI link
     routing system directs the NS(AR) to a MAP Proxy/Server for the ART.
     The MAP then either acts as an Address Resolution Responder (ARR) on
     behalf of the ART or forwards the NS(AR) to the ART which acts as an
     ARR on its own behalf.  The ARR returns an NA(AR) response to the
     ARS, which creates or updates NCE state for the ART while caching
     network layer and underlay addressing information.  The ARS then
     (re)sets ReachableTime for the NCE to REACHABLE_TIME seconds and
     performs multilink forwarding ND message exchanges over specific
     underlay interface pairs to determine paths for sending carrier
     packets directly to the ART.  The ARS otherwise decrements
     ReachableTime while no further solicited ND messages arrive.

     Proxy/Servers add an additional state DEPARTED to the list of NCE
     states found in Section 7.3.2 of [RFC4861].  When a Client terminates
     its association, the Proxy/Server OMNI interface sets a DepartTime
     variable for the NCE to DEPART_TIME seconds.  DepartTime is
     decremented unless a new control message causes the state to return
     to REACHABLE.  While a NCE is in the DEPARTED state, the Proxy/Server
     forwards OAL packets/fragments destined to the target Client to the
     Client's new FHS/MAP Proxy/Server instead.

     It is RECOMMENDED that REACHABLE_TIME be set to the default constant
     value 30 seconds as specified in [RFC4861].  It is RECOMMENDED that
     DEPART_TIME be set to the default constant value 10 seconds to accept
     any carrier packets that may be in flight.  When ReachableTime or
     DepartTime decrement to 0, the NCE is deleted.












  Templin                 Expires 2 September 2026               [Page 30]


  Internet-Draft                    AERO                        March 2026


     AERO nodes also use the value MAX_UNICAST_SOLICIT to limit the number
     of NS(NUD) messages sent when a correspondent may have gone
     unreachable, the value MAX_RTR_SOLICITATIONS to limit the number of
     RS messages sent without receiving an RA and the value
     MAX_NEIGHBOR_ADVERTISEMENT to limit the number of solicited IPv6 ND
     advertisements that can be sent based on a single event.  It is
     RECOMMENDED that MAX_UNICAST_SOLICIT, MAX_RTR_SOLICITATIONS and
     MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the same as specified in
     [RFC4861].

     Different values for the above constants MAY be administratively set;
     however, if different values are chosen, all nodes on the link MUST
     consistently configure the same values.

  4.5.1.  AERO/OMNI Control Plane Messages

     OMNI interfaces use ICMPv6 messages per [RFC4443][RFC4861] as the
     secured control plane messaging service for all adaptation layer
     exchanges.  IPv6 ND messages sent over OMNI interfaces include or
     omit the Source/Target Link Layer Address Option (S/TLLAO) as
     discussed in [I-D.templin-6man-omni3].  OMNI interfaces forward
     ICMPv6 messages to and from the IP layer the same as for any
     interface, but also append/remove a trailing OMNI option during
     encapsulation/decapsulation [I-D.templin-6man-omni3].

     For each ICMPv6 message, the OMNI interface includes a trailing OMNI
     option then completely populates all sub-option information.  If the
     OMNI interface includes an authentication sub-option, it calculates
     and includes a digital signature per the OMNI specification.  OMNI
     interfaces verify integrity and authenticity of each message
     received, and process the message further only following successful
     verification.

     OMNI options include per-neighbor information that provides multilink
     forwarding, address resolution and traffic selector information for
     the neighbor's underlay interfaces.  This information is stored in
     both the neighbor cache and AERO Flow Information Base (AFIB) as
     basis for the forwarding algorithm specified in Section 4.10.  The
     information is cumulative and reflects the union of the OMNI
     information from the most recent control messages received from the
     neighbor.

     AERO/OMNI Clients send RS messages to cause Proxy/Servers to respond
     with RA messages that include autoconfiguration and addressing
     parameters as specified in [I-D.templin-6man-omni3].

     AERO nodes use NS/NA messages as follows:




  Templin                 Expires 2 September 2026               [Page 31]


  Internet-Draft                    AERO                        March 2026


     *  NS/NA(AR) messages are used for address resolution.  When an ARS
        prepares an NS(AR) it sets the Source Address to the IPv6 MLA
        assigned to the OMNI interface.  The ARS also sets the Target
        Address to the IP Destination Address of the invoking packet and
        sets the Destination Address to the solicited-node multicast
        address corresponding to the (unicast) Target Address.  After the
        ARS sends the NS(AR), an ARR with addressing information for the
        ART returns a unicast NA(AR) that contains current, consistent and
        authentic Target Address resolution information.  The ARR sets the
        NA(AR) Source Address to an IPv6 MLA assigned to the ART's OMNI
        interface, sets the Destination Address to the Source Address of
        the NS(AR) and sets the Target Address to the Target Address of
        the NS(AR).  NS/NA(AR) messages must be secured.

     *  Other NS/NA message exchanges are used to determine target
        reachability (NS/NA(NUD)).  These messages include the same
        addresses as for NS/NA(AR) with the exception that the source sets
        the NS(NUD) Destination and Target Address to the same unicast
        address.  The target then returns a responsive NA(NUD).  NS/
        NA(NUD) messages used to establish or update NCE state must be
        secured.

     *  Unsolicited NA messages (uNAs) are used to update a neighbor's
        cache when an underlay interface address changes due to a mobility
        event.  Nodes also use uNAs during Route Optimization.

     *  NS/NA(DAD) messages are not used in AERO, since Duplicate Address
        Detection is not required on OMNI links.  When the network layer
        issues an NS(DAD) message over an OMNI interface, the interface
        simply discards the message.

     AERO also introduces a control message type termed "Multilink Pilot
     (MP)" which consists of an ordinary IP packet with an OMNI option
     trailer and used to establish multilink forwarding state.  The OAL
     source may send MPs as initial messages of a flow until header
     compression can be applied for further messages of the flow.  Note
     that only control messages should include uncompressed OAL and
     original IP packet headers; all data plane messages should include
     compressed headers except in the event of a path change - see:
     Section 4.15.5.











  Templin                 Expires 2 September 2026               [Page 32]


  Internet-Draft                    AERO                        March 2026


     AERO control messages sent on OMNI links that must be examined by
     transit OAL intermediate systems on the path require a special
     codepoint for control message recognition.  The OAL source therefore
     sets the DSCP field in the IPv6 OAL encapsulation header of such
     messages to the special value '111111' (see:
     [I-D.templin-6man-omni3]) and includes an OMNI option trailer with
     control information.  The control planes of transit OAL intermediate
     systems can then intercept and process these messages before
     forwarding them to the next OAL hop.

     AERO control messages also include an SRH extension to the OAL IPv6
     header as discussed in [I-D.templin-6man-omni3].  The SRH includes
     any FHS intermediate system MLAs as non-ultimate Segment List
     entries, the MLA of the LHS Proxy/Server as the penultimate entry and
     the MLA of the target LHS Client as the ultimate entry.

  4.5.2.  OMNI Neighbor Window Synchronization

     In secured environments (e.g., between secured spanning tree
     neighbors, between neighbors on the same secured ANET, etc.), OMNI
     interface neighbors can exchange AERO control messages without
     including Identification values.  In environments where spoofing is
     considered a threat, OMNI interface neighbors instead invoke
     Identification window synchronization by including OMNI Neighbor
     Synchronization sub-options in control message exchanges to maintain
     send/receive window state in their respective neighbor caches as well
     as in AFIB entries of all OAL intermediate nodes in the forward and
     reverse paths.

     In common arrangements, OAL Identification window synchronization is
     necessary for Client to Client, Client to Proxy/Server or Proxy/
     Server to Proxy/Server message exchanges conducted over unsecured
     Internetwork paths.  Conversely, Proxy/Server to Proxy/Server, Proxy/
     Server to Gateway and Gateway to Gateway message exchanges carried
     over the secured spanning tree do not require window synchronization.

     OAL end system and intermediate nodes verify Identification values of
     OAL packets that traverse the unsecured spanning tree according to
     their populated AFIB state.  This allows each OAL node to exclude
     spurious packets injected into the OMNI link from an off-path
     adversary.










  Templin                 Expires 2 September 2026               [Page 33]


  Internet-Draft                    AERO                        March 2026


  4.6.  OMNI Interface Encapsulation and Fragmentation

     When the network layer forwards an original IP packet into an OMNI
     interface, the interface locates a NLNCE corresponding to the
     destination (which may only match "default").  The OMNI interface
     then invokes the OAL as discussed in [I-D.templin-6man-omni3] which
     removes the virtual Ethernet header and encapsulates the packet in an
     IPv6 header to form an OAL packet according to ALNCE information.

     Following encapsulation, the OAL source then fragments the OAL packet
     while including an identical Identification value for each fragment
     that must be within the window for the flow over the interface pair
     selected for the neighbor.  The OAL source includes any necessary OAL
     IPv6 extension headers including an identical SRH with each fragment.
     The OAL source can instead invoke OAL header compression by replacing
     the full OAL IPv6 header, SRH and Extended Fragment Header with an
     OAL Compressed Header (OCH) that includes an AERO Flow Vector Index
     (AFVI) (see: [I-D.templin-6man-omni3]).

     For messages that will traverse unsecured paths, the OAL source
     finally performs underlay encapsulation on each resulting OAL
     fragment to form a carrier packet, with Source Address set to its own
     address (e.g., 192.0.2.100) and Destination Address set to the
     address of the next hop OAL intermediate system or destination (e.g.,
     192.0.2.1).  The carrier packet encapsulation format in the above
     example is shown in Figure 3:

























  Templin                 Expires 2 September 2026               [Page 34]


  Internet-Draft                    AERO                        March 2026


          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |        Underlay Headers       |
          ~       src = 192.0.2.100       ~
          |        dst = 192.0.2.1        |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ~Underlay IPv6 Extension Headers~
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |        OAL IPv6 Header        |
          ~       Source Address (1)      ~
          |    Destination Address (2)    |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ~   OAL IPv6 Extension Headers  ~
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |       Original IP Header      |
          ~     (first-fragment only)     ~
          ~       Source Address (3)      ~
          |    Destination Address (4)    |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                               |
          ~                               ~
          ~ Original Packet Body/Fragment ~
          ~                               ~
          |                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: Carrier Packet Format

     In this format, the OAL source encapsulates the original IP header
     and packet body/fragment in an OAL IPv6 header.  The OAL source then
     adds an SRH plus Extended Fragment Header as OAL IPv6 header
     extensions for each fragment and prepends underlay headers prepared
     as discussed in [I-D.templin-6man-omni3].  The OAL source sends each
     such carrier packet into the SRT unsecured spanning tree, where they
     may be forwarded over multiple OAL intermediate systems until they
     arrive at the OAL destination.  These carrier packets may themselves
     be subject to fragmentation and reassembly along the concatenated
     underlay network path segments.

     The OMNI link control plane service distributes Client MLAs and MNP
     information that may change occasionally due to regional node
     mobility, as well as more static information for Relay FNPs that
     rarely change.  OMNI link Gateways and Proxy/Servers use the
     information to establish and maintain a forwarding plane spanning
     tree that connects all nodes on the link.  The spanning tree supports
     a virtual bridging service according to link layer (instead of
     network layer) information, but may often include longer paths than
     necessary.




  Templin                 Expires 2 September 2026               [Page 35]


  Internet-Draft                    AERO                        March 2026


     Each OMNI interface therefore also includes an AERO Flow Information
     Base (AFIB) that caches AERO Flow Vectors (AFVs) which can provide
     both carrier packet Identification context and more direct forwarding
     "shortcuts" that avoid strict spanning tree paths.  As a result, the
     spanning tree is always available but OMNI interfaces can often use
     the AFIB entries established through route optimization to greatly
     improve performance and reduce load on critical infrastructure
     elements.

     For OAL packets/fragments undergoing underlay re-encapsulation at an
     OAL intermediate system, the OMNI interface performs underlay
     decapsulation followed by Identification verification and OAL
     reassembly only if the OAL packet/fragment is addressed to itself.
     The OMNI interface then decrements the OAL IPv6 header Hop Limit and
     discards the packet/fragment if the Hop Limit reaches 0.  Otherwise,
     the OMNI interface updates the OAL addresses if necessary, includes
     an appropriate Identification, performs OAL fragmentation then for
     each OAL fragment performs underlay encapsulation to produce a
     carrier packet appropriate for next segment forwarding.

  4.7.  OMNI Interface Decapsulation

     When an OAL node receives OAL packets/fragments addressed to another
     node, it discards the previous hop underlay headers and includes new
     underlay headers appropriate for the next hop in the forwarding path
     to the OAL destination.  The node then sends these new carrier
     packets into the next hop underlay interface.

     When an OAL node receives OAL packets/fragments addressed to itself,
     it performs underlay decapsulation, verifies the Identification, then
     performs OAL reassembly/decapsulation to obtain the original OAL
     packet or composite packet (see: [I-D.templin-6man-omni3]).  Next, if
     the enclosed original IP packet(s) are addressed either to itself or
     to a destination reached via an interface other than the OMNI
     interface, the OAL node replaces the OAL encapsulation IPv6 header
     with a virtual Ethernet header and forwards the original IP packet(s)
     to the network layer.

     If the original IP packet(s) are destined to another node reached by
     the OMNI interface, the OAL node instead decrements the Hop Limit,
     then performs underlay encapsulation and forwards these new carrier
     packets into an underlay interface for the next segment.

     Further OMNI link decapsulation details are specified in
     [I-D.templin-6man-omni3].  Further OMNI link forwarding procedures
     are specified in Section 4.10.





  Templin                 Expires 2 September 2026               [Page 36]


  Internet-Draft                    AERO                        March 2026


  4.8.  OMNI Interface Data Origin Authentication

     AERO nodes employ simple data origin authentication procedures.  In
     particular:

     *  AERO Gateways and Proxy/Servers accept carrier packets received
        from the secured spanning tree.

     *  AERO Proxy/Servers and Clients accept carrier packets and original
        IP packets that originate from within the same secured ANET.

     *  AERO Clients and Relays accept original IP packets from downstream
        network correspondents based on ingress filtering.

     *  AERO Clients, Relays, Proxy/Servers and Gateways verify carrier
        packet underlay encapsulation addresses according to
        [I-D.templin-6man-omni3].

     *  OAL end systems and intermediate systems forward/accept OAL
        packets/fragments with Identification values within the current
        window for the OAL source neighbor for a specific underlay
        interface pair and drop any packets with out-of-window
        Identification values.

     AERO nodes silently drop any packets that do not satisfy the above
     data origin authentication procedures.  Further security
     considerations are discussed in Section 7.

  4.9.  OMNI Interface MTU

     The OMNI interface observes the link nature of tunnels, including the
     Maximum Transmission Unit (MTU), Effective MTU to Receive (EMTU_R)
     and the role of fragmentation and reassembly
     [I-D.ietf-intarea-tunnels].  The OMNI interface employs the OAL to
     accommodate multiple underlay links with diverse MTUs.  OMNI
     interface packet sizing considerations are specified in
     [I-D.templin-6man-omni3], where the OMNI interface MTU can
     essentially be considered "unlimited".













  Templin                 Expires 2 September 2026               [Page 37]


  Internet-Draft                    AERO                        March 2026


     When the network layer presents an original IP packet to the OMNI
     interface, the OAL source encapsulates and fragments the packet if
     necessary.  When the network layer presents the OMNI interface with
     multiple original IP packets addressed to the same IPv6 flow, the OAL
     source can concatenate them as a single OAL composite packet as
     discussed in [I-D.templin-6man-omni3] before applying fragmentation.
     The OAL source then submits each OAL fragment for underlay
     encapsulation and transmission as a carrier packet via an underlay
     interface connected to either a physical link (e.g., Ethernet, WiFi,
     Cellular, etc.) or a virtual link such as an Internet or higher-layer
     tunnel.

  4.10.  OMNI Interface Forwarding Algorithm

     Original IP packets enter a node's OMNI interface either from the
     network layer (i.e., from a local application or the IP forwarding
     system) while carrier packets enter from the underlay (i.e., from an
     OMNI interface neighbor).  All original IP packets and carrier
     packets entering a node's OMNI interface first undergo data origin
     authentication as discussed in Section 4.8.  Those that satisfy data
     origin authentication are processed further, while all others are
     dropped silently.

     Original IP packets that enter the OMNI interface from the network
     layer are forwarded to an OMNI interface neighbor using OAL
     encapsulation and fragmentation to produce carrier packets for
     transmission over underlay interfaces.  (If forwarding state
     indicates that the original IP packet should instead be forwarded
     back to the network layer, the packet is dropped to avoid looping).
     Carrier packets that enter the OMNI interface from the underlay are
     either re-encapsulated and re-admitted into the underlay, or
     reassembled and forwarded to the network layer where they are subject
     to either local delivery or IP forwarding.

     When the network layer of a router forwards an original IP packet
     into the OMNI interface, it decrements the TTL/Hop Limit following
     standard IP router conventions.  Once inside the OMNI interface,
     however, the OAL does not decrement the original IP packet TTL/Hop
     Limit further since its adaptation layer forwarding actions occur
     below the network layer.  The original IP packet's TTL/Hop Limit will
     therefore be the same when it exits the destination OMNI interface as
     when it first entered the source OMNI interface.

     When an OAL intermediate system receives a carrier packet, it
     performs underlay decapsulation to obtain the enclosed OAL packet/
     fragment.  When the intermediate system forwards an OAL packet/
     fragment not addressed to itself (or one addressed to itself but that
     also includes an SRH with Segments Left greater than 0), it



  Templin                 Expires 2 September 2026               [Page 38]


  Internet-Draft                    AERO                        March 2026


     decrements the OAL Hop Limit without decrementing the network layer
     IP TTL/Hop Limit.  If decrementing would cause the OAL Hop Limit to
     become 0, the OAL intermediate system drops the OAL packet/fragment.
     This ensures that original IP packet(s) cannot enter an endless loop.

     OMNI interfaces may have multiple underlay interfaces and/or NCEs for
     neighbors with multiple underlay interfaces (see: Section 4.3).  The
     OAL uses Interface Attributes and/or Traffic Selectors to select an
     outbound underlay interface for each OAL packet and also to select
     underlay network Destination Addresses based on the neighbor's target
     underlay interfaces.  AERO implementations SHOULD permit network
     management to dynamically adjust Traffic Selector values at runtime.

     If an OAL packet/fragment matches the Interface Attributes and/or
     Traffic Selectors of multiple outgoing interfaces and/or neighbor
     interfaces, the OMNI interface replicates the packet and sends a
     separate copy via each of the (outgoing / neighbor) interface pairs;
     otherwise, it sends a single copy via an interface with the best
     matching attributes/selectors.  (While not strictly required, the
     likelihood of successful reassembly is often greatest when the OMNI
     interface sends all fragments of the same fragmented OAL packet/
     fragment consecutively over the same underlay interface pair to avoid
     complicating factors such as delay variance and reordering.)  AERO
     nodes keep track of which underlay interfaces are currently
     "reachable" or "unreachable", and use only "reachable" interfaces for
     forwarding purposes.

     In addition to standard forwarding based on Interface Attributes and/
     or Traffic Selectors, nodes may employ a policy engine that would
     provide further guidance to the forwarding algorithm.  For example
     the policy engine may suggest a load balancing profile over multiple
     underlay interface pairs, with portions of a traffic flow spread
     between multiple paths according to Equal Cost MultiPath or Link
     Aggregation Groups (LAGs) [RFC6438] (note that Interface Attributes
     include an underlay interface group identifier).  Other policies may
     suggest the use of paths with the least cost, best performance, etc.
     This document therefore specifies mechanisms without mandating any
     particular policies.

     All Clients, Proxy/Servers and Gateways serve as OAL intermediate
     nodes for the purpose of forwarding OAL packets/fragments that
     include an SRH or OCH with non-zero AFVI over the unsecured spanning
     tree based on AFIB entries.  When an OAL intermediate node forwards
     an OAL packet/fragment with an underlay Source Address and AFVI that
     matches an AFV, the node first verifies that the Identification is in
     sequence.  The OAL intermediate node then rewrites the packet's AFVI
     with a value that will be recognized by the next OAL hop and forwards
     the packet.  (For OAL packets/fragments with uncompressed headers and



  Templin                 Expires 2 September 2026               [Page 39]


  Internet-Draft                    AERO                        March 2026


     with AFVI set to 0, the OAL intermediate node instead forwards based
     on matching the OAL IPv6 Destination Address with a standard IPv6
     forwarding table entry after applying SRH processing.)  The chain of
     OAL source, intermediate and destination nodes may therefore traverse
     many (Proxy/)Clients, Proxy/Servers and Gateways on the path.

     The following sections discuss the OMNI interface-specific forwarding
     algorithms for Clients, Proxy/Servers and Gateways.  In the following
     discussion, an original IP packet's Destination Address is said to
     "match" if it is the same as a cached address, or if it is covered by
     a cached MLA/FNP/MNP.

  4.10.1.  Client Forwarding Algorithm

     When the network layer presents an original IP packet to a Client's
     OMNI interface (i.e., following next-hop determination), the Client
     forwards the packet to the OMNI interface virtual router function if
     the Destination is off-link.  The virtual router then either forwards
     the packet to a Proxy/Server or initiates adaptation layer address
     resolution and forwards the packet according to ALNCE information.
     If the Destination is on-link, the Client instead invokes network
     layer address resolution if there is no NLNCE.  The Client holds the
     packet in a queue until address resolution completes, then admits the
     packet into the OMNI interface.  The OMNI interface then searches for
     an ALNCE that matches the Destination.  If there is a matching ALNCE
     for a neighbor reached via a *NET interface (i.e., an upstream
     interface), the Client selects one or more "reachable" neighbor
     interfaces in the entry for forwarding purposes.

     When a carrier packet enters a Client's OMNI interface from the
     underlay, the Client performs underlay decapsulation if necessary to
     obtain the OAL packet/fragment then examines the OAL Destination
     Address (i.e., after locating the correct AFV if the OAL packet
     header is OCH).  If the OAL Destination Address matches one of the
     Client's addresses and the packet includes an SRH with Segments Left
     greater than 0, the Client rewrites the OAL Destination Address and
     forwards the packet to the peer Client or Proxy/Server indicated by
     the next hop SRH address.  Otherwise, the Client (acting as an OAL
     destination) verifies that the Identification is in-window for the
     matching AFV, then reassembles/decapsulates as necessary and delivers
     the original IP packet to the network layer.  If the OAL Destination
     Address does not match, the Client drops the original IP packet and
     MAY return a network layer ICMP Destination Unreachable message
     subject to rate limiting (see: Section 4.11).







  Templin                 Expires 2 September 2026               [Page 40]


  Internet-Draft                    AERO                        March 2026


     Note: The forwarding table entries established in peer Clients are
     based on MLAs which also appear as OAL Source or Destination
     Addresses within (M)ANETs.  The original IP packet Source and
     Destination Addresses instead use MNP or MLA addresses.

     Note: Clients within MANETs support Client-to-Client multihop
     forwarding when necessary to reach destinations or FHS Proxy/Servers
     that may be multiple OAL hops away.  In this way, forwarding Clients
     act as OAL intermediate nodes and forward using OCH compression based
     on AFV state that is indexed by the AFVIs included in each OAL
     packet/fragment.

  4.10.2.  Proxy/Server and Relay Forwarding Algorithm

     When the network layer admits an original IP packet into a Proxy/
     Server's OMNI interface, the OAL drops the packet to avoid looping if
     forwarding state indicates that it should be forwarded back to the
     network layer.  Otherwise, the OAL examines the IP Destination
     Address to determine if it matches the MLA of a neighboring Gateway
     found in the OMNI interface's network layer neighbor cache.  If so,
     the Proxy/Server performs OAL encapsulation and fragmentation then
     performs underlay encapsulation and forwards the resulting carrier
     packet to the Gateway over a secured link (e.g., an IPsec tunnel,
     Direct link, etc.) to support control plane functions such as the
     operation of the BGP routing protocol.  If the IP Destination Address
     matches an MLA/FNP/MNP associated with a (foreign) Proxy/Server or
     Client, the (local) Proxy/Server instead assumes the Relay role and
     forwards the original IP packet in the same manner as for Client
     forwarding while including an SRH.  Specifically, if there is a
     matching NCE the Proxy/Server selects one or more "reachable"
     neighbor interfaces in the entry for forwarding purposes; otherwise,
     the Proxy/Server performs OAL encapsulation/fragmentation followed by
     underlay encapsulation and forwards the resulting carrier packets
     while invoking address resolution and multilink forwarding procedures
     per Section 4.13.
















  Templin                 Expires 2 September 2026               [Page 41]


  Internet-Draft                    AERO                        March 2026


     When the Proxy/Server receives carrier packets on underlay interfaces
     that contain OAL packets/fragments with both a Source and Destination
     OAL Address that correspond to the same Client's MLA, the Proxy/
     Server drops the carrier packets regardless of their OMNI link point
     of origin.  The Proxy/Server also drops original IP packets received
     on underlay interfaces either directly from a *NET Client if the
     original IP Destination Address corresponds to the same Client's MLA
     or delegated MNP.  Proxy/Servers also drop carrier packets that
     contain OAL packets/fragments with foreign OAL Destination Addresses
     (MLAs) that do not match one of their local *NET Clients.  These
     checks are essential to prevent forwarding inconsistencies from
     accidentally or intentionally establishing endless loops that could
     congest nodes and/or *NET links.

     Proxy/Servers process carrier packets that contain OAL packets/
     fragments with OCH headers or with Destination Addresses that match
     their MLA and also include an SRH.  In the first case, the Proxy/
     Server examines the underlay Source Address and AFVI to locate the
     corresponding AFV entry in the AFIB.  In the second case, the Proxy/
     Server applies standard SRH processing procedures.  The Proxy/Server
     then forwards them according to the AFV or IPv6 routing state while
     decrementing the OAL packet/fragment Hop Limit.

     For OAL packets/fragments with Destination Addresses that match their
     MLA and also include an SRH, the Proxy/Server performs any necessary
     local processing then rewrites the OAL Destination Address according
     to the next hop SRH address.  For those that do not include an OCH or
     SRH with additional next hop addresses, the Proxy/Server instead
     performs underlay decapsulation, verifies the Identification and
     performs OAL reassembly to obtain the original IP packet.  For data
     packets addressed to its own MLA that arrived via the secured
     spanning tree, the Proxy/Server delivers the original IP packet to
     the network layer to support secured BGP routing protocol control
     messaging.  For data packets originating from one of its dependent
     Clients, the Proxy/Server instead performs OAL encapsulation/
     fragmentation followed by underlay encapsulation and sends the
     resulting carrier packets while invoking address resolution and
     multilink forwarding procedures per Section 4.13.  For control
     messages, the Proxy/Server instead authenticates the message and
     processes it as specified in later sections of this document while
     updating neighbor cache and/or AFIB state accordingly.

     When the Proxy/Server receives carrier packets that contain OAL
     packets with OAL Destination Address set to the MLA of one of its
     Client neighbors established through RS/RA exchanges, it accepts the
     carrier packets only if data origin authentication succeeds.  If the
     NCE state is DEPARTED, the Proxy/Server changes the OAL Destination
     Address to the MLA of the Client's new Proxy/Server, decrements the



  Templin                 Expires 2 September 2026               [Page 42]


  Internet-Draft                    AERO                        March 2026


     OAL Hop Limit, then performs underlay encapsulation and forwards the
     resulting carrier packets into the spanning tree which will
     eventually deliver them to the new Proxy/Server.  If the neighbor
     cache state for the Client is REACHABLE and the Proxy/Server is a MAP
     responsible for serving as the Client's address resolution responder
     and/or default router, it verifies the Identification then submits
     the OAL packet/fragment for reassembly.  The Proxy/Server then
     decapsulates and processes the resulting control message or original
     IP packet accordingly.  Otherwise, the Proxy/Server changes the OAL
     Destination Address to the local Client's MLA, includes an SRH with
     intermediate hop MLAs, decrements the OAL Hop Limit, performs
     underlay encapsulation and forwards the carrier packet to the Client
     which then performs data origin verification and reassembly.  (In the
     mobility case, the Client may receive fragments of the same original
     IP packet from different Proxy/Servers but this will not interfere
     with correct reassembly.)

     When the Proxy/Server receives carrier packets that contain OAL
     packets with OAL Source Address set to the MLA of one of its Client
     neighbors established through RS/RA exchanges, it accepts the carrier
     packets only if data origin authentication succeeds.  The local
     Proxy/Server then forwards the packet according to the IP destination
     or AFVI state previously established through multilink control
     messaging.

     When the Proxy/Server receives carrier packets that contain OAL
     packets with OAL Destination Address set to a FNP address that does
     not match the MSP, it accepts the carrier packets only if data origin
     authentication succeeds and if there is a network layer forwarding
     table entry for the FNP.  The Proxy/Server then performs underlay
     decapsulation, verifies the Identification, performs OAL reassembly/
     decapsulation to obtain the original IP packet, then presents it to
     the network layer (as a Relay) where it will be delivered according
     to standard IP forwarding.

     When a Proxy/Server receives a carrier packet from the secured
     spanning tree, it considers the message as authentic without having
     to verify network or higher layer authentication signatures.

     If the Proxy/Server has multiple original IP packets to send to the
     same neighbor, it can concatenate them as a single OAL composite
     packet [I-D.templin-6man-omni3].









  Templin                 Expires 2 September 2026               [Page 43]


  Internet-Draft                    AERO                        March 2026


  4.10.3.  Gateway Forwarding Algorithm

     When the network layer admits an original IP packet into the
     Gateway's OMNI interface, the OAL drops the packet if routing
     indicates that it should be forwarded back to the network layer to
     avoid looping.  Otherwise, the Gateway examines the IP Destination
     Address to determine if it matches the MLA of a neighboring Gateway
     or Proxy/Server by examining the OMNI interface's network layer
     neighbor cache.  If so, the Gateway performs OAL encapsulation/
     fragmentation followed by underlay encapsulation and forwards the
     resulting carrier packets to the neighboring Gateway or Proxy/Server
     over a secured link (e.g., an IPsec tunnel, etc.) to support the
     operation of control plane functions (including the BGP routing
     protocol) between OAL neighbors.

     Gateways forward OAL packets/fragments reassembled from spanning tree
     carrier packets while decrementing the OAL Hop Limit but not the
     original IP header TTL/Hop Limit.  Gateways send carrier packets that
     contain OAL packets/fragments with critical BGP routing protocol or
     other control messages via the SRT secured spanning tree, and may
     send other carrier packets via the secured/unsecured spanning tree or
     via more direct paths according to AFIB information.  When the
     Gateway receives a carrier packet, it decapsulates to obtain the OAL
     packet/fragment then searches for an AFIB entry that matches the OAL
     AFVI or an IPv6 forwarding table entry that matches the OAL
     Destination Address.

     Gateways process carrier packets containing OAL packets/fragments
     with OAL Destination Addresses that do not match their MLAs in the
     same manner as for traditional IP forwarding within the OAL, i.e.,
     they forward packets not explicitly addressed to themselves.
     Gateways locally process OAL packets/fragments with OCH headers or
     full OAL headers with their MLA as the OAL Destination Address.  If
     the OAL packet/fragment contains an OCH or a full OAL header with an
     SRH extension, the Gateway forwards the OAL packet/fragment to the
     next hop while decrementing the OAL Hop Limit but without
     reassembling.  When the Gateway forwards the OAL packet/fragment, it
     either rewrites the OCH AFVI with the value it will represent to the
     next OAL hop or follows standard SRH processing procedures.












  Templin                 Expires 2 September 2026               [Page 44]


  Internet-Draft                    AERO                        March 2026


     If the OAL packet/fragment includes a full OAL header but there is no
     matching AFV, the Gateway instead examines the OAL packet.  The
     Gateway first determines whether the OAL packet includes an MP
     message then processes the message according to the multilink
     forwarding procedures discussed in Section 4.13.  If the carrier
     packets arrived over the secured spanning tree and the enclosed OAL
     packets/fragments are addressed to its MLA, the Gateway instead
     reassembles then discards the OAL header and forwards the original IP
     packet to the network layer to support secured BGP routing protocol
     control messaging.  The Gateway instead drops all other OAL packets.

     Gateways forward OAL packets/fragments received in carrier packets
     that arrived from a first segment via the secured spanning tree to
     the next segment also via the secured spanning tree.  Gateways
     forward OAL packets/fragments received in carrier packets that
     arrived from a first segment via the unsecured spanning tree to the
     next segment also via the unsecured spanning tree.  Gateways
     configure an IPv6 routing table that determines the next hop for a
     given OAL Destination Address, where the secured/unsecured spanning
     tree is determined through the selection of the underlay interface to
     be used for transmission (e.g., an IPsec tunnel or an open INET
     interface).

     As for Proxy/Servers, Gateways must verify that the underlay Source
     Addresses of carrier packets not received from the secured spanning
     tree are "trusted" before forwarding according to an AFV (otherwise,
     the carrier packet must be dropped).

  4.11.  OMNI Interface Error Handling

     When an AERO node admits an original IP packet into the OMNI
     interface, it may receive link and/or network layer error
     indications.  The AERO node may also receive OMNI link error
     indications in OAL-encapsulated uNA messages that include
     authentication signatures.

     A link layer error indication is an ICMP error message generated by a
     router in an underlay network on the path to the next OAL hop or by
     the next OAL hop itself.  The message includes an IP header with the
     address of the node that generated the error as the Source Address
     and with the underlay address of the AERO node as the Destination
     Address.

     The IP header is followed by an ICMP header that includes an error
     Type, Code and Checksum.  Valid type values include "Destination
     Unreachable", "Packet Too Big", "Time Exceeded", "Parameter Problem"
     etc.  [RFC0792][RFC4443].




  Templin                 Expires 2 September 2026               [Page 45]


  Internet-Draft                    AERO                        March 2026


     The ICMP header is followed by the leading portion of the carrier
     packet that generated the error, also known as the "packet-in-error".
     For ICMPv6, [RFC4443] specifies that the packet-in-error includes:
     "As much of invoking packet as possible without the ICMPv6 packet
     exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes).  For
     ICMPv4, [RFC0792] specifies that the packet-in-error includes:
     "Internet Header + 64 bits of Original Data Datagram", however
     [RFC1812] Section 4.3.2.3 updates this specification by stating: "the
     ICMP datagram SHOULD contain as much of the original datagram as
     possible without the length of the ICMP datagram exceeding 576
     bytes".

     The link layer error message format is shown in Figure 4:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                               |
          ~    IP Header of link layer    ~
          ~         error message         ~
          |                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ~          ICMP Header          ~
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
          |                               |   P
          ~  carrier packet underlay and  ~   a
          ~   OAL encapsulation headers   ~   c
          |                               |   k
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   e
          |                               |   t
          ~    original IP packet hdrs    ~
          ~    (first-fragment only)      ~   i
          |                               |   n
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                               |   e
          ~    Portion of the body of     ~   r
          ~    the original IP packet     ~   r
          ~       (all fragments)         ~   o
          |                               |   r
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---

            Figure 4: OMNI Interface Link-Layer Error Message Format

     The AERO node rules for processing these link layer error messages
     are as follows:

     *  When an AERO node receives a link layer Parameter Problem message,
        it processes the message the same as described as for ordinary
        ICMP errors in the normative references [RFC0792][RFC4443].




  Templin                 Expires 2 September 2026               [Page 46]


  Internet-Draft                    AERO                        March 2026


     *  When an AERO node receives persistent link layer Packet Too Big
        messages, there may be a restricting link on the path or the next
        OAL hop may be experiencing reassembly cache congestion.  In both
        cases, the node should adaptively decrease the size of the OAL
        fragments it sends to this OAL next hop (note that the PTB
        messages could indicate either "hard" or "soft" errors).

     *  When an AERO node receives persistent link layer Time Exceeded
        messages, the IP ID field may be wrapping before earlier fragments
        awaiting reassembly have been processed.  In that case, the node
        should adaptively decrease the size of the OAL fragments it sends
        to this OAL next hop.

     *  When an AERO node receives persistent link layer Destination
        Unreachable messages in response to carrier packets that it sends
        to one of its neighbor correspondents, the node should process the
        message as an indication that a path may be failing, and
        optionally initiate NUD over that path.  If it receives
        Destination Unreachable messages over multiple paths, the node
        should allow future carrier packets destined to the correspondent
        to flow through a default route and re-initiate route
        optimization.

     *  When an AERO Client receives persistent link layer Destination
        Unreachable messages in response to carrier packets that it sends
        to one of its neighbor Proxy/Servers, the Client should mark the
        path as unusable and use another path.  If it receives Destination
        Unreachable messages on many or all paths, the Client should
        associate with a new Proxy/Server and release its association with
        the old Proxy/Server as specified in Section 4.15.3.

     *  When an AERO Proxy/Server receives persistent link layer
        Destination Unreachable messages in response to carrier packets
        that it sends to one of its neighbor Clients, the Proxy/Server
        should mark the underlay path as unusable and use another underlay
        path.

     *  When an AERO Proxy/Server receives link layer Destination
        Unreachable messages in response to a carrier packet that it sends
        to one of its permanent neighbors, it treats the messages as an
        indication that the path to the neighbor may be failing.  However,
        the dynamic routing protocol should soon re-converge and correct
        the temporary outage.








  Templin                 Expires 2 September 2026               [Page 47]


  Internet-Draft                    AERO                        March 2026


     When an AERO Gateway receives a carrier packet for which the network
     layer Destination Address is covered by an MLA prefix or MSP assigned
     to a black-hole route, the Gateway drops the carrier packet if there
     is no more-specific routing information for the destination and
     returns an OMNI interface Destination Unreachable message subject to
     rate limiting.

     AERO intermediate and end systems return ICMPv6 error messages
     intended for an OAL source as secured OAL control messages.  When the
     OAL source receives the message, it can perform authentication and
     either process the message locally or translate it into a network
     layer error to return to the original source.

  4.12.  AERO Mobility Service Coordination

     AERO nodes observes the Router Discovery and Prefix Registration
     specifications and coordinate their autoconfiguration actions with
     the mobility service through RS/RA message exchanges as specified in
     [I-D.templin-6man-omni3].

  4.12.1.  AERO Service Model

     Each AERO Proxy/Server on the OMNI link is configured to respond to
     Client MNP prefix delegation/registration requests based on the
     DHCPv6 service.  Each Proxy/Server is provisioned with a database of
     MNP-to-Client ID mappings for all Clients enrolled in the AERO
     service.  The Client database is maintained by a central
     administrative authority for the OMNI link and securely distributed
     to all Proxy/Servers, e.g., via the Lightweight Directory Access
     Protocol (LDAP) [RFC4511], via static configuration, etc.  Clients
     receive the same MNP service regardless of the Proxy/Servers they
     select and provision their MNPs for downstream-attached node
     addressing on EUN interfaces.  (Note: an OMNI link can instead
     delegate non-correlated MNPs to Clients instead of maintaining a
     common synchronized database.  In that case, each Client may receive
     a different MNP delegation each time it registers with the OMNI
     domain and may need to renumber its downstream-attached EUNs.)

     Clients associate each of their *NET underlay interfaces with FHS
     Proxy/Servers.  Each FHS Proxy/Server locally services one or more of
     the Client's underlay interfaces, and the Client typically selects
     one among them to serve as the MAP Proxy/Server (the Client may
     instead select a "third-party" MAP Proxy/Server that does not
     directly service any of its underlay interfaces).  All of the
     Client's other FHS Proxy/Servers forward proxyed copies of RS/RA
     messages between the MAP Proxy/Server and Client without assuming the
     MAP role functions themselves.




  Templin                 Expires 2 September 2026               [Page 48]


  Internet-Draft                    AERO                        March 2026


     Each Client typically associates with a single MAP Proxy/Server,
     while all other Proxy/Servers are candidates for providing the MAP
     role for other Clients.  A Client can select both an FHS and MAP
     Proxy/Server in a single message by including an SRH in the RS
     message OAL header when it already knows the MAP's address.  An FHS
     Proxy/Server assumes the MAP role when it receives an RS message with
     a Destination Address that matches its own MLA or link-scoped All-
     Routers multicast.  An FHS Proxy/Server assumes the proxy role when
     it receives an RS message with an SRH or with a Destination Address
     that matches another Proxy/Server.  (An FHS Proxy/Server can also
     assume the proxy role when it receives an RS message addressed to
     link-scoped All-Routers multicast if it can determine the MLA of
     another Proxy/Server to serve as a MAP.)

     AERO Clients and Proxy/Servers use control messages to maintain
     NLNCEs and ALNCEs.  AERO Proxy/Servers configure their OMNI
     interfaces as advertising NBMA interfaces, and therefore send unicast
     RA messages with a short Router Lifetime value (e.g., 2 *
     ReachableTime seconds) in response to a Client's RS message.
     Thereafter, Clients send additional RS messages to keep Proxy/Server
     state alive.

     AERO Clients and FHS/MAP Proxy/Servers include MNP prefix delegation
     parameters in RS/RA messages.  The control messages are exchanged
     between the Client and any FHS Proxy/Servers acting as proxys for the
     MAP Proxy/Server as specified in [I-D.templin-6man-omni3] according
     to the address/prefix management schedule required by the service.
     If the Client knows its MNP in advance, it can include the MNP in its
     prefix delegation request.  If the MAP Proxy/Server accepts the
     Client's MNP assertion (or if it delegates a new MNP for the Client),
     it injects the MLA and MNP into the routing system then establishes
     the necessary neighbor cache state.

     AERO Clients and their FHS Proxy/Servers on MANETs and open INETs
     must establish and maintain Identification synchronization windows in
     their RS/RA exchanges.  The window synchronization provides a well-
     managed Identification value that the Client and Proxy/Server can use
     for validating control messages with authentication signatures.

     All Client and Proxy/Server behaviors for the exchange of RS/RA
     messages are conducted according to the Router Discovery and Prefix
     Delegation specifications found in [I-D.templin-6man-omni3].









  Templin                 Expires 2 September 2026               [Page 49]


  Internet-Draft                    AERO                        March 2026


  4.13.  AERO Address Resolution, Multilink Forwarding and Route
         Optimization

     AERO nodes invoke address resolution, multilink forwarding and route
     optimization when they need to forward the initial original IP
     packets of flows to new neighbors over (M)ANET/INET interfaces as
     well as to maintain continuous multilink forwarding coordination with
     existing neighbors.  As specified in [RFC4861], "when a node has a
     unicast packet to send to a neighbor, but does not know the
     neighbor's link-layer address, it performs address resolution".

     Possible Source and Destination Addresses for original IP packets
     that traverse a local (M)ANET/INET and/or the rest of the OMNI link
     include addresses taken from an FNP, MNP or MLA assigned to a Client.
     The flow is then identified by the 3-tuple consisting of the IPv6
     Source Address, Destination Address and Flow Label.

     The Address Resolution Source (ARS) considers candidate original IP
     packet destinations as either on-link or off-link on the OMNI
     interface.  For destinations that match an on-link prefix, the ARS
     invokes address resolution as a network layer function if there is no
     NLNCE matching the destination.  For destinations that match an off-
     link prefix, the ARS forwards the packet to a virtual router function
     within the OMNI interface that invokes address resolution as an
     adaptation layer function if there is no ALNCE matching the
     destination.  The first such address resolution may return prefix
     information sufficient to satisfy future resolutions for addresses
     covered by the same prefix locally and without the need for
     additional control messaging over the network.

     Address resolution is based on an IPv6 ND NS/NA(AR) messaging
     exchange between the ARS and the target neighbor as the Address
     Resolution Target (ART).  The ARS engages address resolution by
     sending NS(AR) messages over a selected underlay interface to
     determine adaptation and underlay address mappings for the ART
     network layer address.  (The ARS may select any available underlay
     interface to carry the NS(AR) with a likely emphasis on the best
     performing, least congested, etc.)

     The ARS then discovers address resolution information from any OMNI
     Interface Attributes sub-options included in NA(AR) messages returned
     by the ART.  Both the ARS and ART can update their neighbor caches
     based on the address resolution information and cache any information
     received in Route Information Options (RIOs) [RFC4191] included in
     the NS/NA(AR) exchange.  Note that the NS/NA(AR) RIOs are included as
     adaptation layer information in the OMNI option per
     [I-D.templin-6man-omni3] and are not delivered to the network layer.




  Templin                 Expires 2 September 2026               [Page 50]


  Internet-Draft                    AERO                        March 2026


     The original source or its current FHS/MAP Proxy/Server serves as the
     ARS.  Either the ART itself or the current LHS/MAP Proxy/Server (or
     Relay) for the ART serves as the Address Resolution Responder (ARR),
     i.e., the NA(AR) source.

     Address resolution is initiated by the first eligible ARS closest to
     the original source as follows:

     *  For Clients on VPN/IPsec and Direct interfaces, the Client's FHS
        Proxy/Server is the ARS.

     *  For Clients on (M)ANET interfaces, either the FHS Proxy/Server or
        the Client itself may be the ARS.

     *  For Clients on INET interfaces, the Client itself is the ARS.

     *  For FNP correspondent nodes on foreign links/networks serviced by
        a Relay, the Relay is the ARS.

     *  For Clients that engage the MAP Proxy/Server in "mobility anchor"
        mode, the MAP Proxy/Server is the ARS.

     *  For peer Clients within the same (M)ANET/EUN, address resolution
        and route optimization is through receipt of Redirect messages.

     The AERO routing system directs an address resolution request sent by
     the ARS to the ARR.  The ARR then returns an address resolution reply
     which must include information that is complete, current, consistent
     and authentic.  Both the ARS and ARR are then jointly responsible for
     periodically refreshing the address resolution, and for quickly
     informing each other of any changes.  Following address resolution,
     the ARS and ART perform subsequent multilink forwarding and route
     optimization exchanges to maintain optimal forwarding profiles for
     each distinct flow.

     The address resolution, multilink forwarding and route optimization
     procedures are specified in the following sections.

  4.13.1.  Multilink Address Resolution

     Address resolution over OMNI interfaces is conceptually the same as
     specified in Section 7 of [RFC4861] including the sending and
     receiving of NS/NA(AR) messages as well as their implications for
     neighbor cache entry creation and state management.  The NS/NA(AR)
     messages include addresses and S/TLLAOs in the same manner as for any
     interface and as discussed in Section 4.5.1.  The OMNI interface
     therefore exhibits an IP layer behavior that is indistinguishable
     from an ordinary interface while managing adaptation layer state at a



  Templin                 Expires 2 September 2026               [Page 51]


  Internet-Draft                    AERO                        March 2026


     layer below IP.

     For destinations that match an off-link prefix, Address Resolution
     over OMNI interfaces is driven by NS/NA(AR) messaging as an
     adaptation layer function without disturbing the NLNCE.  The network
     layer forwards packets that match an off-link prefix to a virtual
     router function within the OMNI interface.  The virtual router
     function then either forwards the packets to an FHS Proxy/Server to
     act as the ARS or initiates an NS/NA(AR) exchange at the adaptation
     layer (without including S/TLLAOs) while acting as an ARS on its own
     behalf.  In that case, the OMNI interface caches any updated
     adaptation layer addressing information received in NS/NA(AR)
     messages in the ALNC.

     For destinations that match an on-link prefix, Address Resolution
     over OMNI interfaces is driven by network layer NS/NA(AR) messaging
     the same as for any IP interface.  The OMNI interface then removes
     the S/TLLAO upon transmission of all NS/NA(AR) messages and includes
     an S/TLLAO with the OMNI interface internal link-layer address when
     delivering an NS/NA(AR) message to the network layer.

     When one or more original IP packets matching an on-link prefix are
     forwarded over an OMNI interface, the ARS checks the Destination
     Cache to determine whether there is a NCE that matches the
     Destination Address.  If there is a NCE in the REACHABLE state, the
     ARS invokes the OAL and forwards the resulting carrier packets
     according to the cached state then returns from processing.  If there
     is no NLNCE but the ARS is able to determine that adaptation layer
     mapping state for the IP destination is available, e.g., by snooping
     the ALNC, it can also create a NLNCE in the REACHABLE state and admit
     the original IP packets into the interface without requiring an NS/
     NA(AR) exchange.

     Otherwise, if there is no NLNCE the ARS creates one in the INCOMPLETE
     state.  The ARS then prepares an Address Resolution NS(AR) message to
     send toward an ART.  The resulting NS(AR) message must be sent
     securely and includes Source, Destination and Target Addresses as
     discussed in Section 4.5.1.

     When the ARS admits the NS(AR) message into the OMNI interface, the
     adaptation layer returns an immediate NA(AR) if the ALNC already
     contains fresh address resolution information for the FNP/MNP prefix
     or MLA that covers the IP Destination Address.  Otherwise, the
     adaptation layer prepares to forward the NS(AR) while removing the
     SLLAO (if present) since the locally-unique link-layer address has no
     useful information for prospective neighbors.





  Templin                 Expires 2 September 2026               [Page 52]


  Internet-Draft                    AERO                        March 2026


     For both the on-link and off-link cases of forwarding an NS(AR) at
     the adaptation layer, the ARS then includes an OMNI option with an
     authentication sub-option (if necessary).  If the ARS can commit to
     managing its own dynamic mobility updates, it then includes Interface
     Attributes and/or Traffic Selectors for all of the source Client's
     underlay interfaces plus RIOs for any of the Client's MNPs.  The ARS
     then then submits the NS(AR) message for OAL encapsulation and
     transmission.

  4.13.1.1.  Sending the NS(AR)

     When the ARS is a FHS Proxy/Server, it sets the OAL Source Address to
     its own MLA and sets the OAL Destination Address to the NS(AR) Target
     Address.  The ARS then performs underlay encapsulation and sends the
     resulting carrier packet into the SRT secured spanning tree without
     decrementing the network layer TTL/Hop Limit field.

     When the ARS is a Client, it instead uses its own MLA as the OAL
     Source Address and the MLA of the next OAL hop as the OAL Destination
     Address while including an SRH with the MLAs of OAL intermediate
     systems ending with the MLA of the interface-specific FHS Proxy/
     Server.  If the Client is in a MANET or an open INET, it next
     calculates and includes an authentication signature.  In all *NET
     cases, the Client then includes an OAL IPv6 Extended Fragment Header
     with Identification set to an in-window value for this FHS Proxy/
     Server.  The ARS Client then performs underlay encapsulation and
     forwards the carrier packet to the FHS Proxy/Server.

     The FHS Proxy/Server then performs underlay decapsulation, verifies
     the Identification, verifies the NS(AR) OAL checksum/authentication
     signature and confirms that the Client's claimed FNP/MNP RIO(s) and
     Source Address are correct.  The FHS Proxy/Server then changes the
     OAL Source Address to its own MLA and changes the OAL Destination
     Address to the NS(AR) Target Address.  The FHS Proxy/Server next
     removes the IPv6 Extended Fragment Header, performs underlay
     encapsulation and sends the resulting carrier packet into the secured
     spanning tree on behalf of the Client.

     Note: both the source and target Client/Relay and their MAP Proxy/
     Servers include current and accurate information for their multilink
     Interface Attributes profile.  The MAP Proxy/Servers can be trusted
     to provide an authoritative ARR response and/or mobility update
     message on behalf of the source/target if necessary.








  Templin                 Expires 2 September 2026               [Page 53]


  Internet-Draft                    AERO                        March 2026


  4.13.1.2.  Relaying the NS(AR)

     When a Gateway receives carrier packets containing the NS(AR), it
     performs underlay decapsulation and determines the next hop by
     consulting its standard IPv6 forwarding table for the OAL header
     Destination Address.  The Gateway next decrements the OAL header Hop
     Limit, performs underlay encapsulation and sends the carrier
     packet(s) via the secured spanning tree the same as for any IPv6
     router where they may traverse multiple intermediate OMNI link
     segments interconnected by Gateways.  The final Gateway will deliver
     the carrier packets via the secured spanning tree to the LHS/MAP
     Proxy/Server (or Relay) that services the ART.

  4.13.1.3.  NS(AR) Processing at the ARR/ART

     When the LHS/MAP Proxy/Server (or Relay) of the ART receives the
     NS(AR) secured carrier packets with the target address of the ART as
     the OAL Destination Address, it performs underlay decapsulation then
     either forwards the NS(AR) to the ART or processes it locally if it
     is acting as the ART's designated ARR.  The LHS/MAP Proxy/Server (or
     Relay) processes the message as follows:

     *  if the NS(AR) target matches a Client NCE in the DEPARTED state,
        the (old) MAP Proxy/Server resets the OAL Destination Address to
        the MLA of its new MAP Proxy/Server.  The old MAP Proxy/Server
        then decrements the OAL header Hop Limit, performs underlay
        encapsulation and forwards the resulting carrier packet over the
        secured spanning tree.

     *  If the NS(AR) target matches a Client NCE in the REACHABLE state,
        the LHS/MAP Proxy/Server (or Relay) notes whether the NS(AR)
        arrived from the secured spanning tree.  If the message arrived
        via the secured spanning tree the LHS/MAP Proxy/Server (or Relay)
        verifies the NS(AR) OAL checksum only; otherwise, it must also
        verify the authentication signature.

     *  If the LHS/MAP Proxy/Server maintains a Report List for the ART
        (see: [I-D.templin-6man-omni3]), it next records the NS(AR) Source
        Address in the Report List for this ART.  If the MAP Proxy/Server
        is the ART's designated ARR, it forwards any original IP packet(s)
        attached to the NS(AR) composite packet to the ART and prepares to
        return an NA(AR) as discussed below; otherwise, the LHS/MAP Proxy/
        Server determines the underlay interface for the ART and proceeds
        as follows:

        -  If the LHS/MAP Proxy/Server is also the LHS Proxy/Server on the
           underlay interface used to convey the NS(AR) to the ART, it
           includes an OAL IPv6 Extended Fragment Header with an in-window



  Templin                 Expires 2 September 2026               [Page 54]


  Internet-Draft                    AERO                        March 2026


           Identification for the ART Client plus an SRH and
           authentication signature if necessary then recalculates the OAL
           checksum.  The Proxy/Server then changes the OAL Source Address
           to its own MLA, changes the OAL Destination Address to the next
           hop MLA on the path to the ART, decrements the OAL Hop Limit,
           performs underlay encapsulation and forwards the resulting
           carrier packet over the underlay interface to the ART.

        -  If the MAP Proxy/Server is not the LHS Proxy/Server on the
           underlay interface used to convey the NS(AR) to the ART, it
           instead changes the OAL Destination Address to the MLA of the
           LHS Proxy/Server for the selected ART interface.  The MAP
           Proxy/Server next decrements the OAL Hop Limit, performs
           underlay encapsulation and forwards the resulting carrier
           packet over the secured spanning tree.

        -  When the LHS Proxy/Server receives the carrier packets, it
           performs underlay decapsulation, verifies the NS(AR) OAL
           checksum, then forwards to the ART while changing the OAL
           addresses as above.  The LHS Proxy/Server also includes an IPv6
           Extended Fragment Header plus an SRH and authentication
           signature if necessary while recalculating the checksum the
           same as described above.

     *  If the NS(AR) target matches one of its FNP routes, the MAP/LHS
        Proxy/Server serves as both a Relay and an ARR, since the Relay
        forwards original IP packets toward FNP target nodes at the
        network layer.

     If the ARR is a Relay or the ART itself, it first creates or updates
     an ALNCE for the NS(AR) Source MLA while caching all Interface
     Attributes and Traffic Selector information in the ALNCE and caching
     any IPv6 addresses for the original source found in the Interface
     Attributes in the Destination Cache.  The ARR then installs any RIO
     MNP prefixes in the ALNCE.  (If the NS(AR) does not include address
     resolution information, the ART will simply need to initiate another
     unidirectional address resolution request if it has return traffic to
     send back to the ARS.)

     Next, if the NS(AR) target is on-link on the ARR/ART's OMNI interface
     the ART delivers the NS(AR) to the network layer while including an
     SLLAO with the OMNI interface internal link-layer address.  The
     network layer will return an NA(AR) with a TLLAO which the ARR
     removes before forwarding the NA(AR) back to the ARS.  For off-link
     targets, the ARR instead prepares a solicited NA(AR) message to
     return to the ARS as an adaptation layer function without exposing
     the NS(AR) to the network layer.




  Templin                 Expires 2 September 2026               [Page 55]


  Internet-Draft                    AERO                        March 2026


     In both the on- and off-link cases, the ARR includes RIOs for all of
     the ART's FNPs/MNPs, where the RIO for a destination that matches
     only "default" includes a /64 FNP that covers the address.  The ARR
     then includes Interface Attributes and Traffic Selector sub-options
     for all of the ART's underlay interfaces with current information for
     each interface.  The ARR next sets the NA(AR) message R flag to 1 (as
     a router) and S flag to 1 (as a response to a solicitation) and sets
     the O flag to 1 (as an authoritative responder).

     The ARR finally includes an authentication signature, an IPv6
     Extended Fragment Header and an OAL SRH with MLA addressing
     information for the LHS hops on the path to the LHS Proxy/Server and
     ending with the MLA of the ARS MAP/FHS Proxy/Server that appeared in
     the NS(AR) SRH.  The ARR next calculates the NA(AR) OAL checksum then
     submits the NA(AR) for encapsulation with OAL Source Address set to
     its own MLA and Destination Address set to either the MLA that
     appeared in the NS(AR) OAL source for (M)ANET traversal or the NS(AR)
     source itself for INET traversal.  The ARR then performs underlay
     encapsulation and forwards the resulting carrier packet.

     When the ART's LHS Proxy/Server receives carrier packets sent by an
     ART acting as an ARR on its own behalf, it performs underlay
     decapsulation then verifies the NA(AR) message OAL Identification and
     checksum/authentication signature.  The Proxy/Server then verifies
     that any RIO information is acceptable, changes the OAL Source
     Address to its own MLA and changes the OAL Destination Address to the
     MLA of the ARS MAP/FHS Proxy/Server.  The Proxy/Server next
     decrements the OAL Hop Limit, removes the OAL Extended Fragment
     Header, performs underlay encapsulation and finally forwards the
     resulting carrier packet into the secured spanning tree.

  4.13.1.4.  Relaying the NA(AR)

     When a Gateway receives NA(AR) carrier packets, it performs underlay
     decapsulation and determines the next hop by consulting its standard
     IPv6 forwarding table for the OAL header Destination Address.  The
     Gateway then decrements the OAL header Hop Limit, performs underlay
     encapsulation and forwards the resulting carrier packet via the SRT
     secured spanning tree where it may traverse multiple intermediate
     OMNI link segments interconnected by other Gateways.  The final-hop
     Gateway will deliver the carrier packets via the secured spanning
     tree to a FHS Proxy/Server for the ARS.









  Templin                 Expires 2 September 2026               [Page 56]


  Internet-Draft                    AERO                        March 2026


  4.13.1.5.  Processing the NA(AR) at the ARS

     When the ARS receives NA(AR) carrier packets, it performs underlay
     decapsulation then searches for an ALNCE that matches the MLA
     corresponding to the NA(AR) Source.  The ARS then processes the
     message the same as for standard IPv6 Address Resolution [RFC4861].
     In the process, it caches all OMNI option Interface Attributes and
     Traffic Selectors in the ALNCE for the NA(AR) MLA Source Address and
     caches any IPv6 addresses for the ART found in the Interface
     Attributes in the Destination Cache.  The ARS then caches any RIO
     FNP/MNP prefixes in the ALNCE indexed by the neighbor's MLA.  All
     included Interface Attributes sub-options plus RIOs together provide
     the address mapping information necessary to satisfy address
     resolution.

     For targets that match an on-link prefix, the adaptation layer of the
     ARS then includes a TLLAO with the OMNI interface internal link-layer
     address then delivers the NA(AR) to the network layer.  The network
     layer will then set the NLNCE for this neighbor to REACHABLE while
     caching the link-layer address.  Future original IP packet
     transmissions over the OMNI interface will use this IP to link-layer
     address mapping the same as for any IPv6 interface.

     When the ARS is a Client, the SRT secured spanning tree will first
     deliver the solicited NA(AR) message to the Client's FHS Proxy/
     Server, which includes an OAL Extended Fragment Header with an in-
     window Identification for this Client, and forwards the message to
     the Client.  If the Client is on a well-managed ANET, physical
     security and protected spectrum ensures security for the NA(AR)
     without needing an additional authentication signature or
     Identification; if the Client is in a MANET or in the open INET the
     Proxy/Server must instead include an Identification and
     authentication signature.  The Proxy/Server then includes an SRH,
     changes the OAL Source Address to its own MLA and changes the OAL
     Destination Address to the MLA of the next hop on the path to the
     Client when it forwards the NA(AR).  The Proxy/Server then decrements
     the OAL Hop Limit, performs underlay encapsulation and forwards the
     resulting carrier packet over the underlay interface to the Client.
     When the Client receives the NA(AR), it caches the adaptation layer
     information as above then removes the OMNI option and forwards the
     NS(AR) to the network layer if the target is on-link.  The Client is
     then responsible for informing the ART if any of its adaptation layer
     addressing changes (e.g., due to mobility) before the ALCNE expires.








  Templin                 Expires 2 September 2026               [Page 57]


  Internet-Draft                    AERO                        March 2026


  4.13.1.6.  Reliability

     After the ARS transmits the first NS(AR), it should wait up to
     RETRANS_TIMER seconds to receive a responsive NA(AR).  The ARS can
     then retransmit the NS(AR) up to MAX_UNICAST_SOLICIT times before
     giving up.

  4.13.2.  Multilink Forwarding

     Following address resolution, the ARS and ART (i.e., the end system
     Clients or their respective Proxy/Servers) can assert per-flow
     unidirectional multilink forwarding paths through underlay interface
     pairs serviced by the same Source/Destination Addresses and Flow
     Label by sending MP messages with OMNI Neighbor Synchronization sub-
     options and with an OAL SRH with an AVFI option with (I)nitialize set
     to 1.  The MP messages establish per-flow multilink forwarding and
     header compression state in OAL intermediate systems in the forward
     path from the source to the target.  Note that either the ARS or ART
     can independently initiate multilink forwarding by sending MP
     messages on behalf of specific flows over underlay interface pairs.

     The source Client or FHS Proxy/Server creates MP messages by
     including OMNI option trailers for original IP packets.  The source
     finally performs OAL encapsulation with Source and Destination
     addresses set the same as for address resolution while including an
     SRH extension.  The flow 3-tuple is then identified by the MP Source
     Address, Destination Address and Flow Label.  After sending initial
     MP messages for a flow, the OAL source can begin applying header
     compression for additional messages for the flow.

     The multilink forwarding profile provides support for redundant paths
     that each OAL node can harness to its best advantage.  For example,
     OAL nodes can use traffic selectors to distribute different traffic
     types over available multilink paths, while other factors such as
     metrics, cost, provider, etc. can also provide useful decision
     points.  OAL nodes can also employ multilink forwarding for fault
     tolerance by sending redundant data over multiple paths
     simultaneously, or for load balancing where the individual packets of
     a single traffic flow are spread across multiple independent paths.
     OAL nodes that engage in multilink forwarding therefore must
     incorporate a policy engine that selects both inbound and outbound
     multilink paths for a given traffic profile at a given point in time.
     This specification therefore provides multilink forwarding mechanisms
     without mandating any specific multilink policy.

     All Client, Proxy/Server and Gateway nodes that configure OMNI
     interfaces and engage in multilink coordination include an additional
     forwarding table termed the AERO Flow Information Base (AFIB) that



  Templin                 Expires 2 September 2026               [Page 58]


  Internet-Draft                    AERO                        March 2026


     supports OAL packet/fragment forwarding based on original IP packet
     flows over specific OMNI neighbor interface pairs.  The AFIB contains
     per-flow AERO Flow Vectors (AFVs) identified by the underlay address
     of the previous OAL hop plus a value known as the AFV Index (AFVI).
     The AFVs cache uncompressed OAL header information to support
     forwarding of packets with compressed headers as well as previous/
     next-hop addressing and AFVI information.  The AFVs also cache window
     synchronization state (i.e., the starting sequence number and window
     size) for each specific flow.  Using the window synchronization
     state, simple Identification-based data origin authentication is
     enabled at each OAL source, intermediate system and target node.

     Client and Proxy/Server OMNI interfaces manage end system AFIB
     entries in conjunction with their internal ALNC, where the ALNCEs
     link to (possibly) multiple AFVs with one per flow over a specific
     FHS/LHS interface ifIndex pair.  When OMNI interface peers need to
     coordinate, they locate a NLNCE for the peer (established through
     address resolution) then use the ALNCE as a nexus that aggregates
     potentially many AVFs which cache AFVIs to support multilink
     forwarding on a per-flow basis.  Gateway OMNI interfaces and the OMNI
     interfaces of Clients or Proxy/Servers acting as OAL intermediate
     nodes manage transit AFIB entries independently of their internal
     neighbor caches.  These transit AFVs are indexed by the underlay
     address and AFVI supplied by the previous hop.

     OAL source, intermediate system and target nodes create or update
     AFVs/AFVIs when they process an MP message with an OMNI Neighbor
     Synchronization sub-option with the SYN flag set (see:
     [I-D.templin-6man-omni3]).  The source of the initiating MP is
     considered to reside in the "First Hop Segment (FHS)", while the
     destination is considered to reside in the "Last Hop Segment (LHS)".

     The FHS and LHS roles are determined on a per-flow and per-interface-
     pair basis.  After address resolution, either peer is equally capable
     of initiating multilink forwarding on behalf of a specific flow.  The
     peer that sends the initiating MP message with Neighbor
     Synchronization for a specific pair becomes the FHS peer while the
     one that receives the MP becomes the LHS peer for that (flow,
     interface pair) only.  It is therefore commonplace that peers may
     assume the FHS role for some flows while assuming the LHS role for
     others, i.e., even though each peer maintains only a single NCE.

     When an OAL node sends/forwards an MP with an AFVI with the
     (I)nitialize flag set, it creates or updates an AFV, caches the
     Identification window information, caches the OAL IPv6 header and
     caches the flow 3-tuple for compression/decompression of the original
     IP packet header.  The OAL node also records the previous hop
     underlay address and AFVI, then generates a new next hop AFVI or



  Templin                 Expires 2 September 2026               [Page 59]


  Internet-Draft                    AERO                        March 2026


     updates the lifetime of an already-established AFVI.  The next hop
     AFVI should be selected within the range [1 - (2**16-1)] unless all
     values within that range are already in active use.  Otherwise, the
     AFVI must be selected within the range [2**16 - (2**32-1)] while the
     value 0 indicates "AFVI unspecified".  When the OAL node forwards
     future OAL packets/fragments that include the previous hop underlay
     address and AFVI, it can unambiguously locate the correct AFV and use
     the cached information to forward to the next OAL hop.

     OAL nodes cache AFVs for up to ReachableTime seconds following their
     initial creation.  If the node processes another MP message specific
     to an AFV, it updates ReachableTime to REACHABLE_TIME seconds, i.e.,
     the same as for NCEs.  If ReachableTime expires, the node deletes the
     AFV.

     The following sections provide the detailed specifications of these
     MP exchanges for all nodes along the forward and reverse paths.

  4.13.2.1.  FHS Client-Proxy/Server MP Forwarding

     When an FHS OAL source has an original IP packet to send toward an
     LHS OAL target, it first performs address resolution resulting in the
     creation of an ALNCE for the MLA of the target then selects a source
     and target underlay interface pair based on address resolution flow
     bindings.  The FHS source then uses its cached information for the
     target interface as LHS information then prepares an MP message with
     a Neighbor Synchronization sub-option and any necessary
     authentication sub-options.

     The FHS source next creates an AFV then generates and assigns an AFVI
     for the flow over this interface pair; the AFVI (coupled with its UNX
     address) must be unique for its communications to this next OAL hop.
     The FHS source then includes an SRH with segment addressing
     information and with the LHS Proxy/Server MLA as the final address.
     The FHS source finally includes an OMNI Neighbor Synchronization sub-
     option with window synchronization parameters and prepares the MP
     message for transmission while also caching the window
     synchronization parameters in the local AFV.

     If the FHS source is the FHS Proxy/Server, it performs OAL
     encapsulation while setting the OAL Source Address to its own MLA and
     setting the OAL Destination Address to the MLA found in the target
     Interface Attributes.  The FHS Proxy/Server then performs underlay
     encapsulation and forwards the resulting carrier packet into the
     secured spanning tree which will deliver it to an FHS Gateway.






  Templin                 Expires 2 September 2026               [Page 60]


  Internet-Draft                    AERO                        March 2026


     If the FHS source is the FHS Client, it instead includes an
     authentication signature and OAL Extended Fragment Header with an in-
     window Identification for its FHS Proxy/Server if necessary.  If FMT-
     Forward and FMT-Mode are both set, the Client sets the Neighbor
     Synchronization LHS ifIndex to the ifIndex of the target; otherwise,
     it sets the ifIndex to 0 to allow the FHS Proxy/Server to select the
     target ifIndex.  The FHS Client then performs OAL encapsulation while
     including an SRH per [I-D.templin-6man-omni3], sets the OAL Source
     Address to its own MLA and sets the OAL Destination Address to the
     MLA of the first hop toward the FHS Proxy/Server.  The FHS Client
     finally performs underlay encapsulation and forwards the resulting
     carrier packet to the FHS Proxy/Server.

     If there are multiple OAL hops between the Client and FHS Proxy/
     Server, the first OAL intermediate node receives the carrier packets
     containing the MP then also verifies the OAL checksum and
     authentication signature.  The OAL intermediate node then caches the
     FHS/LHS Client addressing, AFVI and window synchronization
     information as previous hop information in a new or existing AFV.
     The OAL intermediate hop then creates a new unique AFVI to forward to
     the next OAL hop, then both caches the AFVI and writes it into the
     control message AVI field, i.e., while over-writing the value
     supplied by the previous hop.  The OAL intermediate node then
     forwards to the next OAL hop toward the FHS Proxy/Server which then
     performs the same functions as the previous OAL hop.

     When the FHS Proxy/Server receives the carrier packets, it performs
     underlay decapsulation, verifies the Identification, and verifies the
     MP OAL checksum and authentication signature.  The FHS Proxy/Server
     then creates an AFV (i.e., the same as the FHS Client had done) while
     caching the FHS/LHS Client addressing, AFVI and window
     synchronization information as previous hop information for this AFV.
     The FHS Proxy/Server next generates a new unique AFVI to forward to
     the next OAL hop, then both caches the AFVI in the AFV and writes it
     into the MP AFVI field.  The FHS Proxy/Server next calculates the MP
     OAL checksum then decrements the OAL Hop Limit, removes the OAL
     Extended Fragment Header, performs underlay encapsulation and
     forwards the resulting carrier packet into the secured spanning tree.

  4.13.2.2.  FHS/intermediate/LHS Gateway MP Forwarding

     Gateways in the spanning tree forward OAL packets/fragments not
     explicitly addressed to themselves, while forwarding those that
     arrived via the secured spanning tree to the next hop also via the
     secured spanning tree and forwarding all others via the unsecured
     spanning tree.  When an FHS Gateway receives an MP message over the
     secured spanning tree, it performs underlay decapsulation then
     verifies the MP OAL checksum.  The FHS Gateway next creates an AFV



  Templin                 Expires 2 September 2026               [Page 61]


  Internet-Draft                    AERO                        March 2026


     based on the previous hop Neighbor Synchronization information, i.e.,
     the same as the FHS Proxy/Server had done.  The FHS Gateway then
     generates a locally-unique AFVI for the next hop and both caches the
     value in the AFV and copies it into the MP AFVI.

     The FHS Gateway then examines the SRT prefixes corresponding to both
     the FHS and LHS.  If the FHS Gateway has a local interface connection
     to both the FHS and LHS (whether they are the same or different
     segments), the FHS/LHS Gateway caches the MP Neighbor Synchronization
     information in the AFV, and writes a new locally-unique AFVI for the
     next hop into the AFV and MP AFVI.  The FHS Gateway then decrements
     the OAL Hop Limit, performs underlay encapsulation and forwards the
     resulting carrier packet into the secured spanning tree.

     When the FHS and LHS Gateways are different, the LHS Gateway will
     receive carrier packets over the secured spanning tree from the FHS
     Gateway, noting there may be many intermediate Gateways in the path
     between FHS and LHS which will update their transit AFVs in the same
     fashion while selecting new locally-unique AFVIs for the next hop
     based on Neighbor Synchronization and SRH information.  The LHS
     Gateway then performs underlay decapsulation, verifies the
     Identification, verifies the MP OAL checksum then creates an AFV
     (i.e., the same as all previous hop Gateways had done) while caching
     the Neighbor Synchronization information from the previous hop and
     creating a new AFVI for the next hop.  The LHS Gateway then
     decrements the OAL Hop Limit, performs underlay encapsulation and
     forwards the resulting carrier packet into the secured spanning tree.

  4.13.2.3.  LHS Proxy/Server-Client MP Processing

     When the LHS Proxy/Server receives the carrier packets from the
     secured spanning tree, it performs underlay decapsulation, verifies
     the MP OAL checksum then creates an AFV and caches the previous hop
     Neighbor Synchronization and addressing information.

     If FMT-Forward is clear and FMT-Mode is set, the LHS Proxy/Server
     next resets the Neighbor Synchronization FHS ifIndex to 0.  The LHS
     Proxy/Server next includes an authentication signature in the MP if
     necessary, changes the OAL Source Address to its own MLA, changes the
     Destination Address to the MLA of the next hop toward the LHS Client
     and includes an SRH with the MLAs of intermediate systems and a new
     AFVI for this flow.  The LHS Proxy/Server then decrements the OAL Hop
     Limit, includes an OAL Extended Fragment Header with an appropriate
     Identification value if necessary, performs underlay encapsulation
     and forwards the resulting carrier packet to the LHS Client.






  Templin                 Expires 2 September 2026               [Page 62]


  Internet-Draft                    AERO                        March 2026


     If there are multiple OAL hops between the LHS Proxy/Server and LHS
     Client, the first OAL intermediate node receives the carrier packet
     containing the MP then also verifies the OAL checksum and
     authentication signature.  The OAL intermediate node then caches the
     FHS/LHS Client addressing, AFVI and window synchronization
     information as previous hop information in a new or existing AFV.
     The OAL intermediate hop then creates a new unique AFVI to forward to
     the next OAL hop, then both caches the AFVI and writes it into the
     MP's SRH, i.e., while over-writing the value supplied by the previous
     hop.  The OAL intermediate node then forwards to the next OAL hop
     toward the LHS Client which then performs the same functions as the
     previous OAL hop.

     When the LHS Client receives the carrier packet, it performs underlay
     decapsulation, verifies the Identification, then verifies the MP OAL
     checksum/authentication signature.  The LHS Client then creates an
     ALNCE for the MP Source Address (if necessary) in the STALE state and
     caches the MP Neighbor Synchronization information in a new AFV
     associated with the NCE corresponding to the MP Source Address.

  4.13.2.4.  Packet Forwarding Following MP Exchanges

     Following initial MP exchanges the OAL source can begin sending
     ordinary carrier packets for the flow that include OCH compressed
     headers with AFVIs and Identification values within their respective
     send windows without requiring security signatures and/or secured
     spanning tree traversal.  OAL end and intermediate systems can also
     consult their AFIBs when they receive carrier packets that contain
     OAL packets/fragments with AFVIs to unambiguously locate the correct
     AFV and can use the AFV state to forward OAL packets/fragments to the
     next hop.  OAL end systems must then occasionally send additional MPs
     to update window state, register new flows for optimized multilink
     forwarding, confirm reachability and/or refresh AFIB cache state in
     the path before ReachableTime expires.

     While the OAL end systems continue to actively exchange OAL packets,
     they are jointly responsible for updating cache state and per-
     interface reachability before expiration.  Window synchronization
     state is performed on a per-flow basis and tracked in the AFVs which
     are also linked to the appropriate NCE.  However, the window
     synchronization exchange only confirms target Client reachability
     over the specific underlay interface pair.  Reachability for other
     underlay interfaces that share the same NCE must be determined
     individually using additional MP messages that include Neighbor
     Synchronization information.






  Templin                 Expires 2 September 2026               [Page 63]


  Internet-Draft                    AERO                        March 2026


     OAL sources can then begin including OCHs in OAL packets/fragments
     with an AFVI that OAL intermediate systems can use for shortest-path
     forwarding based on AFVIs instead of spanning tree OAL IPv6
     addresses.  Forwarding based on the limited OCH information is
     supported since all OAL nodes in the path up to (and sometimes
     including) the OAL destination have already established AFVs.

     When a Proxy/Server receives OAL packets/fragments destined to a
     local SRT segment Client or forwards OAL packets/fragments received
     from a local segment Client, it first locates the correct AFV.  If
     the OAL packet/fragment includes a secured control message, the
     Proxy/Server uses the Client's ALNCE established through RS/RA
     exchanges to re-encapsulate while sending outbound secured carrier
     packets via the secured spanning tree and sending inbound secured
     carrier packets while including an OAL authentication signature/
     checksum.  For ordinary OAL packets/fragments, the Proxy/Server uses
     the same AFV if directed by AFVI and/or OAL addressing.  Otherwise it
     locates an AFV established through an MP exchange between the Client
     and the remote SRT segment peer, and forwards the OAL packet/
     fragments without first reassembling/decapsulating.

     When a source Client forwards OAL packets/fragments it can employ
     header compression according to the AFVs established through an MP
     exchange with a remote or local peer.  When a target Client receives
     carrier packets that contain OAL packets/fragments that match a local
     AFV, the Client first verifies the Identification then decompresses
     the headers if necessary, reassembles to obtain the OAL packet then
     decapsulates and delivers the original IP packet to the network
     layer.

     When synchronized peer Clients in the same SRT segment with FMT-
     Forward and FMT-Mode set discover each other's NATed UNX addresses,
     they can exchange carrier packets that contain OAL packets/fragments
     directly with header compression using AFVIs discovered as above
     (see: Section 4.13.4.3).

  4.13.3.  Mobile Ad-hoc Network (MANET) Forwarding

     Clients with OMNI interfaces configured over underlay interfaces with
     indeterminant neighborhood properties may be connected to a Mobile
     Ad-hoc NETwork (MANET).  Each MANET may be either completely outside
     of the range of any OMNI link Proxy/Servers or may require multihop
     traversal between Clients acting as MANET routers to reach Proxy/
     Servers that connect to the rest of the OMNI link.  The former class
     of MANETs must operate in isolation solely based on the unique IPv6
     MLAs they configure locally.  The latter class allows MANET routers
     to extend infrastructure-based addressing information including MNPs
     over multiple OMNI link hops as discussed in the OMNI specification.



  Templin                 Expires 2 September 2026               [Page 64]


  Internet-Draft                    AERO                        March 2026


     MANET Clients configure their OMNI interfaces over one or more MANET
     interfaces where multihop forwarding may be necessary.  Routing
     protocols suitable for use over MANET interfaces include OSPFv3
     [RFC5340] with MANET Designated Router (OSPF-MDR) extensions
     [RFC5614], OLSRv2 [RFC7181], Babel [RFC8966], AODVv2
     [I-D.perkins-manet-aodvv2] and others.  Other services specific to
     MANET link-local and/or site-local operations (including SMF
     [RFC6621], DLEP [RFC8175] and others) are also considered in-scope.
     These services strive for optimal use of available radio bandwidth
     and power consumption in their control message transmissions, but
     efficient data plane operation is also essential.

     The Client configures the top-level MLA prefix on the OMNI interface
     and configures the MANET routing protocol to populate discovered MLA-
     specific routes in an alternate kernel routing table.  The OAL then
     engages the Netlink socket (or an alternate operating system
     primitive) to monitor the table.  When the MANET routing protocol
     adds, modifies or removes an MLA route the OAL adds/modifies/removes
     a corresponding route within the OMNI interface to allow MLA-
     addressed packets forwarded by the network layer to flow through the
     OMNI interface instead of directly via a MANET interface.  The OMNI
     interface virtual router entity then engages OAL encapsulation and
     header compression before forwarding an OAL packet or fragment via
     the correct MANET underlay interface.  The next hop's OMNI interface
     will then receive the packets from its MANET interface due to the OAL
     encapsulation port/protocol/ethertype.

     Clients must therefore reduce overhead through minimal encapsulation
     and effective header compression whenever possible.  For this reason,
     when the MANET routing protocol discovers a new MLA-based route the
     Client configures a lesser-preferred forwarding table entry over the
     corresponding MANET interface and a more-preferred forwarding table
     entry over the OMNI interface as specified in
     [I-D.templin-6man-omni3].  This will cause the network layer to
     direct outbound packets to the OMNI interface, which can apply header
     compression and underlay MANET interface selection.

     Multilink Clients that connect a MANET to the rest of the OMNI link
     act as regular Clients for exchanges with external INETs, but act as
     Proxy/Servers over their MANET interfaces.  Each such Client
     therefore has at least two underlay interfaces, including both INET
     and MANET interfaces.  The Client therefore services the MANET as if
     it were a Proxy/Server but presents itself as a Client to external
     facing INETs.  This class of Clients are also known as "Proxy/
     Clients".






  Templin                 Expires 2 September 2026               [Page 65]


  Internet-Draft                    AERO                        March 2026


     The process for a multihop Client to establish multilink forwarding
     and header compression AFV state in the MANET is conducted in the
     same fashion as described above and using the same MP message
     exchanges.  Each MANET forwarding node in the path creates or updates
     AFV state in the same fashion as for intermediate Gateways in the
     secured spanning tree except that MP messages require authentication
     signatures (unless neighboring MANET nodes apply lower-layer
     security) and an Identification that is within the window for its
     serving Proxy/Server if the destination is outside of the local MANET
     cluster.  The MP messages extend from the initiating FHS MANET
     Client, then across any MANET hops over intermediate FHS Proxy/
     Clients, then to the FHS Proxy/Server, then across the secured SRT
     spanning tree to the LHS Proxy/Server, then finally across any
     intermediate LHS MANET hops to the responding LHS Client.  (When the
     source and target Client are both within the same local MANET
     cluster, however, the process is conducted directly between the two
     Clients without engaging the FHS Proxy/Server.)  In all other ways,
     the MP message exchanges are the same as discussed in Section 4.13.2.

     Following the MP message exchanges, each MANET router in the forward
     (and optionally also reverse) path in both the FHS and LHS MANETs
     will have established AFVs containing multilink forwarding and header
     compression state for the flow.  The AFVs determine AFVI-based
     forwarding based on the OCH header contents, and each MANET router
     only forwards packets with in-window Identification values for the
     flow.  MANET routers maintain AFVs for up to ReachableTime seconds
     unless they are refreshed by a new MP message.  New window
     synchronization exchanges must also be performed periodically to
     avoid window exhaustion and/or spoofing based on predictable
     Identifications.

  4.13.4.  AERO Route Optimization

  4.13.4.1.  Proxy/Server-to-Proxy/Server Route Optimization

     When the FHS and LHS Proxy/Servers are both connected to an IPv6
     underlay for the same SRT segment, they can forward MP message
     exchanges directly over the underlay without engaging SRT spanning
     tree hops.












  Templin                 Expires 2 September 2026               [Page 66]


  Internet-Draft                    AERO                        March 2026


     If the underlay is not secured, the FHS and LHS Proxy/Servers must
     include an authentication signature with their MP messages, which
     could either be the original authentication signature included by
     their respective Clients or a new signature included by the Proxy/
     Server itself.  If the Proxy/Server that processes the MP message
     determines that the message is authentic, it creates or updates an
     AFV entry according to the multilink forwarding parameters.  This
     establishes both AFVI and Identification window state to be used for
     future data traffic forwarding.

  4.13.4.2.  Gateway-to-Proxy/Server Route Optimization

     When the LHS gateway and FHS Proxy/Server are both connected to an
     IPv6 underlay for the same SRT segment, they can forward MP message
     exchanges directly over the underlay without engaging additional SRT
     spanning tree hops.  In this arrangement, the LHS Gateway acts the
     same as the FHS Proxy/Server as discussed in Section 4.13.4.1 and
     observes the requirement for including authentication signatures.

  4.13.4.3.  Client-to-Client Route Optimization

     When the FHS/LHS Clients are both located on the same SRT segment,
     Client-to-Client route optimization is possible following the
     establishment of any necessary state in NATs in the path.  Both
     Clients will have already established state via their respective
     shared segment Proxy/Servers (and possibly also any shared segment
     Gateways) and can begin sending carrier packets directly via NAT
     traversal while avoiding any Proxy/Server and/or Gateway hops.

     When the FHS/LHS Clients on the same SRT segment perform initial MP
     message exchanges to establish AFIB state, they first examine the
     FMT-Forward and FMT-Mode settings to determine whether direct-path
     forwarding is even possible for one or both Clients (direct-path
     forwarding is only possible when FMT-Forward and FMT-Mode are both
     set).  The MP messages then include an Interface Attributes sub-
     option (i.e., in addition to a Neighbor Synchronization sub-option)
     with the mapped UNX information discovered during the RS/RA exchanges
     with their respective Proxy/Servers.  After the AFV paths have been
     established, both Clients can begin sending carrier packets via
     strict AFV paths while establishing a direct path for Client-to-
     Client route optimization.

     To establish the direct path, either Client (acting as the source)
     transmits a bubble to the mapped UNX for the target Client which
     primes the local chain of NATs for reception of future carrier
     packets from that UNX (see: [RFC4380] and [I-D.templin-6man-omni3]).
     The source Client then prepares an MP message with the MLA/FNP/MNP
     address of a subject packet as the Source Address, with the MLA/FNP/



  Templin                 Expires 2 September 2026               [Page 67]


  Internet-Draft                    AERO                        March 2026


     MNP address of the target as the Target and Destination Address and
     with an OMNI option with an Interface Attributes sub-option.  The
     source Client then encapsulates the MP in an OAL header and SRH
     extension with its own MLA as the Source Address, with the MLA of the
     next OAL hop toward the Proxy/Server as the Destination Address and
     with an in-window Identification for the target.  The source Client
     then performs underlay encapsulation and sends the resulting carrier
     packets to the Proxy/Server which re-encapsulates and sends them as
     unsecured carrier packets according to AFIB state where they will
     eventually arrive at the target Client.

     Following initial MP message exchanges, both Clients mark their
     respective (source, target) underlay interface pairs as "trusted" for
     no more than ReachableTime seconds.  The Clients can then begin
     exchanging ordinary data packets as OCH encapsulated carrier packets.
     While the Clients continue to exchange packets via the direct path
     avoiding all Proxy/Servers and Gateways, they should perform
     additional MP message exchanges via their local Proxy/Servers to
     refresh NCE state as well as send additional bubbles to the peer's
     UNX if necessary to refresh NAT state.

     Note: these procedures apply for a widely-deployed but basic class of
     NATs.  Procedures for advanced NAT classes are outlined in [RFC6081],
     which provides mechanisms that can be employed equally for AERO using
     the corresponding sub-options specified by OMNI.

     Note: each communicating pair of Clients may need to maintain NAT
     state for peer to peer communications via multiple underlay interface
     pairs and/or multiple flows.  It is therefore important that UNX
     information is maintained with the correct peer interface and that
     the NCE may cache information for multiple peer interfaces.

     Note: the source and target Client exchange UNX information during
     the secured MP multilink route optimization exchange.  This allows
     for subsequent MP exchanges to proceed using only the Identification
     value as a data origin confirmation.  However, Client-to-Client
     peerings that require stronger security may also include
     authentication signatures for mutual authentication.

  4.13.4.4.  Intra-(M)ANET/EUN Route Optimization

     When a Client forwards an OAL packet (or an original IP packet) from
     another Client connected to one of its downstream EUNs to a peer
     within the same downstream EUN, the Client returns an IPv6 ND
     Redirect message to inform the source that the target can be reached
     directly.  The contents of the Redirect message are the same as
     specified in [RFC4861] except that the message includes MLAs instead
     of LLAs, and should also include any OMNI option RIOs with MNP



  Templin                 Expires 2 September 2026               [Page 68]


  Internet-Draft                    AERO                        March 2026


     information corresponding to the target.

     In the same fashion, when a Proxy/Server forwards an OAL packet (or
     original IP packet) from a Client connected to one of its downstream
     *NETs to a peer within the same downstream *NET, the Proxy/Server
     returns an IPv6 ND Redirect message.

     All other route optimization functions are conducted per the MP
     messaging discussed in the previous sections.

  4.14.  Neighbor Unreachability Detection (NUD)

     AERO nodes perform Neighbor Unreachability Detection (NUD) per
     [RFC4861] either reactively in response to persistent link layer
     errors (see: Section 4.11) or proactively to confirm reachability.
     The NUD algorithm is based on periodic control message exchanges and
     may further be seeded by IPv6 ND hints of forward progress, but care
     must be taken to avoid inferring reachability based on spoofed
     information.

     For on-link destinations, NUD messaging is driven by the network
     layer under the same conditions as for any interface; for off-link
     destinations, the process is driven by the adaptation layer.  The NS/
     NA(NUD) messages follow the same forwarding and processing rules as
     for address resolution and confirm that the target neighbor is still
     reachable over a selected underlay interface path.  The messages may
     also update NLNCE/ALNCE state if they include address resolution
     information and an authentication signature.

     In order to test additional underlay interface paths, the adaptation
     layer can independently send an NS(NUD) message with an SRH with an
     AFVI with the (I)nitialize flag set to 0 in order to receive an
     NA(NUD) response.  The NS messages may be sent while ordinary data
     packets are flowing to follow already-established paths without
     updating state and therefore need not include an authentication
     signature but should include an OMNI Nonce sub-option.

     When the source receives the NA, it marks the target underlay
     interface tested as "trusted".  Note that underlay interface states
     are maintained independently of the overall NCE REACHABLE state, and
     that a single NCE may have multiple target underlay interfaces in
     various "trusted/untrusted" states while the NCE state as a whole
     remains REACHABLE.








  Templin                 Expires 2 September 2026               [Page 69]


  Internet-Draft                    AERO                        March 2026


  4.15.  Mobility Management and Quality of Service (QoS)

     AERO is a fully Distributed Mobility Management (DMM) service in
     which each Proxy/Server is responsible for only a subset of the
     Clients on the OMNI link.  This is in contrast to a Centralized
     Mobility Management (CMM) service where there are only one or a few
     network mobility collective entities for large Client populations.
     Clients coordinate with their associated FHS and MAP Proxy/Servers
     via RS/RA exchanges to maintain the DMM profile, and the AERO routing
     system tracks all current Client/Proxy/Server peering relationships.

     MAP Proxy/Servers provide an address resolution aggregation point for
     their dependent Clients, while FHS Proxy/Servers provide a proxy
     conduit between the Client and both the MAP and OMNI link in general.
     Clients are responsible for maintaining neighbor relationships with
     their Proxy/Servers through periodic RS/RA exchanges, which also
     serve to confirm neighbor reachability.  When a Client's underlay
     interface attributes change, the Client is responsible for updating
     the MAP Proxy/Server through new RS/RA exchanges using the FHS Proxy/
     Server as a first-hop conduit.  The FHS Proxy/Server can also act as
     a proxy to perform some IPv6 ND exchanges on the Client's behalf
     without consuming bandwidth on the Client underlay interface.

     Note: when a Client's underlay interface address changes, the Client
     and/or its (former) FHS Proxy/Server for this interface must
     invalidate any AFVs based on the (changed) interface.  Future data
     packet forwarding will then trigger a new multilink forwarding MP
     message exchange to re-populate new AFVs in the path.

     Mobility management considerations are specified in the following
     sections.

  4.15.1.  Registering Link-Layer Information Changes

     When a Client needs to change its underlay Interface Attributes and/
     or Traffic Selectors for one or more underlay interfaces (e.g., due
     to a mobility event), it sends RS messages to its MAP Proxy/Server
     via new FHS Proxy/Servers if necessary.  Each RS includes an OMNI
     option with Interface Attributes and/or Traffic Selector sub-options
     for the ifIndex in question.











  Templin                 Expires 2 September 2026               [Page 70]


  Internet-Draft                    AERO                        March 2026


     Note that the FHS Proxy/Server may change due to an underlay
     interface connectivity change or an intentional switch to a new
     Proxy/Server.  If the Client RS includes an OMNI Proxy/Server
     Departure sub-option for the former FHS Proxy/Server, the new FHS
     Proxy/Server can send a departure indication (see: Section 4.15.3);
     otherwise, any stale state in the former FHS Proxy/Server will simply
     expire after ReachableTime expires with no effect on the MAP Proxy/
     Server.

     Up to MAX_RTR_SOLICITATIONS RS messages MAY be sent in parallel with
     sending carrier packets containing user data in case one or more RAs
     are lost.  If all RAs are lost, the Client SHOULD re-associate with a
     new Proxy/Server.

     When a Client needs to bring new underlay interfaces into service
     (e.g., when it activates a new data link), it sends an RS message to
     the MAP Proxy/Server via a FHS Proxy/Server for the underlay
     interface (if necessary) with an OMNI option that includes an
     Interface Attributes sub-option with interface parameters and with
     address resolution information for the new link.

  4.15.2.  Deactivating Existing Links

     When a Client needs to deactivate an existing underlay interface, it
     sends an RS message toward the MAP Proxy/Server via an FHS Proxy/
     Server with an OMNI option with appropriate Interface Attributes
     values for the deactivated link.

     If the Client needs to send RS messages over an underlay interface
     other than the one being deactivated, it MUST include current
     Interface Attributes for the link used as the first sub-option as
     well as additional Interface Attributes for any underlay interfaces
     being deactivated as additional sub-options with ifMetric set to
     'ffffffff'.  The Client (or its MAP Proxy/Server) then again sends
     uNA messages to all neighbors the same as described above.

     Note that when a Client deactivates an underlay interface, neighbors
     that receive the ensuing uNA messages need not purge all references
     for the underlay interface from their NCEs.  The Client may
     reactivate or reuse the underlay interface and/or its ifIndex at a
     later point in time, when it will send new RS messages to an FHS
     Proxy/Server with fresh interface parameters to update any neighbors.
     The manner in which the Client dynamically manages its local ifIndex
     to interface mappings is a local decision, but should not be done in
     a manner that could cause state inconsistencies in the network.






  Templin                 Expires 2 September 2026               [Page 71]


  Internet-Draft                    AERO                        March 2026


  4.15.3.  Moving Between Proxy/Servers

     When a Client associates with a new MAP Proxy/Server, it sends RS
     messages to register its underlay interfaces with the new MAP while
     including the departed MAP's MLA in a Proxy/Server Control OMNI sub-
     option.  When the new MAP Proxy/Server returns an RA message via the
     FHS Proxy/Server (acting as a proxy), the FHS Proxy/Server sends a
     uNA to the departed MAP Proxy/Server if the departed MLA is other
     than ::/128.  Note that the FHS Proxy/Server defers the uNA
     transmission until after the new MAP has responded for reliability
     purposes; if even greater reliability is needed, the FHS Proxy/Server
     can instead send an NS(NUD) message to receive an NA(NUD) response.

     The FHS Proxy/Server sets the uNA Source Address to the MLA of the
     new MAP, sets the Target Address to the Client's MLA and sets the
     Destination Address to the MLA of the departed MAP.  The FHS Proxy/
     Server then includes a Proxy/Server Control OMNI sub-option with the
     M flag set to 1 and all other flags set to 0 and with no departed
     addresses included.  The FHS Proxy/Server then encapsulates the uNA
     in an OAL header with its own MLA as the Source Address and the MLA
     of the departed MAP as the Destination Address, then performs
     underlay encapsulation and forwards the resulting carrier packet via
     the secured spanning tree.

     When the departed MAP Proxy/Server receives the carrier packet, it
     decapsulates to obtain the uNA and examines the Proxy/Server Control
     sub-option M flag.  If the M flag is 1 the departed MAP Proxy/Server
     then changes the Client's NCE state to DEPARTED, resets DepartTime
     and caches the new MAP Proxy/Server MLA.  After a short delay (e.g.,
     2 seconds) the departed MAP Proxy/Server withdraws the Client's MLA
     and MNP(s) from the routing system.  While in the DEPARTED state, the
     departed MAP Proxy/Server forwards any carrier packets received via
     the secured spanning tree destined to the Client's MNP addresses to
     the new MAP Proxy/Server's MLA.  When DepartTime expires, the
     departed MAP Proxy/Server deletes the Client's NCE.

     Mobility events may also cause a Client to change to a new FHS Proxy/
     Server over a specific underlay interface at any time such that a
     Client RS/RA exchange over the underlay interface will engage the new
     FHS Proxy/Server instead of the old.  The Client can arrange to
     inform the old FHS Proxy/Server of the departure by including a
     Proxy/Server Control sub-option with the MLA of the departed FHS
     Proxy/Server.  The new FHS Proxy/Server will issue a uNA (or NS/NA)
     using the same procedures as outlined for the MAP above.

     The new FHS Proxy/Server sets the uNA Source Address its own MLA,
     sets the Target Address to the Client's MLA and sets the Destination
     Address to the MLA of the departed FHS Proxy/Server.  The new FHS



  Templin                 Expires 2 September 2026               [Page 72]


  Internet-Draft                    AERO                        March 2026


     Proxy/Server then includes a Proxy/Server Control OMNI sub-option
     with the P flag set to 1 and all other flags set to 0 and with no
     departed addresses included.  The new FHS Proxy/Server then
     encapsulates the uNA in an OAL header with its own MLA as the Source
     Address and the MLA of the old FHS Proxy/Server as the Destination
     Address, then performs underlay encapsulation and forwards the
     resulting carrier packet via the secured spanning tree.

     When the departed FHS Proxy/Server receives the uNA, it updates the
     Client's MLA to the address of the new FHS Proxy/Server and sets the
     NCE state to DEPARTED.  The departed FHS Proxy/Server can then
     forward any packets it receives for the Client to its new FHS Proxy/
     Server.  The departed FHS Proxy/Server's NCE for the Client will then
     naturally expire if no further RS message arrive.  This can often
     result in successful delivery of carrier packets that would otherwise
     be lost temporarily due to the mobility event.

     Clients SHOULD NOT move rapidly between MAP Proxy/Servers in order to
     avoid causing excessive oscillations in the AERO routing system.
     Examples of when a Client might wish to change to a different MAP
     Proxy/Server include a MAP Proxy/Server that has become unresponsive,
     topological movements of significant distance, movement to a new
     geographic region, movement to a new OMNI link segment, etc.

     Note that a Client simultaneous change to both a new FHS and MAP
     Proxy/Server is signaled by the new FHS when it sends a uNA to both
     the departed FHS and MAP Proxy/Server.  If both the departed FHS/MAP
     are one and the same, and the new FHS/MAP are one and the same, the
     new FHS sends a single uNA (or NS/NA) with both the M and P flags set
     to 1, i.e., it need not send multiple messages.

  4.15.4.  Mobility Update Messaging

     Mobile Clients (and/or their MAP Proxy/Servers) accommodate mobility
     and/or multilink change events by sending secured uNA messages to
     each neighbor that previously received address resolution
     information.  When a node sends a uNA message to each specific
     neighbor on behalf of a mobile Client, it sets the IPv6 Source and
     Target Address to the Client's MLA then sets the Destination Address
     to the neighbor's MLA.

     The node then encapsulates the uNA in an OAL header with Source set
     to its own MLA and Destination set to the MLA of the neighbor.  The
     node also includes an OMNI option with Interface Attributes and
     Traffic Selector sub-options for any of the mobile Client's underlay
     interfaces that may have changed values and includes an
     authentication signature if necessary.




  Templin                 Expires 2 September 2026               [Page 73]


  Internet-Draft                    AERO                        March 2026


     The node next sets the uNA R flag to 1, S flag to 0 and O flag to 1,
     then encapsulates the message in an OAL header.  Following OAL and
     underlay encapsulation, the carrier packet containing the uNA message
     will then follow the secured spanning tree and arrive at the specific
     neighbor.

     As discussed in Section 7.2.6 of [RFC4861], the transmission and
     reception of uNA messages is unreliable but provides a useful
     optimization.  In well-connected Internetworks with robust data links
     uNA messages will be delivered with high reliability, but in any case
     the node can optionally send up to MAX_NEIGHBOR_ADVERTISEMENT uNAs to
     each neighbor to increase the likelihood that at least one will be
     received.  Alternatively, the node can send an NS(MM) message to
     solicit an NA(MM) response as discussed in Section 4.5.1.

     When the neighbor receives a uNA with address resolution changes, it
     marks any AFVs in its ALNCE for the uNA source that were established
     based on now-obsolete information as STALE.  When the neighbor
     forwards the next packet for an affected flow, it initiates a new
     multilink forwarding exchange as specified in Section 4.13.2 to
     refresh AFVI state for the path.

  4.15.5.  Accommodating Path Changes

     After AFV state has been established for a flow, all OAL intermediate
     systems in the forward path will have AFVs with header compression
     state and (AFVI, UNX) information for the next hop.  However, paths
     can fluctuate due to factors such as node mobility, routing changes,
     network membership, etc.  If an OAL intermediate system forwarding
     OAL packets with OCH headers detects that the next hop in the path
     has changed, it immediately reverts to sending the packets with
     header compression disabled (by including full OAL IPv6 and Extended
     Fragment Headers, an SRH with AFVI set to 0 plus a full original IP
     header) in future packets

     When the OAL destination begins to receive OAL packets with full
     headers (i.e., when it had previously received authentic MP messages
     for this flow), it assumes that the network path has changed and
     begins returning control messages to the OAL source.  The OAL
     destination sends ICMPv6 Error control messages with Type 4
     ("Parameter Problem"), with Code TBD ("Compressed header expected" -
     see IANA Considerations) and with at least the full uncompressed
     original IP packet header in the packet-in-error field.  The OAL
     destination then delivers the packet to upper layers.

     When the OAL source receives the ICMPv6 messages, it refreshes
     multilink forwarding state for this flow by issuing new MP messages
     the same as for a new flow as specified in Section 4.13.2.  OAL



  Templin                 Expires 2 September 2026               [Page 74]


  Internet-Draft                    AERO                        March 2026


     intermediate nodes in the former path will then simply purge the
     stale AFV state when it expires.  The OAL source does not report an
     error to upper layers as the OAL destination has already accepted the
     packet.

  4.16.  Multicast

     Each Client provides an IGMP (IPv4) [RFC2236] or MLD (IPv6) [RFC3810]
     proxy service for its EUNs and/or hosted applications [RFC4605] and
     acts as a Protocol Independent Multicast - Sparse-Mode (PIM-SM, or
     simply "PIM") Designated Router (DR) [RFC7761] on the OMNI link.
     Proxy/Servers act as OMNI link PIM routers for Clients on ANET, VPN/
     IPsec or Direct interfaces, and Relays also act as OMNI link PIM
     routers on behalf of nodes on other links/networks.

     Clients on VPN/IPsec, Direct or (M)ANET underlay interfaces for which
     the *NET has deployed native multicast services forward IGMP/MLD
     messages into the *NET.  The IGMP/MLD messages may be further
     forwarded by a first-hop *NET access router acting as an IGMP/MLD-
     snooping switch [RFC4541], then ultimately delivered to a *NET (FHS)
     Proxy/Server.  The FHS Proxy/Server then acts as an ARS to send
     NS(AR) messages to an ARR for the multicast source.  Clients on *NET
     underlay interfaces without native multicast services instead send
     NS(AR) messages as an ARS to cause their FHS Proxy/Server to forward
     the message to an ARR.  When the ARR prepares an NA(AR) response, it
     initiates PIM protocol messaging according to the Source-Specific
     Multicast (SSM) and Any-Source Multicast (ASM) operational modes as
     discussed in the following sections.

  4.16.1.  Source-Specific Multicast (SSM)

     When an ARS "X" (i.e., either a Client or Proxy/Server) acting as PIM
     router receives a Join/Prune message from a node on its downstream
     interfaces containing one or more ((S)ource, (G)roup) pairs, it
     updates its Multicast Routing Information Base (MRIB) accordingly.
     For each S belonging to a prefix reachable via X's non-OMNI
     interfaces, X then forwards the (S, G) Join/Prune to any PIM routers
     on those interfaces per [RFC7761].  The same as for unicast
     destinations, the 3-tuple of Source Address, Destination Address and
     Flow Label identifies a flow for multicast group G.

     For each S belonging to a prefix reachable via X's OMNI interface, X
     sends an NS(AR) message (see: Section 4.13) into the secured spanning
     tree which delivers it to ARR "Y" that services S.  Y will then
     return an NA(AR) that includes an OMNI option with Interface
     Attributes, Traffic Selectors and RIOs for S.





  Templin                 Expires 2 September 2026               [Page 75]


  Internet-Draft                    AERO                        March 2026


     When X processes the NA(AR) it selects one or more underlay
     interfaces for S and performs an MP multilink forwarding message
     exchange over the secured spanning tree while including a PIM Join/
     Prune message OMNI sub-option for each multicast group of interest.
     If S is located behind any Proxys "Z"*, each Z* then updates its MRIB
     accordingly and maintains the MLA/FNP/MNP Source Address of X as the
     next hop in the reverse path.  Since Gateways forward messages not
     addressed to themselves without examining them, this means that the
     (reverse) multicast tree path is simply from each Z* (and/or S) to X
     with no other multicast-aware routers in the path.

     Following the initial combined Join/Prune and MP messaging, X
     maintains a NCE for each S the same as if X was sending unicast data
     traffic to S.  In particular, X performs additional MP message
     exchanges to keep the NCE alive for up to t_periodic seconds
     [RFC7761].  If no new Joins are received within t_periodic seconds, X
     allows the NCE to expire.  Finally, if X receives any additional
     Join/Prune messages for (S,G) it forwards the messages over the
     secured spanning tree.

     Client C that holds an MLA/MNP for source S may later depart from a
     first Proxy/Server Z1 and/or connect via a new Proxy/Server Z2.  In
     that case, Y sends an MP message to X the same as specified for
     unicast mobility in Section 4.15.  When X receives the MP message, it
     updates its NCE for the MLA for source S and sends new Join messages
     in MP message exchanges addressed to the new target Client underlay
     interface connection for S.  There is no requirement to send any
     Prune messages to old Proxy/Server Z1 since source S will no longer
     source any multicast data traffic via Z1.  Instead, the multicast
     state for (S,G) in Proxy/Server Z1 will soon expire since no new
     Joins will arrive.

  4.16.2.  Any-Source Multicast (ASM)

     When an ARS "X" acting as a PIM router receives Join/Prune messages
     from a node on its downstream interfaces containing one or more (*,G)
     pairs, it updates its Multicast Routing Information Base (MRIB)
     accordingly.  X first performs an NS/NA(AR) exchange to receive
     address resolution information for Rendezvous Point (RP) "R" for each
     G.  X then includes a copy of each Join/Prune message in the OMNI
     option of an MP message, then encapsulates the MP message in an OAL
     header and sends the message into the secured spanning tree.









  Templin                 Expires 2 September 2026               [Page 76]


  Internet-Draft                    AERO                        March 2026


     For each source "S" that sends multicast traffic to group G via R,
     Client S* that aggregates S (or its Proxy/Server) encapsulates the
     original IP packets in PIM Register messages, includes the PIM
     Register messages in the OMNI options of MP messages, performs OAL
     encapsulation and fragmentation with Identification values within the
     receive window for Client R* that aggregates R, then performs
     underlay encapsulation and forwards the resulting carrier packets.

     Client R* may then elect to send a PIM Join to S* in the OMNI option
     of a MP over the secured spanning tree.  This will result in an (S,G)
     tree rooted at S* with R as the next hop so that R will begin to
     receive two copies of the original IP packet; one native copy from
     the (S, G) tree and a second copy from the pre-existing (*, G) tree
     that still uses MP PIM Register encapsulation.  R can then issue an
     MP with a PIM Register-stop message over the secured spanning tree to
     suppress the Register-encapsulated stream.  At some later time, if
     Client S* moves to a new Proxy/Server, it resumes sending original IP
     packets via MP PIM Register encapsulation via the new Proxy/Server.

     At the same time, as multicast listeners discover individual S's for
     a given G, they can initiate an (S,G) Join for each S under the same
     procedures discussed in Section 4.16.1.  Once the (S,G) tree is
     established, the listeners can send (S, G) Prune messages to R so
     that multicast original IP packets for group G sourced by S will only
     be delivered via the (S, G) tree and not from the (*, G) tree rooted
     at R.  All mobility considerations discussed for SSM apply.

  4.16.3.  Bi-Directional PIM (BIDIR-PIM)

     Bi-Directional PIM (BIDIR-PIM) [RFC5015] provides an alternate
     approach to ASM that treats the Rendezvous Point (RP) as a Designated
     Forwarder (DF).  Further considerations for BIDIR-PIM are out of
     scope.

  4.17.  Operation over Multiple OMNI Links

     An AERO Client can connect to multiple OMNI links the same as for any
     data link service.  In that case, the Client maintains a distinct
     OMNI interface for each link, e.g., 'omni0' for the first link,
     'omni1' for the second, 'omni2' for the third, etc.  Each OMNI link
     would include its own distinct set of Gateways and Proxy/Servers,
     thereby providing redundancy in case of failures.









  Templin                 Expires 2 September 2026               [Page 77]


  Internet-Draft                    AERO                        March 2026


     Each OMNI link could utilize the same or different ANET/INET link
     layer connections.  The links can be distinguished at the link layer
     via the SRT prefix in a similar fashion as for Virtual Local Area
     Network (VLAN) tagging (e.g., IEEE 802.1Q) and/or through assignment
     of distinct sets of MSPs on each link.  This gives rise to the
     opportunity for supporting multiple redundant networked paths (see:
     Section 4.2.4).

     The Client's network layer can select the outbound OMNI interface
     appropriate for a given traffic profile while (in the reverse
     direction) correspondent nodes must have some way of steering their
     original IP packets destined to a target via the correct OMNI link.

     In a first alternative, if each OMNI link services different MSPs the
     Client can receive a distinct MNP from each of the links.  IP routing
     will therefore assure that the correct OMNI link is used for both
     outbound and inbound traffic.  This can be accomplished using
     existing technologies and approaches, and without requiring any
     special supporting code in correspondent nodes or Gateways.

     In a second alternative, if each OMNI link services the same MSP(s)
     then each link could assign a distinct "OMNI link Anycast" address
     that is configured by all Gateways on the link.  Correspondent nodes
     can then perform Segment Routing to select the correct SRT, which
     will then direct the original IP packet over multiple hops to the
     target.

  4.18.  Transition/Coexistence Considerations

     OAL encapsulation ensures that dissimilar INET partitions can be
     joined into a single unified OMNI link, even though the partitions
     themselves may have differing protocol versions and/or incompatible
     addressing plans.  However, a commonality can be achieved by
     incrementally distributing globally routable (i.e., native) IP
     prefixes to eventually reach all nodes (both mobile and fixed) in all
     OMNI link segments.  This can be accomplished by incrementally
     deploying AERO Gateways on each INET partition, with each Gateway
     distributing its MNPs and/or discovering FNPs on its INET links.

     This gives rise to the opportunity to eventually distribute native IP
     addresses to all nodes, and to present a unified OMNI link view even
     if the INET partitions remain in their current protocol and
     addressing plans.  In that way, the OMNI link can serve the dual
     purpose of providing a mobility/multilink service and a transition/
     coexistence service.  Alternatively, if an INET partition is
     transitioned to a native IP protocol version and addressing scheme
     compatible with the OMNI link MNP-based addressing scheme, the
     partition and OMNI link can be joined by Gateways.



  Templin                 Expires 2 September 2026               [Page 78]


  Internet-Draft                    AERO                        March 2026


     Relays that connect INETs/EUNs with dissimilar IP protocol versions
     may need to employ a network address and protocol translation
     function such as NAT64 [RFC6146].

  4.19.  Proxy/Server-Gateway Bidirectional Forwarding Detection

     In environments where rapid failure recovery is essential, Proxy/
     Servers and Gateways SHOULD use Bidirectional Forwarding Detection
     (BFD) [RFC5880].  Nodes that use BFD can quickly detect and react to
     failures so that cached information is re-established through
     alternate nodes.  BFD control messaging is carried only over well-
     connected ground domain networks (i.e., and not low-end radio links)
     and can therefore be tuned for rapid response.

     Proxy/Servers and Gateways can maintain BFD sessions in parallel with
     their BGP peerings.  If a Proxy/Server or Gateway fails, BGP peers
     will quickly re-establish routes through alternate paths the same as
     for common BGP operational practice.

  4.20.  Time-Varying MNPs

     In some use cases, it is desirable, beneficial and efficient for the
     Client to receive a constant MNP that travels with the Client
     wherever it moves.  For example, this would allow air traffic
     controllers to easily track aircraft, etc.  In other cases, however
     (e.g., intelligent transportation systems), the MN may be willing to
     sacrifice a modicum of efficiency in order to have time-varying MNPs
     that can be changed every so often to defeat adversarial tracking.

     The DHCPv6 service offers a way for Clients that desire time-varying
     MNPs to obtain short-lived prefixes (e.g., on the order of a small
     number of minutes).  In that case, the identity of the Client would
     not be bound to the MNP but rather to a Node Identification value
     (see: [I-D.templin-6man-omni3]) that can serve as a Client ID seed
     for MNP prefix delegation.  The Client would then be obligated to
     renumber its internal networks whenever its MNP changes.  This should
     not present problems for Clients with automated network renumbering
     services, however it can limit the durations of ongoing sessions that
     would prefer to use a constant address.

  5.  Implementation Status

     AERO/OMNI Release-3.2 was tagged on March 30, 2021, and was subject
     to internal testing.  The implementation is not planned for public
     release.






  Templin                 Expires 2 September 2026               [Page 79]


  Internet-Draft                    AERO                        March 2026


     A write-from-scratch reference implementation is under active
     internal development, with release version v0.pre8 tagged on January
     16, 2026.  Future versions will be made available for public release.

  6.  IANA Considerations

     The IANA is requested to assign a new Code TBD ("Compressed header
     expected") in the "ICMPv6 Parameter Problem" registry
     [https://www.iana.org/assignments/icmpv6-parameters/
     icmpv6-parameters.xhtml].  Registration Procedures include Standards
     Action or IESG Approval.

     The IANA assigned UDP port number "8060" for an experimental first
     edition of AERO [RFC6706].  The Overlay Multilink Network Interface
     (OMNI) specification [I-D.templin-6man-omni3] reclaims "8060" as the
     service port for AERO/OMNI UDP/IP encapsulation, therefore this
     document makes no IANA request.  (Note: although [RFC6706] was not
     widely implemented or deployed, it need not be obsoleted since it
     uses ICMPv6 message type '0' (Reserved) which implementations of this
     specification ignore.)

  7.  Security Considerations

     AERO Gateways establish security associations with AERO Proxy/Servers
     and Relays within their local OMNI link segments using secured
     tunnels over underlay interfaces.  The AERO Gateways of all OMNI link
     segments in turn configure secured tunnels with neighboring AERO
     Gateways for other OMNI link segments in a secured spanning tree
     topology.  Applicable security services include IPsec [RFC4301] with
     IKEv2 [RFC7296], etc.  (Note that secured direct point-to-point links
     can also be used instead of or in addition to network layer
     security.)  Together, these services are responsible for assuring
     connectionless integrity and data origin authentication with optional
     protection against replays for control messages that traverse the
     secured spanning tree.
















  Templin                 Expires 2 September 2026               [Page 80]


  Internet-Draft                    AERO                        March 2026


     To prevent unauthorized local applications from congesting the
     secured spanning tree, Proxy/Servers and Gateways configure local
     access controls to permit only the BGP protocol service daemon to
     source routing protocol control messages with the MLA assigned to the
     OMNI interface as the source over the secured spanning tree.  An
     implementation can employ a port/address filtering configuration that
     permits only TCP port 179 (as defined in the IANA "Service Names and
     Port Numbers" registry) when using the MLA assigned to the OMNI
     interface.  To prevent malicious Clients from congesting the secured
     spanning tree, Proxy/Servers should also rate-limit the secured IPv6
     ND messages they process for the same (source, target) pair, e.g., by
     applying IPv6 ND MAX_UNICAST_SOLICIT; MAX_NEIGHBOR_ADVERTISEMENT
     limits.

     To prevent spoofing, Proxy/Servers MUST silently discard without
     responding to any unsecured IPv6 ND messages with OMNI sub-options
     that would otherwise affect state.  Also, Proxy/Servers MUST silently
     discard without forwarding any original IP packets received from one
     of their own Clients (whether directly or following OAL reassembly)
     with a Source Address that does not match the Client's MNP and/or a
     Destination Address that does match the Client's MNP.  Finally,
     Proxy/Servers MUST silently discard without forwarding any carrier
     packets that include an OAL packet/fragment with Source and
     Destination Addresses that both match the same MNP.

     AERO Clients that connect to secured ANETs need not apply additional
     security to their IPv6 ND messages, since the messages will be
     accepted and forwarded by a perimeter Proxy/Server that applies
     security over its INET-facing interface to the secured spanning tree
     (see above).  AERO Clients that connect to MANETs or open INETs can
     use network and/or transport layer security services such as VPNs
     (e.g., IPsec tunnels) or can by some other means establish a secured
     direct link to a Proxy/Server.  When a VPN or direct link may be
     impractical, however, INET Clients and Proxy/Servers SHOULD include
     and verify authentication signatures for IPv6 ND messages as
     specified in [I-D.templin-6man-omni3].

     End systems SHOULD apply transport or higher layer security services
     such as QUIC-TLS [RFC9000], TLS/SSL [RFC8446], DTLS [RFC6347], etc.
     to provide a level of protection comparable to critical secured
     Internet services.  End systems that require host-based VPN services
     SHOULD use network and/or transport layer security services such as
     IPsec, TLS/SSL, DTLS, etc.  AERO Proxy/Servers and Clients can also
     provide a network-based VPN service on behalf of end systems, e.g.,
     if the end system is located within a secured enclave and cannot
     establish a VPN on its own behalf.





  Templin                 Expires 2 September 2026               [Page 81]


  Internet-Draft                    AERO                        March 2026


     AERO Proxy/Servers and Gateways present targets for traffic
     amplification Denial of Service (DoS) attacks.  This concern is no
     different than for widely-deployed VPN security gateways in the
     Internet, where attackers could send spoofed packets to the gateways
     at high data rates.  This can be mitigated through the AERO/OMNI data
     origin authentication procedures, as well as connecting Proxy/Servers
     and Gateways over dedicated links with no connections to the Internet
     and/or when connections to the Internet are only permitted through
     well-managed firewalls.  Traffic amplification DoS attacks can also
     target an AERO Client's low data rate links.  This is a concern not
     only for Clients located on the open Internet but also for Clients in
     secured enclaves.  AERO Proxy/Servers and Proxys can institute rate
     limits that protect Clients from receiving carrier packet floods that
     could DoS low data rate links.

     AERO Relays must implement ingress filtering to avoid a spoofing
     attack in which spurious messages with ULA addresses are injected
     into an OMNI link from an outside attacker.  AERO Clients MUST ensure
     that their connectivity is not used by unauthorized nodes on their
     EUNs to gain access to a protected network, i.e., AERO Clients that
     act as routers MUST NOT provide routing services for unauthorized
     nodes.  (This concern is no different than for ordinary hosts that
     receive an IP address delegation but then "share" the address with
     other nodes via some form of Internet connection sharing such as
     tethering.)

     The AERO service for MANET and open INET Clients depends on a public
     key distribution service in which Client public keys and identities
     are maintained in a shared database accessible to Proxy/Servers and
     potential correspondent peer nodes.  Similarly, each Client must be
     able to determine the public key of each Proxy/Server, e.g. by
     consulting an online database.

     The PRL contains only public information, but MUST be well-managed
     and secured from unauthorized tampering.  The PRL can be conveyed to
     the Client in a similar fashion as in [RFC5214] (e.g., through data
     link layer login messaging, secure upload of a static file, DNS
     lookups, etc.).

     Security considerations for IPv6 fragmentation and reassembly are
     discussed in [I-D.templin-6man-omni3].  In environments where
     spoofing is considered a threat, all OAL nodes SHOULD employ
     Identification window synchronization and OAL end systems SHOULD
     configure an (end-system-based) firewall.

     Security considerations for accepting link layer ICMP messages and
     reflected carrier packets are discussed throughout the document.




  Templin                 Expires 2 September 2026               [Page 82]


  Internet-Draft                    AERO                        March 2026


  8.  Acknowledgements

     Discussions in the IETF, aviation standards communities and private
     exchanges helped shape some of the concepts in this work.
     Individuals who contributed insights include Mikael Abrahamsson,
     Felipe Magno de Almeida, Mark Andrews, Fred Baker, Amanda Baber, Bob
     Braden, Stewart Bryant, Scott Burleigh, Brian Carpenter, Wojciech
     Dec, Pavel Drasil, Ralph Droms, Adrian Farrel, Nick Green, Sri
     Gundavelli, Brian Haberman, Bernhard Haindl, Joel Halpern, Tom
     Herbert, Bob Hinden, Sascha Hlusiak, Lee Howard, Christian Huitema,
     Zdenek Jaron, Andre Kostur, Hubert Kuenig, Eliot Lear, Ted Lemon,
     Andy Malis, Satoru Matsushima, Tomek Mrugalski, Thomas Narten, Madhu
     Niraula, Alexandru Petrescu, Behcet Saikaya, Michal Skorepa, Dave
     Thaler, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman, Lloyd
     Wood and James Woodyatt.  Members of the IESG also provided valuable
     input during their review process that greatly improved the document.
     Special thanks go to Stewart Bryant, Joel Halpern and Brian Haberman
     for their shepherding guidance during the publication of the AERO
     first edition.

     This work has further been encouraged and supported by Boeing
     colleagues including Akash Agarwal, Kyle Bae, M.  Wayne Benson, Dave
     Bernhardt, Cam Brodie, John Bush, Balaguruna Chidambaram, Irene Chin,
     Bruce Cornish, Claudiu Danilov, Sean Dickson, Don Dillenburg, Joe
     Dudkowski, Wen Fang, Samad Farooqui, Anthony Gregory, Jeff Holland,
     Seth Jahne, Brian Jaury, Greg Kimberly, Ed King, Madhuri Madhava
     Badgandi, Laurel Matthew, Gene MacLean III, Kyle Mikos, Rob
     Muszkiewicz, Sean O'Sullivan, Satish Raghavendran, Vijay Rajagopalan,
     Kristina Ross, Greg Saccone, Ron Sackman, Bhargava Raman Sai Prakash,
     Rod Santiago, Madhanmohan Savadamuthu, Kent Shuey, Brian Skeen, Mike
     Slane, Carrie Spiker, Katie Tran, Brendan Williams, Amelia Wilson,
     Julie Wulff, Yueli Yang, Eric Yeh and other members of the Boeing
     mobility, networking and autonomy teams.  Akash Agarwal, Kyle Bae,
     Wayne Benson, Madhuri Madhava Badgandi, Vijayasarathy Rajagopalan,
     Bhargava Raman Sai Prakash, Katie Tran and Eric Yeh are especially
     acknowledged for their work on the AERO implementation.  Chuck
     Klabunde is honored for his support and guidance, and we mourn his
     untimely loss.

     This work was inspired by the support and encouragement of countless
     outstanding colleagues, managers and program directors over the span
     of many decades.  Beginning in the late 1980s,' the Digital Equipment
     Corporation (DEC) Ultrix Engineering and DECnet Architects groups
     identified early issues with fragmentation and bridging links with
     diverse MTUs.  In the early 1990s, engagements at DEC Project Sequoia
     at UC Berkeley and the DEC Western Research Lab in Palo Alto included
     investigations into large-scale networked filesystems, ATM vs
     Internet and network security proxys.  In the mid-1990s to early



  Templin                 Expires 2 September 2026               [Page 83]


  Internet-Draft                    AERO                        March 2026


     2000s employment at the NASA Ames Research Center (Sterling Software)
     and SRI International supported early investigations of IPv6, ONR UAV
     Communications and the IETF.  An employment at Nokia where important
     IETF documents were published gave way to a present-day engagement
     with The Boeing Company.  The work matured at Boeing through major
     programs including Future Combat Systems, Advanced Airplane Program,
     DTN for the International Space Station, Mobility Vision Lab, CAST,
     Caravan, Airplane Internet of Things, the NASA UAS/CNS program, the
     FAA/ICAO ATN/IPS program and many others.  An attempt to name all who
     gave support and encouragement would double the current document size
     and result in many unintentional omissions - but to all a humble
     thanks.

     Earlier works on NBMA tunneling approaches are found in
     [RFC2529][RFC5214][RFC5569].

     Many of the constructs presented in this second edition of AERO are
     based on the author's earlier works, including:

     *  Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]

     *  The Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320]

     *  Virtual Enterprise Traversal (VET) [RFC5558]

     *  Routing and Addressing in Networks with Global Enterprise
        Recursion (RANGER) [RFC5720][RFC6139]

     *  The Internet Routing Overlay Network (IRON) [RFC6179]

     *  AERO, First Edition [RFC6706]

     Note that these works cite numerous earlier efforts that are not
     included here due to space limitations.  The authors of those earlier
     works are acknowledged for their insights.

     This work is aligned with the NASA Safe Autonomous Systems Operation
     (SASO) program under NASA contract number NNA16BD84C.

     This work is aligned with the FAA as per the SE2025 contract number
     DTFAWA-15-D-00030.

     This work is aligned with the Boeing Commercial Airplanes (BCA)
     Airplane Internet of Things (AIoT) and autonomy programs.

     This work is aligned with the Boeing Information Technology (BIT)
     MobileNet program.




  Templin                 Expires 2 September 2026               [Page 84]


  Internet-Draft                    AERO                        March 2026


     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.

  9.  References

  9.1.  Normative References

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

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

     [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
                RFC 792, DOI 10.17487/RFC0792, September 1981,
                <https://www.rfc-editor.org/info/rfc792>.

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

     [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
                More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
                November 2005, <https://www.rfc-editor.org/info/rfc4191>.

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

     [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
                Border Gateway Protocol 4 (BGP-4)", RFC 4271,
                DOI 10.17487/RFC4271, January 2006,
                <https://www.rfc-editor.org/info/rfc4271>.

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






  Templin                 Expires 2 September 2026               [Page 85]


  Internet-Draft                    AERO                        March 2026


     [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
                Control Message Protocol (ICMPv6) for the Internet
                Protocol Version 6 (IPv6) Specification", STD 89,
                RFC 4443, DOI 10.17487/RFC4443, March 2006,
                <https://www.rfc-editor.org/info/rfc4443>.

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

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

     [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
                "IPv6 Flow Label Specification", RFC 6437,
                DOI 10.17487/RFC6437, November 2011,
                <https://www.rfc-editor.org/info/rfc6437>.

     [RFC6438]  Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
                for Equal Cost Multipath Routing and Link Aggregation in
                Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
                <https://www.rfc-editor.org/info/rfc6438>.

     [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
                "Special-Purpose IP Address Registries", BCP 153,
                RFC 6890, DOI 10.17487/RFC6890, April 2013,
                <https://www.rfc-editor.org/info/rfc6890>.

     [RFC8028]  Baker, F. and B. Carpenter, "First-Hop Router Selection by
                Hosts in a Multi-Prefix Network", RFC 8028,
                DOI 10.17487/RFC8028, November 2016,
                <https://www.rfc-editor.org/info/rfc8028>.

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

     [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 2 September 2026               [Page 86]


  Internet-Draft                    AERO                        March 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>.

  9.2.  Informative References

     [BGP]      Huston, G., "BGP in 2015, http://potaroo.net", January
                2016.

     [CERF1]    Cerf, V. and R. Kahn, "A Protocol for Packet Network
                Intercommunication,
                https://ieeexplore.ieee.org/document/1092259", May 1974.

     [CERF2]    Cerf, V., "The Catenet Model For Internetworking, IETF
                IEN48, https://www.rfc-editor.org/ien/scanned/ien48.pdf",
                July 1978.

     [EUI]      "IEEE Guidelines for Use of Extended Unique Identifier
                (EUI), Organizationally Unique Identifier (OUI), and
                Company ID, https://standards.ieee.org/wp-
                content/uploads/import/documents/tutorials/eui.pdf", 3
                August 2017.

     [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.ietf-intarea-tunnels]
                Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
                Architecture", Work in Progress, Internet-Draft, draft-
                ietf-intarea-tunnels-15, 9 May 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
                tunnels-15>.

     [I-D.ietf-rtgwg-atn-bgp]
                Templin, F., Saccone, G., Dawra, G., Lindem, A., and V.
                Moreno, "A Simple BGP-based Mobile Routing System for the
                Aeronautical Telecommunications Network", Work in
                Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-30, 6
                February 2026, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rtgwg-atn-bgp-30>.




  Templin                 Expires 2 September 2026               [Page 87]


  Internet-Draft                    AERO                        March 2026


     [I-D.perkins-manet-aodvv2]
                Perkins, C. E., Dowdell, J., Steenbrink, L., and V.
                Pritchard, "Ad Hoc On-demand Distance Vector Version 2
                (AODVv2) Routing", Work in Progress, Internet-Draft,
                draft-perkins-manet-aodvv2-06, 20 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-perkins-
                manet-aodvv2-06>.

     [I-D.templin-6man-mla]
                Templin, F., "IPv6 Addresses for Ad Hoc Networks", Work in
                Progress, Internet-Draft, draft-templin-6man-mla-30, 11
                November 2025, <https://datatracker.ietf.org/doc/html/
                draft-templin-6man-mla-30>.

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

     [KAHN]     Perry, T., "The Great Interconnector, IEEE Spectrum,
                https://spectrum.ieee.org/bob-kahn-2667754905", May 2024.

     [POUZIN]   Pouzin, L., "Interconnection of Packet Switching Networks,
                http://xn--brwolff-5wa.de/public/Pouzin-1973-
                Interconnection-of-Packet-Switching-Networks--INWG-Note-
                42.pdf", October 1973.

     [RFC1256]  Deering, S., Ed., "ICMP Router Discovery Messages",
                RFC 1256, DOI 10.17487/RFC1256, September 1991,
                <https://www.rfc-editor.org/info/rfc1256>.

     [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
                RFC 1812, DOI 10.17487/RFC1812, June 1995,
                <https://www.rfc-editor.org/info/rfc1812>.

     [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
                J., and E. Lear, "Address Allocation for Private
                Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
                February 1996, <https://www.rfc-editor.org/info/rfc1918>.

     [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
                2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
                <https://www.rfc-editor.org/info/rfc2236>.






  Templin                 Expires 2 September 2026               [Page 88]


  Internet-Draft                    AERO                        March 2026


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

     [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
                Domains without Explicit Tunnels", RFC 2529,
                DOI 10.17487/RFC2529, March 1999,
                <https://www.rfc-editor.org/info/rfc2529>.

     [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
                via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
                2001, <https://www.rfc-editor.org/info/rfc3056>.

     [RFC3724]  Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
                the Middle and the Future of End-to-End: Reflections on
                the Evolution of the Internet Architecture", RFC 3724,
                DOI 10.17487/RFC3724, March 2004,
                <https://www.rfc-editor.org/info/rfc3724>.

     [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
                Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
                DOI 10.17487/RFC3810, June 2004,
                <https://www.rfc-editor.org/info/rfc3810>.

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

     [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
                December 2005, <https://www.rfc-editor.org/info/rfc4301>.

     [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
                Network Address Translations (NATs)", RFC 4380,
                DOI 10.17487/RFC4380, February 2006,
                <https://www.rfc-editor.org/info/rfc4380>.

     [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
                Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
                2006, <https://www.rfc-editor.org/info/rfc4389>.

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






  Templin                 Expires 2 September 2026               [Page 89]


  Internet-Draft                    AERO                        March 2026


     [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
                Protocol (LDAP): The Protocol", RFC 4511,
                DOI 10.17487/RFC4511, June 2006,
                <https://www.rfc-editor.org/info/rfc4511>.

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

     [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
                "Internet Group Management Protocol (IGMP) / Multicast
                Listener Discovery (MLD)-Based Multicast Forwarding
                ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
                August 2006, <https://www.rfc-editor.org/info/rfc4605>.

     [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
                "Bidirectional Protocol Independent Multicast (BIDIR-
                PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
                <https://www.rfc-editor.org/info/rfc5015>.

     [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
                Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
                DOI 10.17487/RFC5214, March 2008,
                <https://www.rfc-editor.org/info/rfc5214>.

     [RFC5320]  Templin, F., Ed., "The Subnetwork Encapsulation and
                Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320,
                February 2010, <https://www.rfc-editor.org/info/rfc5320>.

     [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
                for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
                <https://www.rfc-editor.org/info/rfc5340>.

     [RFC5522]  Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
                Route Optimization Requirements for Operational Use in
                Aeronautics and Space Exploration Mobile Networks",
                RFC 5522, DOI 10.17487/RFC5522, October 2009,
                <https://www.rfc-editor.org/info/rfc5522>.

     [RFC5558]  Templin, F., Ed., "Virtual Enterprise Traversal (VET)",
                RFC 5558, DOI 10.17487/RFC5558, February 2010,
                <https://www.rfc-editor.org/info/rfc5558>.

     [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4
                Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
                January 2010, <https://www.rfc-editor.org/info/rfc5569>.



  Templin                 Expires 2 September 2026               [Page 90]


  Internet-Draft                    AERO                        March 2026


     [RFC5614]  Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
                Extension of OSPF Using Connected Dominating Set (CDS)
                Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009,
                <https://www.rfc-editor.org/info/rfc5614>.

     [RFC5720]  Templin, F., "Routing and Addressing in Networks with
                Global Enterprise Recursion (RANGER)", RFC 5720,
                DOI 10.17487/RFC5720, February 2010,
                <https://www.rfc-editor.org/info/rfc5720>.

     [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
                (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
                <https://www.rfc-editor.org/info/rfc5880>.

     [RFC6081]  Thaler, D., "Teredo Extensions", RFC 6081,
                DOI 10.17487/RFC6081, January 2011,
                <https://www.rfc-editor.org/info/rfc6081>.

     [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
                "IPv6 Router Advertisement Options for DNS Configuration",
                RFC 6106, DOI 10.17487/RFC6106, November 2010,
                <https://www.rfc-editor.org/info/rfc6106>.

     [RFC6139]  Russert, S., Ed., Fleischman, E., Ed., and F. Templin,
                Ed., "Routing and Addressing in Networks with Global
                Enterprise Recursion (RANGER) Scenarios", RFC 6139,
                DOI 10.17487/RFC6139, February 2011,
                <https://www.rfc-editor.org/info/rfc6139>.

     [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
                Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
                <https://www.rfc-editor.org/info/rfc6145>.

     [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
                NAT64: Network Address and Protocol Translation from IPv6
                Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
                April 2011, <https://www.rfc-editor.org/info/rfc6146>.

     [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
                Beijnum, "DNS64: DNS Extensions for Network Address
                Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
                DOI 10.17487/RFC6147, April 2011,
                <https://www.rfc-editor.org/info/rfc6147>.

     [RFC6179]  Templin, F., Ed., "The Internet Routing Overlay Network
                (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011,
                <https://www.rfc-editor.org/info/rfc6179>.




  Templin                 Expires 2 September 2026               [Page 91]


  Internet-Draft                    AERO                        March 2026


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

     [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
                Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
                January 2012, <https://www.rfc-editor.org/info/rfc6347>.

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

     [RFC6706]  Templin, F., Ed., "Asymmetric Extended Route Optimization
                (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012,
                <https://www.rfc-editor.org/info/rfc6706>.

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

     [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
                "The Optimized Link State Routing Protocol Version 2",
                RFC 7181, DOI 10.17487/RFC7181, April 2014,
                <https://www.rfc-editor.org/info/rfc7181>.

     [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
                Kivinen, "Internet Key Exchange Protocol Version 2
                (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
                2014, <https://www.rfc-editor.org/info/rfc7296>.

     [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
                Korhonen, "Requirements for Distributed Mobility
                Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
                <https://www.rfc-editor.org/info/rfc7333>.

     [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
                Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
                Multicast - Sparse Mode (PIM-SM): Protocol Specification
                (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
                2016, <https://www.rfc-editor.org/info/rfc7761>.

     [RFC8175]  Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
                Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
                DOI 10.17487/RFC8175, June 2017,
                <https://www.rfc-editor.org/info/rfc8175>.





  Templin                 Expires 2 September 2026               [Page 92]


  Internet-Draft                    AERO                        March 2026


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

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

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

     [RFC8966]  Chroboczek, J. and D. Schinazi, "The Babel Routing
                Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
                <https://www.rfc-editor.org/info/rfc8966>.

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

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

     [RFC9762]  Colitti, L., Linkova, J., Ma, X., Ed., and D. Lamparter,
                "Using Router Advertisements to Signal the Availability of
                DHCPv6 Prefix Delegation to Clients", RFC 9762,
                DOI 10.17487/RFC9762, June 2025,
                <https://www.rfc-editor.org/info/rfc9762>.

  Appendix A.  Non-Normative Considerations

     AERO can be applied to a multitude of Internetworking scenarios, with
     each having its own adaptations.  The following considerations are
     provided as non-normative guidance:

  A.1.  Implementation Strategies for Route Optimization

     Address resolution and route optimization as discussed in
     Section 4.13 results in the creation of NCEs.  The NCE state is set
     to REACHABLE for at most ReachableTime seconds.  In order to refresh
     the NCE lifetime before the ReachableTime timer expires, the
     specification requires implementations to issue a new NS/NA(AR)
     exchange to reset ReachableTime while data messages are still



  Templin                 Expires 2 September 2026               [Page 93]


  Internet-Draft                    AERO                        March 2026


     flowing.  However, the decision of when to initiate a new NS/NA(AR)
     exchange and to perpetuate the process is left as an implementation
     detail.

     One possible strategy may be to monitor the NCE watching for data
     messages for (ReachableTime - 5) seconds.  If any data messages have
     been sent to the neighbor within this timeframe, then send an NS(AR)
     to receive a new NA(AR).  If no data messages have been sent, wait
     for 5 additional seconds and send an immediate NS(AR) if any data
     packets are sent within this "expiration pending" 5 second window.
     If no additional data messages are sent within the 5 second window,
     reset the NCE state to STALE.

     The monitoring of the neighbor data traffic therefore becomes an
     ongoing process during the NCE lifetime.  If the NCE expires, future
     data messages will trigger a new NS/NA(AR) exchange while the
     messages themselves may be delivered over longer paths until route
     optimization state is re-established.

  A.2.  Implicit Mobility Management

     OMNI interface neighbors MAY provide a configuration option that
     allows them to perform implicit mobility management in which no IPv6
     ND messaging is used.  In that case, the Client only transmits
     carrier packets over a single interface at a time, and the neighbor
     always observes carrier packets arriving from the Client from the
     same underlay Source Address.

     If the Client's underlay interface address changes (either due to a
     readdressing of the original interface or switching to a new
     interface) the neighbor immediately updates the NCE for the Client
     and begins accepting and sending carrier packets according to the
     Client's new address.  This implicit mobility method applies to use
     cases such as cellphones with both WiFi and Cellular interfaces where
     only one of the interfaces is active at a given time, and the Client
     automatically switches over to the backup interface if the primary
     interface fails.

  A.3.  Direct Underlying Interfaces

     When a Client's OMNI interface is configured over a Direct interface,
     the neighbor at the other end of the Direct link can receive original
     IP packets without any encapsulation.  In that case, the Client sends
     packets over the Direct link according to traffic selectors.  If the
     Direct interface is selected, then the Client's packets are
     transmitted directly to the peer without traversing an ANET/INET.  If
     other interfaces are selected, then the Client's packets are
     transmitted via a different interface, which may result in the



  Templin                 Expires 2 September 2026               [Page 94]


  Internet-Draft                    AERO                        March 2026


     inclusion of Proxy/Servers and Gateways in the communications path.
     Direct interfaces must be tested periodically for reachability, e.g.,
     via NUD.

  A.4.  AERO Critical Infrastructure Considerations

     AERO Gateways can be either Commercial off-the Shelf (COTS) standard
     IP routers or virtual machines in the cloud.  Gateways must be
     provisioned, supported and managed by the INET administrative
     authority, and connected to the Gateways of other INETs via inter-
     domain peerings.  Cost for purchasing, configuring and managing
     Gateways is nominal even for very large OMNI links.

     AERO INET Proxy/Servers can be standard dedicated server platforms,
     but most often will be deployed as virtual machines in the cloud.
     The only requirements for INET Proxy/Servers are that they can run
     the AERO/OMNI code and have at least one network interface connection
     to the INET.  INET Proxy/Servers must be provisioned, supported and
     managed by the INET administrative authority.  Cost for purchasing,
     configuring and managing cloud Proxy/Servers is nominal especially
     for virtual machines.

     AERO ANET Proxy/Servers are most often standard dedicated server
     platforms with one underlay interface connected to the ANET and a
     second interface connected to an INET.  As with INET Proxy/Servers,
     the only requirements are that they can run the AERO/OMNI code and
     have at least one interface connection to the INET.  ANET Proxy/
     Servers must be provisioned, supported and managed by the ANET
     administrative authority.  Cost for purchasing, configuring and
     managing Proxys is nominal, and borne by the ANET administrative
     authority.

     AERO Relays are simply Proxy/Servers connected to INETs and/or EUNs
     that provide forwarding services for non-MNP destinations.  The Relay
     connects to the OMNI link and engages in eBGP peering with one or
     more Gateways as a stub AS.  The Relay then injects its MNPs and/or
     non-MNP prefixes into the BGP routing system, and provisions the
     prefixes to its downstream-attached networks.  The Relay can perform
     ARS/ARR services the same as for any Proxy/Server, and can route
     between the MNP and non-MNP address spaces.











  Templin                 Expires 2 September 2026               [Page 95]


  Internet-Draft                    AERO                        March 2026


  A.5.  AERO Server Failure Implications

     AERO Proxy/Servers do not present a single point of failure in the
     architecture since all Proxy/Servers on the link provide identical
     services and loss of a Proxy/Server does not imply immediate and/or
     comprehensive communication failures.  Proxy/Server failure can be
     quickly detected and conveyed by Bidirectional Forward Detection
     (BFD) and/or proactive NUD allowing Clients to migrate to new Proxy/
     Servers.

     If a Proxy/Server fails, peer carrier packet forwarding to Clients
     will continue by virtue of the NCEs that have already been
     established through address resolution and route optimization.  If a
     Client also experiences mobility events at roughly the same time the
     Proxy/Server fails, uNA messages may be lost but NCEs in the DEPARTED
     state will ensure that carrier packet forwarding to the Client's new
     locations will continue for up to DepartTime seconds.

     If a Client is left without a Proxy/Server for a considerable length
     of time (e.g., greater than ReachableTime seconds) then existing NCEs
     will eventually expire and both ongoing and new communications will
     fail.  The original source will continue to retransmit until the
     Client has established a new Proxy/Server relationship, after which
     time communications can continue .

     Therefore, links that provide many Proxy/Servers with high
     availability profiles are responsive to loss of individual
     infrastructure elements, since Clients can quickly establish new
     Proxy/Server relationships in event of failures.

  A.6.  AERO Client / Server Architecture

     The AERO architectural model is client / server in the control plane,
     with route optimization in the data plane.  The same as for common
     Internet services, the AERO Client discovers the addresses of AERO
     Proxy/Servers and connects to one or more of them.  The AERO service
     is analogous to common Internet services such as google.com,
     yahoo.com, cnn.com, etc.  However, there is only one AERO service for
     the link and all Proxy/Servers provide identical services.

     Common Internet services provide differing strategies for advertising
     server addresses to clients.  The strategy is conveyed through the
     DNS resource records returned in response to name resolution queries.
     As of January 2020 Internet-based 'nslookup' services were used to
     determine the following:






  Templin                 Expires 2 September 2026               [Page 96]


  Internet-Draft                    AERO                        March 2026


     *  When a client resolves the domainname "google.com", the DNS always
        returns one A record (i.e., an IPv4 address) and one AAAA record
        (i.e., an IPv6 address).  The client receives the same addresses
        each time it resolves the domainname via the same DNS resolver,
        but may receive different addresses when it resolves the
        domainname via different DNS resolvers.  But, in each case,
        exactly one A and one AAAA record are returned.

     *  When a client resolves the domainname "ietf.org", the DNS always
        returns one A record and one AAAA record with the same addresses
        regardless of which DNS resolver is used.

     *  When a client resolves the domainname "yahoo.com", the DNS always
        returns a list of 4 A records and 4 AAAA records.  Each time the
        client resolves the domainname via the same DNS resolver, the same
        list of addresses are returned but in randomized order (i.e.,
        consistent with a DNS round-robin strategy).  But, interestingly,
        the same addresses are returned (albeit in randomized order) when
        the domainname is resolved via different DNS resolvers.

     *  When a client resolves the domainname "amazon.com", the DNS always
        returns a list of 3 A records and no AAAA records.  As with
        "yahoo.com", the same three A records are returned from any
        worldwide Internet connection point in randomized order.

     The above example strategies show differing approaches to Internet
     resilience and service distribution offered by major Internet
     services.  The Google approach exposes only a single IPv4 and a
     single IPv6 address to clients.  Clients can then select whichever IP
     protocol version offers the best response, but will always use the
     same IP address according to the current Internet connection point.
     This means that the IP address offered by the network must lead to a
     highly-available server and/or service distribution point.  In other
     words, resilience is predicated on high availability within the
     network and with no client-initiated failovers expected (i.e., it is
     all-or-nothing from the client's perspective).  However, Google does
     provide for worldwide distributed service distribution by virtue of
     the fact that each Internet connection point responds with a
     different IPv6 and IPv4 address.  The IETF approach is like google
     (all-or-nothing from the client's perspective), but provides only a
     single IPv4 or IPv6 address on a worldwide basis.  This means that
     the addresses must be made highly-available at the network level with
     no client failover possibility, and if there is any worldwide service
     distribution it would need to be conducted by a network element that
     is reached via the IP address acting as a service distribution point.






  Templin                 Expires 2 September 2026               [Page 97]


  Internet-Draft                    AERO                        March 2026


     In contrast to the Google and IETF philosophies, Yahoo and Amazon
     both provide clients with a (short) list of IP addresses with Yahoo
     providing both IP protocol versions and Amazon as IPv4-only.  The
     order of the list is randomized with each name service query
     response, with the effect of round-robin load balancing for service
     distribution.  With a short list of addresses, there is still
     expectation that the network will implement high availability for
     each address but in case any single address fails the client can
     switch over to using a different address.  The balance then becomes
     one of function in the network vs function in the end system.

     The same implications observed for common highly-available services
     in the Internet apply also to the AERO client/server architecture.
     When an AERO Client connects to one or more ANETs, it discovers one
     or more AERO Proxy/Server addresses through the mechanisms discussed
     in earlier sections.  Each Proxy/Server address presumably leads to a
     fault-tolerant clustering arrangement such as supported by Linux-HA,
     Extended Virtual Synchrony or Paxos.  Such an arrangement has
     precedence in common Internet service deployments in lightweight
     virtual machines without requiring expensive hardware deployment.
     Similarly, common Internet service deployments set service IP
     addresses on service distribution points that may relay requests to
     many different servers.

     For AERO, the expectation is that a combination of the Google/IETF
     and Yahoo/Amazon philosophies would be employed.  The AERO Client
     connects to different ANET access points and can receive 1-2 Proxy/
     Server ULAs at each point.  It then selects one AERO Proxy/Server
     address, and engages in RS/RA exchanges with the same Proxy/Server
     from all ANET connections.  The Client remains with this Proxy/Server
     unless or until the Proxy/Server fails, in which case it can switch
     over to an alternate Proxy/Server.  The Client can likewise switch
     over to a different Proxy/Server at any time if there is some reason
     for it to do so.  So, the AERO expectation is for a balance of
     function in the network and end system, with fault tolerance and
     resilience at both levels.

  Appendix B.  Change Log

     << RFC Editor - remove prior to publication >>

     Differences from earlier versions:

     Draft -55 to -60
        *  Final version; future updates to appear in amendments draft.

        *  Clarified OMNI interface relation to MANET interfaces and MANET
           routing.



  Templin                 Expires 2 September 2026               [Page 98]


  Internet-Draft                    AERO                        March 2026


        *  Routability for MLAs within the OMNI link limited domain.

        *  ICMPv6 error messages now appear as standalone control messages
           and not appended to an IPv6 ND message.

        *  Clarification on SRH addressing; ICMPv6 message code
           description change.

     Draft -54 to -55
        *  Simplified Multilink Forwarding messages now based only on MP
           control messages which are ordinary IP packets with OMNI option
           trailers.

     Draft -53 to -54
        *  Removed defunct specification on Segment Routing.

     Draft -52 to -53
        *  Support marking non IPv6 ND messages as control.

        *  OMNI interface LLA clarifications.

     Draft -50 to -52
        *  Fully embraced segment routing and Segment Routing Topology.

        *  Fully embraced MLA addressing and removed PNP addressing.

        *  Updated historical background.

        *  Clarified IPv6 ND message Source, Destination and Target
           addressing.

        *  Clarified that AFVI is now an SRH TLV option.

  Author's Address

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










  Templin                 Expires 2 September 2026               [Page 99]


