draft-templin-intarea-aero2-04.txt   draft-templin-intarea-aero2-05.txt 
Network Working Group F. L. Templin, Ed. Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology Internet-Draft Boeing Research & Technology
Intended status: Standards Track 26 March 2024 Intended status: Standards Track 27 March 2024
Expires: 27 September 2024 Expires: 28 September 2024
Automatic Extended Route Optimization (AERO) Automatic Extended Route Optimization (AERO)
draft-templin-intarea-aero2-04 draft-templin-intarea-aero2-05
Abstract Abstract
This document specifies an Automatic Extended Route Optimization This document specifies an Automatic Extended Route Optimization
(AERO) service for IP internetworking over Overlay Multilink Network (AERO) service for IP internetworking over Overlay Multilink Network
(OMNI) interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND) (OMNI) interfaces. AERO/OMNI uses IPv6 Neighbor Discovery (IPv6 ND)
for control plane messaging over the OMNI virtual link. Router for control plane messaging over the OMNI virtual link. Router
discovery and neighbor coordination are employed for network discovery and neighbor coordination are employed for network
admission and to manage the OMNI link forwarding and routing systems. admission and to manage the OMNI link forwarding and routing systems.
Secure multilink path selection, multinet traversal, mobility Secure multilink path selection, multinet traversal, mobility
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 September 2024. This Internet-Draft will expire on 28 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.2.4. Segment Routing Topologies (SRTs) . . . . . . . . . . 27 4.2.4. Segment Routing Topologies (SRTs) . . . . . . . . . . 27
4.2.5. Segment Routing For OMNI Link Selection . . . . . . . 28 4.2.5. Segment Routing For OMNI Link Selection . . . . . . . 28
4.3. OMNI Interface Characteristics . . . . . . . . . . . . . 28 4.3. OMNI Interface Characteristics . . . . . . . . . . . . . 28
4.4. OMNI Interface Initialization . . . . . . . . . . . . . . 31 4.4. OMNI Interface Initialization . . . . . . . . . . . . . . 31
4.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 31 4.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 31
4.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 31 4.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 31
4.4.3. AERO Host Behavior . . . . . . . . . . . . . . . . . 32 4.4.3. AERO Host Behavior . . . . . . . . . . . . . . . . . 32
4.4.4. AERO Gateway Behavior . . . . . . . . . . . . . . . . 32 4.4.4. AERO Gateway Behavior . . . . . . . . . . . . . . . . 32
4.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 33 4.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 33
4.5.1. OMNI ND Messages . . . . . . . . . . . . . . . . . . 36 4.5.1. OMNI ND Messages . . . . . . . . . . . . . . . . . . 36
4.5.2. OMNI Neighbor Advertisement Message Flags . . . . . . 38 4.5.2. OMNI Neighbor Advertisement Message Flags . . . . . . 39
4.5.3. OMNI Neighbor Window Synchronization . . . . . . . . 39 4.5.3. OMNI Neighbor Window Synchronization . . . . . . . . 39
4.6. OMNI Interface Encapsulation and Fragmentation . . . . . 39 4.6. OMNI Interface Encapsulation and Fragmentation . . . . . 40
4.7. OMNI Interface Decapsulation . . . . . . . . . . . . . . 42 4.7. OMNI Interface Decapsulation . . . . . . . . . . . . . . 43
4.8. OMNI Interface Data Origin Authentication . . . . . . . . 43 4.8. OMNI Interface Data Origin Authentication . . . . . . . . 43
4.9. OMNI Interface MTU . . . . . . . . . . . . . . . . . . . 43 4.9. OMNI Interface MTU . . . . . . . . . . . . . . . . . . . 44
4.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . . 44 4.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . . 44
4.10.1. Host Forwarding Algorithm . . . . . . . . . . . . . 46 4.10.1. Host Forwarding Algorithm . . . . . . . . . . . . . 46
4.10.2. Client Forwarding Algorithm . . . . . . . . . . . . 46 4.10.2. Client Forwarding Algorithm . . . . . . . . . . . . 46
4.10.3. Proxy/Server and Relay Forwarding Algorithm . . . . 48 4.10.3. Proxy/Server and Relay Forwarding Algorithm . . . . 48
4.10.4. Gateway Forwarding Algorithm . . . . . . . . . . . . 51 4.10.4. Gateway Forwarding Algorithm . . . . . . . . . . . . 51
4.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 52 4.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 52
4.12. AERO Mobility Service Coordination . . . . . . . . . . . 55 4.12. AERO Mobility Service Coordination . . . . . . . . . . . 56
4.12.1. AERO Service Model . . . . . . . . . . . . . . . . . 55 4.12.1. AERO Service Model . . . . . . . . . . . . . . . . . 56
4.12.2. AERO Host and Client Behavior . . . . . . . . . . . 56 4.12.2. AERO Host and Client Behavior . . . . . . . . . . . 57
4.12.3. AERO Proxy/Server Behavior . . . . . . . . . . . . . 57 4.12.3. AERO Proxy/Server Behavior . . . . . . . . . . . . . 58
4.13. AERO Address Resolution, Multilink Forwarding and Route 4.13. AERO Address Resolution, Multilink Forwarding and Route
Optimization . . . . . . . . . . . . . . . . . . . . . . 63 Optimization . . . . . . . . . . . . . . . . . . . . . . 64
4.13.1. Multilink Address Resolution . . . . . . . . . . . . 65 4.13.1. Multilink Address Resolution . . . . . . . . . . . . 66
4.13.2. Multilink Forwarding . . . . . . . . . . . . . . . . 70 4.13.2. Multilink Forwarding . . . . . . . . . . . . . . . . 71
4.13.3. Mobile Ad-hoc Network (MANET) Forwarding . . . . . . 84 4.13.3. Mobile Ad-hoc Network (MANET) Forwarding . . . . . . 85
4.13.4. Client/Gateway Route Optimization . . . . . . . . . 87 4.13.4. Client/Gateway Route Optimization . . . . . . . . . 88
4.13.5. Client/Client Route Optimization . . . . . . . . . . 89 4.13.5. Client/Client Route Optimization . . . . . . . . . . 90
4.13.6. Intra-ANET/ENET Route Optimization for AERO Peers . 91 4.13.6. Intra-ANET/ENET Route Optimization for AERO Peers . 92
4.14. Neighbor Unreachability Detection (NUD) . . . . . . . . . 91 4.14. Neighbor Unreachability Detection (NUD) . . . . . . . . . 92
4.15. Mobility Management and Quality of Service (QoS) . . . . 93 4.15. Mobility Management and Quality of Service (QoS) . . . . 94
4.15.1. Mobility Update Messaging . . . . . . . . . . . . . 94 4.15.1. Mobility Update Messaging . . . . . . . . . . . . . 95
4.15.2. Announcing Link-Layer Information Changes . . . . . 95 4.15.2. Announcing Link-Layer Information Changes . . . . . 96
4.15.3. Bringing New Links Into Service . . . . . . . . . . 95 4.15.3. Bringing New Links Into Service . . . . . . . . . . 96
4.15.4. Deactivating Existing Links . . . . . . . . . . . . 95 4.15.4. Deactivating Existing Links . . . . . . . . . . . . 96
4.15.5. Moving Between Proxy/Servers . . . . . . . . . . . . 96 4.15.5. Moving Between Proxy/Servers . . . . . . . . . . . . 97
4.16. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 97 4.16. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 98
4.16.1. Source-Specific Multicast (SSM) . . . . . . . . . . 98 4.16.1. Source-Specific Multicast (SSM) . . . . . . . . . . 99
4.16.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 99 4.16.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 100
4.16.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 100 4.16.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 101
4.17. Operation over Multiple OMNI Links . . . . . . . . . . . 100 4.17. Operation over Multiple OMNI Links . . . . . . . . . . . 101
4.18. DNS Considerations . . . . . . . . . . . . . . . . . . . 101 4.18. DNS Considerations . . . . . . . . . . . . . . . . . . . 102
4.19. Transition/Coexistence Considerations . . . . . . . . . . 101 4.19. Transition/Coexistence Considerations . . . . . . . . . . 102
4.20. Proxy/Server-Gateway Bidirectional Forwarding 4.20. Proxy/Server-Gateway Bidirectional Forwarding
Detection . . . . . . . . . . . . . . . . . . . . . . . 102 Detection . . . . . . . . . . . . . . . . . . . . . . . 103
4.21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . 102 4.21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . 103
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 102 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 103
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104
7. Security Considerations . . . . . . . . . . . . . . . . . . . 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 104
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 107
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.1. Normative References . . . . . . . . . . . . . . . . . . 108 9.1. Normative References . . . . . . . . . . . . . . . . . . 109
9.2. Informative References . . . . . . . . . . . . . . . . . 109 9.2. Informative References . . . . . . . . . . . . . . . . . 110
Appendix A. Non-Normative Considerations . . . . . . . . . . . . 116 Appendix A. Non-Normative Considerations . . . . . . . . . . . . 117
A.1. Implementation Strategies for Route Optimization . . . . 116 A.1. Implementation Strategies for Route Optimization . . . . 117
A.2. Implicit Mobility Management . . . . . . . . . . . . . . 117 A.2. Implicit Mobility Management . . . . . . . . . . . . . . 118
A.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 117 A.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 118
A.4. AERO Critical Infrastructure Considerations . . . . . . . 118 A.4. AERO Critical Infrastructure Considerations . . . . . . . 119
A.5. AERO Server Failure Implications . . . . . . . . . . . . 118 A.5. AERO Server Failure Implications . . . . . . . . . . . . 119
A.6. AERO Client / Server Architecture . . . . . . . . . . . . 119 A.6. AERO Client / Server Architecture . . . . . . . . . . . . 120
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 121 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 122
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 122
1. Introduction 1. Introduction
Automatic Extended Route Optimization (AERO) fulfills the Automatic Extended Route Optimization (AERO) fulfills the
requirements of Distributed Mobility Management (DMM) [RFC7333] and requirements of Distributed Mobility Management (DMM) [RFC7333] and
route optimization [RFC5522] for air/land/sea/space mobility route optimization [RFC5522] for air/land/sea/space mobility
applications including aeronautical networking intelligent applications including aeronautical networking intelligent
transportation systems, home network users, enterprise mobile device transportation systems, home network users, enterprise mobile device
users, space exploration and many others. AERO is a secure users, space exploration and many others. AERO is a secure
internetworking and mobility management service that employs the internetworking and mobility management service that employs the
skipping to change at page 34, line 25 skipping to change at page 34, line 25
mobility event. However, in some environments this may result in mobility event. However, in some environments this may result in
excessive NS/NA control message overhead especially for Clients excessive NS/NA control message overhead especially for Clients
connected to low-end data links. connected to low-end data links.
Clients can therefore set the NUD/ARR/RPT flags in RS messages they Clients can therefore set the NUD/ARR/RPT flags in RS messages they
send to select their Proxy/Server service profiles. If the NUD flag send to select their Proxy/Server service profiles. If the NUD flag
is set, the FHS Proxy/Server that forwards the RS message assumes the is set, the FHS Proxy/Server that forwards the RS message assumes the
role of responding to NS messages and maintains peer NCEs associated role of responding to NS messages and maintains peer NCEs associated
with the NCE for this Client. If the ARR flag is set, the MAP Proxy/ with the NCE for this Client. If the ARR flag is set, the MAP Proxy/
Server that processes the RS message assumes the role of responding Server that processes the RS message assumes the role of responding
to NS(AR) messages on behalf of this Client NCE. If the RPT flag is to NS for Address Resolution (NS(AR)) messages on behalf of this
set, the MAP Proxy/Server that processes the RS message becomes Client NCE. If the RPT flag is set, the MAP Proxy/Server that
responsible for maintaining a "Report List" for each Client NCE for processes the RS message becomes responsible for maintaining a
the source addresses of NS(AR) messages it forwards on behalf of this "Report List" for each Client NCE for the source addresses of NS(AR)
Client. messages it forwards or responds to on behalf of this Client.
When a Client sets the RPT flag, the MAP Proxy/Server maintains When a Client sets the RPT flag, the MAP Proxy/Server maintains
Report List entries based on a ReportTime timer initialized to Report List entries based on a ReportTime timer initialized to
REACHABLE_TIME seconds upon receipt of an NS(AR) and decremented once REACHABLE_TIME seconds upon receipt of an NS(AR) and decremented once
per second while no additional NS(AR)s arrive. The MAP Proxy/Server per second while no additional NS(AR)s arrive. The MAP Proxy/Server
then sends uNA Mobility Management (MM) messages to each Report List then sends uNA Mobility Management (MM) messages to each Report List
entry when it receives a Client mobility update indication (e.g., entry when it receives a Client mobility update indication (e.g.,
through receipt of an RS with updated Interface Attributes and/or through receipt of an RS with updated Interface Attributes and/or
Traffic Selectors). When a Report List entry ReportTime timer Traffic Selectors). When a Report List entry ReportTime timer
expires, the MAP Proxy/Server deletes the entry. When a Client NCE expires, the MAP Proxy/Server deletes the entry. When a Client NCE
skipping to change at page 35, line 21 skipping to change at page 35, line 21
above. above.
When an Address Resolution Source (ARS) sends an NS(AR) message When an Address Resolution Source (ARS) sends an NS(AR) message
toward an Address Resolution Target (ART) Client/Relay, the OMNI link 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. 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 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 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 ARR on its own behalf. The ARR returns an NA(AR) response to the
ARS, which creates or updates a NCE for the ART while caching L3 and ARS, which creates or updates a NCE for the ART while caching L3 and
L2 addressing information. The ARS then (re)sets ReachableTime for L2 addressing information. The ARS then (re)sets ReachableTime for
the NCE to REACHABLE_TIME seconds and performs unicast NS/NA the NCE to REACHABLE_TIME seconds and performs NS/NA multilink
exchanges over specific underlay interface pairs to determine paths forwarding exchanges over specific underlay interface pairs to
for sending carrier packets directly to the ART. The ARS otherwise determine paths for sending carrier packets directly to the ART. The
decrements ReachableTime while no further solicited NA messages ARS otherwise decrements ReachableTime while no further solicited NA
arrive. messages arrive.
Proxy/Servers add an additional state DEPARTED to the list of NCE 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 states found in Section 7.3.2 of [RFC4861]. When a Client terminates
its association, the Proxy/Server OMNI interface sets a DepartTime its association, the Proxy/Server OMNI interface sets a DepartTime
variable for the NCE to DEPART_TIME seconds. DepartTime is variable for the NCE to DEPART_TIME seconds. DepartTime is
decremented unless a new IPv6 ND message causes the state to return decremented unless a new IPv6 ND message causes the state to return
to REACHABLE. While a NCE is in the DEPARTED state, the Proxy/Server to REACHABLE. While a NCE is in the DEPARTED state, the Proxy/Server
forwards OAL packets/fragments destined to the target Client to the forwards OAL packets/fragments destined to the target Client to the
Client's new FHS/MAP Proxy/Server instead. Client's new FHS/MAP Proxy/Server instead.
skipping to change at page 37, line 43 skipping to change at page 37, line 43
AERO Hosts and Clients on ENET underlay networks send RS messages to AERO Hosts and Clients on ENET underlay networks send RS messages to
the link-scoped All-Routers multicast address, a GUA (SRA) address of the link-scoped All-Routers multicast address, a GUA (SRA) address of
a remote MAP Proxy/Server or the MNP (SRA) address of an upstream a remote MAP Proxy/Server or the MNP (SRA) address of an upstream
Client while using unicast or anycast OAL/L2 addresses. The upstream Client while using unicast or anycast OAL/L2 addresses. The upstream
AERO Client responds by returning a unicast RA message. AERO Client responds by returning a unicast RA message.
AERO nodes use NS/NA messages for the following purposes: AERO nodes use NS/NA messages for the following purposes:
* NS/NA(AR) messages are used for address resolution and optionally * NS/NA(AR) messages are used for address resolution and optionally
to establish sequence number windows. The ARS sends an NS(AR) to to establish sequence number windows. The ARS sends an NS(AR) to
the solicited-node multicast address of the ART, and an ARR with the unicast address of the ART, and an ARR with addressing
addressing information for the ART returns a unicast NA(AR) that information for the ART returns a unicast NA(AR) that contains
contains current, consistent and authentic target address current, consistent and authentic target address resolution
resolution information. NS(AR) messages include a solicited-node information. NS(AR) messages include a solicited-node multicast
multicast destination address to distinguish them from ordinary NS destination address to distinguish them from ordinary NS messages.
messages. NS/NA(AR) messages must be secured. NS/NA(AR) messages must be secured.
* Ordinary NS/NA messages are used determine target reachability, * Other NS/NA message exchanges are used determine target
establish and maintain NAT state, and/or establish multilink reachability (NS/NA(NUD)), establish/maintain Route Optimization
forwarding (i.e., AFIB) state. The source sends an NS to the state (NS/NA(RO)) or establish/maintain multilink forwarding state
unicast address of the target while optionally including an OMNI (NS/NA(MF)). The source sends an NS to the unicast address of the
AERO Forwarding Parameters (AFP) sub-option naming a specific target while optionally including an OMNI AERO Forwarding
underlay interface pair, and the target returns a unicast NA that Parameters (AFP) sub-option naming a specific underlay interface
includes a responsive AFP if necessary. NS/NA messages that use pair, and the target returns a unicast NA that includes a
an in-window sequence number and do not update any other state responsive AFP if necessary. NS/NA messages that use an in-window
need not include an authentication signature but must include an sequence number and do not update any other state need not include
IPv6 ND message checksum. NS/NA messages used to establish window an authentication signature but must include an IPv6 ND message
synchronization and/or AFIB state must be secured. checksum. NS/NA messages used to establish window synchronization
and/or AFIB state must be secured.
* Unsolicited NA (uNA) messages are used to signal addressing and/or * Unsolicited NA (uNA) messages are used to signal addressing and/or
other neighbor state changes (e.g., address changes due to other mobility management (uNA(MM)) neighbor state changes (e.g.,
mobility, signal degradation, traffic selector updates, etc.). uNA address changes due to mobility, signal degradation, traffic
messages can also be also used to acknowledge receipt of non- selector updates, etc.). uNA messages can also be also used to
solicitation IPv6 ND messages (see below). uNA messages that acknowledge receipt of other IPv6 ND messages (uNA(ACK)) as well
update state information must be secured. as to securely convey ICMP error information (uNA(ERR)). uNA
messages that update state information must be secured.
* NS/NA(DAD) messages are not used in AERO, since Duplicate Address * NS/NA(DAD) messages are not used in AERO, since Duplicate Address
Detection is not required. Detection is not required.
AERO and OMNI together support an added reliability feature not AERO and OMNI together support an added reliability feature not
available in ordinary IPv6 ND messaging. In particular, nodes can available in ordinary IPv6 ND messaging. In particular, nodes can
set the OMNI Neighbor Coordination SNR flag or Window Synchronization set the OMNI Neighbor Coordination SNR flag or Window Synchronization
SYN flag in unicast non-solicitation IPv6 ND messages (including RA, SYN flag in unicast non-solicitation IPv6 ND messages (including RA,
NA and Redirect) to request a synchronous (but "unsolicited") NA and Redirect) to request a synchronous (but "unsolicited")
uNA(ACK) acknowledgement response (see: [I-D.templin-intarea-omni2]). uNA(ACK) acknowledgement response (see: [I-D.templin-intarea-omni2]).
skipping to change at page 41, line 22 skipping to change at page 41, line 49
a Routing Header extension of the OAL header, the Extended Fragment a Routing Header extension of the OAL header, the Extended Fragment
Header identifies each fragment, and the L2 headers are prepared as Header identifies each fragment, and the L2 headers are prepared as
discussed in [I-D.templin-intarea-omni2]. The OAL source sends each discussed in [I-D.templin-intarea-omni2]. The OAL source sends each
such carrier packet into the SRT unsecured spanning tree, where they such carrier packet into the SRT unsecured spanning tree, where they
may be forwarded over multiple OAL intermediate systems until they may be forwarded over multiple OAL intermediate systems until they
arrive at the OAL destination. These carrier packets may themselves arrive at the OAL destination. These carrier packets may themselves
be subject to L2 fragmentation and reassembly along the path. be subject to L2 fragmentation and reassembly along the path.
The OMNI link control plane service distributes Client MNP prefix The OMNI link control plane service distributes Client MNP prefix
information that may change occasionally due to regional node information that may change occasionally due to regional node
mobility, as well more static information for Relay FNPs and per- mobility, as well as more static information for Relay FNPs and per-
segment SNPs that rarely change. OMNI link Gateways and Proxy/ segment SNPs that rarely change. OMNI link Gateways and Proxy/
Servers use the information to establish and maintain a forwarding Servers use the information to establish and maintain a forwarding
plane spanning tree that connects all nodes on the link. The plane spanning tree that connects all nodes on the link. The
spanning tree supports a virtual bridging service according to link spanning tree supports a virtual bridging service according to link
layer (instead of network layer) information, but may often include layer (instead of network layer) information, but may often include
longer paths than necessary. longer paths than necessary.
Each OMNI interface therefore also includes an AERO Forwarding Each OMNI interface therefore also includes an AERO Forwarding
Information Base (AFIB) that caches AERO Forwarding Vectors (AFVs) Information Base (AFIB) that caches AERO Forwarding Vectors (AFVs)
which can provide both carrier packet Identification context and more which can provide both carrier packet Identification context and more
skipping to change at page 69, line 14 skipping to change at page 70, line 14
When the ART's FHS Proxy/Server receives carrier packets sent by an When the ART's FHS Proxy/Server receives carrier packets sent by an
ART acting as an ARR on its own behalf, it performs L2 reassembly and ART acting as an ARR on its own behalf, it performs L2 reassembly and
decapsulation, verifies the Identification, performs OAL reassembly, decapsulation, verifies the Identification, performs OAL reassembly,
then verifies the checksum/authentication signature. The Proxy/ then verifies the checksum/authentication signature. The Proxy/
Server then verifies that the RIO information is acceptable, changes Server then verifies that the RIO information is acceptable, changes
the OAL source address to its own SNP SRA GUA and changes the OAL the OAL source address to its own SNP SRA GUA and changes the OAL
destination to the FNP/MNP SRA address or SNP GUA corresponding to destination to the FNP/MNP SRA address or SNP GUA corresponding to
the NA(AR) destination. The Proxy/Server next decrements the OAL Hop the NA(AR) destination. The Proxy/Server next decrements the OAL Hop
Limit, includes an appropriate Identification then recalculates the Limit, includes an appropriate Identification then recalculates the
NA checksum. The Proxy/Server finally performs OAL fragmentation NA(AR) checksum. The Proxy/Server finally performs OAL fragmentation
followed by L2 encapsulation/fragmentation and forwards the resulting followed by L2 encapsulation/fragmentation and forwards the resulting
carrier packets into the secured spanning tree. carrier packets into the secured spanning tree.
4.13.1.4. Relaying the NA(AR) 4.13.1.4. Relaying the NA(AR)
When a Gateway receives NA(AR) carrier packets, it performs L2 When a Gateway receives NA(AR) carrier packets, it performs L2
reassembly/decapsulation and determines the next hop by consulting reassembly/decapsulation and determines the next hop by consulting
its standard IPv6 forwarding table for the OAL header destination its standard IPv6 forwarding table for the OAL header destination
address. The Gateway then decrements the OAL header Hop Limit, address. The Gateway then decrements the OAL header Hop Limit,
performs L2 encapsulation/fragmentation and forwards the resulting performs L2 encapsulation/fragmentation and forwards the resulting
skipping to change at page 81, line 23 skipping to change at page 82, line 23
synchronization state must be determined individually using synchronization state must be determined individually using
additional NS/NA(MF) messages. additional NS/NA(MF) messages.
To update AFIB state in the path, the FHS node that sent the original To update AFIB state in the path, the FHS node that sent the original
NS(MF) message with AFP Job code '00' can send additional NS(MF) NS(MF) message with AFP Job code '00' can send additional NS(MF)
messages with AFP sub-options with Job code '10' (Follow "A"; Record messages with AFP sub-options with Job code '10' (Follow "A"; Record
"B") and with window synchronization parameters. The message will be "B") and with window synchronization parameters. The message will be
processed by all intermediate systems which will refresh AFV timers, processed by all intermediate systems which will refresh AFV timers,
cache window synchronization parameters and forward the NS(MF) onward cache window synchronization parameters and forward the NS(MF) onward
toward the LHS node that returned the original NA(MF) message. When toward the LHS node that returned the original NA(MF) message. When
the LHS node receives the NS, it returns an NA(MF) message with AFP the LHS node receives the NS(MF), it returns an NA(MF) message with
Job code '11' (Follow "B"; Record "A"). AFP Job code '11' (Follow "B"; Record "A").
At the same time, the LHS node that received the original NS(MF) At the same time, the LHS node that received the original NS(MF)
message with Job code '00' can send additional NS(MF) messages with message with Job code '00' can send additional NS(MF) messages with
Job code '11' in order to cause the FHS node to return an NA(MF) Job code '11' in order to cause the FHS node to return an NA(MF)
message with AFP Job code '10'. The process can therefore be message with AFP Job code '10'. The process can therefore be
coordinated asynchronously with the FHS/LHS nodes initiating an NS/ coordinated asynchronously with the FHS/LHS nodes initiating an NS/
NA(MF) exchange independently of one another. The exchanges will NA(MF) exchange independently of one another. The exchanges will
succeed as long as the AFIB state in the path remains active. Note succeed as long as the AFIB state in the path remains active. Note
that all intermediate system processing of Job code '10' and '11' NS/ that all intermediate system processing of Job code '10' and '11' NS/
NA(MF) messages is conducted the same as for the initial exchange NA(MF) messages is conducted the same as for the initial exchange
skipping to change at page 83, line 8 skipping to change at page 84, line 8
Forward and FMT-Mode set discover each other's NATed L2ADDR Forward and FMT-Mode set discover each other's NATed L2ADDR
addresses, they can exchange carrier packets that contain OAL addresses, they can exchange carrier packets that contain OAL
packets/fragments directly with header compression using AFVIs packets/fragments directly with header compression using AFVIs
discovered as above (see: Section 4.13.5). The FHS Client will have discovered as above (see: Section 4.13.5). The FHS Client will have
cached the "A" AFVI for the LHS Client, which will have cached the cached the "A" AFVI for the LHS Client, which will have cached the
"B" AFVI for the FHS Client. "B" AFVI for the FHS Client.
When the FHS Client or FHS Proxy/Server sends an NS(MF) for the When the FHS Client or FHS Proxy/Server sends an NS(MF) for the
purpose of establishing multilink forwarding state, it should wait up purpose of establishing multilink forwarding state, it should wait up
to RETRANS_TIMER seconds to receive a responsive NA(MF). The FHS to RETRANS_TIMER seconds to receive a responsive NA(MF). The FHS
node can then retransmit the NS up to MAX_UNICAST_SOLICIT times node can then retransmit the NS(MF) up to MAX_UNICAST_SOLICIT times
before giving up. Note that each successive attempt establishes new before giving up. Note that each successive attempt establishes new
AFV state in the OAL intermediate systems, but that any abandoned AFV state in the OAL intermediate systems, but that any abandoned
stale AFV state will be quickly reclaimed. stale AFV state will be quickly reclaimed.
4.13.2.8. Rapid Commit Multilink Forwarding 4.13.2.8. Rapid Commit Multilink Forwarding
Multilink forwarding can often be invoked in conjunction with Address Multilink forwarding can often be invoked in conjunction with Address
Resolution in order to reduce control message overhead and round-trip Resolution in order to reduce control message overhead and round-trip
delays. When an ART acting as an ARR receives an NS(AR) with a set delays. When an ART acting as an ARR receives an NS(AR) with a set
of Interface Attributes for the ARS source Client, it can perform of Interface Attributes for the ARS source Client, it can perform
"rapid commit" by immediately invoking multilink forwarding as above "rapid commit" by immediately invoking multilink forwarding as above
at the same time as returning the NA(AR). at the same time as returning the NA(AR).
In order to perform rapid commit, the ARR includes an AFP sub-option In order to perform rapid commit, the ARR includes an AFP sub-option
with Job code '00' and a Window Synchronization sub-option as though with Job code '00' and a Window Synchronization sub-option as though
it were initiating a multilink coordination NS/NA exchange as it were initiating a multilink coordination NS/NA(MF) exchange as
specified above. The ARR then includes any Interface Attributes and/ specified above. The ARR then includes any Interface Attributes and/
or Traffic Selector sub-options as necessary to satisfy the address or Traffic Selector sub-options as necessary to satisfy the address
resolution request. The ARR then returns the NA(AR) to the ARS using resolution request. The ARR then returns the NA(AR) to the ARS using
the same hop-by-hop OAL addressing disciplines as specified above for the same hop-by-hop OAL addressing disciplines as specified above for
an ordinary multilink NS/NA(MF) exchange. This will cause the NA(AR) an ordinary multilink NS/NA(MF) exchange. This will cause the NA(AR)
to visit all FHS/LHS OAL intermediate systems on the path towards the to visit all FHS/LHS OAL intermediate systems on the path towards the
ARS. ARS.
When the NA(AR) traverses the return path to the ARS, OAL When the NA(AR) traverses the return path to the ARS, OAL
intermediate systems in the path process the NS(MF) AFP information intermediate systems in the path process the NS(MF) AFP information
skipping to change at page 85, line 39 skipping to change at page 86, line 39
while writing the value 0 into the second SID field. The source while writing the value 0 into the second SID field. The source
Client then caches the full OAL header in an AFV for the destination Client then caches the full OAL header in an AFV for the destination
and sends the NS(MF) to the next hop. and sends the NS(MF) to the next hop.
When the next MANET forwarding hop's OMNI interface receives the When the next MANET forwarding hop's OMNI interface receives the
NS(MF), it creates an AFV and caches the full OAL header as well as NS(MF), it creates an AFV and caches the full OAL header as well as
the previous hop's "C" AFVI, L2 address and Window Synchronization the previous hop's "C" AFVI, L2 address and Window Synchronization
parameters for the forward path. The OMNI interface then selects its parameters for the forward path. The OMNI interface then selects its
own non-zero/unique "C" AFVI and over-writes that value into the own non-zero/unique "C" AFVI and over-writes that value into the
first SID field of the CRH-16. Consecutive MANET forwarding hops first SID field of the CRH-16. Consecutive MANET forwarding hops
then repetitively forward the NS to their respective next hops, which then repetitively forward the NS(MF) to their respective next hops,
perform the same procedures as above. The process continues until which perform the same procedures as above. The process continues
the NS(MF) reaches either a final destination within the same MANET until the NS(MF) reaches either a final destination within the same
or a MANET border Proxy/Server that can forward to destinations in MANET or a MANET border Proxy/Server that can forward to destinations
other networks. in other networks.
When the final destination is within the same MANET, the destination When the final destination is within the same MANET, the destination
OMNI interface returns an NA(MF) with a CRH-16 and uses the same non- OMNI interface returns an NA(MF) with a CRH-16 and uses the same non-
zero/unique "C" AVFI discipline described above in the reverse path zero/unique "C" AVFI discipline described above in the reverse path
which may travel over a completely different set of MANET routers which may travel over a completely different set of MANET routers
than those in the forward path. Otherwise, the Proxy/Server that than those in the forward path. Otherwise, the Proxy/Server that
receives the NS(MF) forwards it to other networks according to the receives the NS(MF) forwards it to other networks according to the
same multilink forwarding procedures discussed in Section 4.13.2. same multilink forwarding procedures discussed in Section 4.13.2.
When the Proxy/Server eventually receives an NA to return to the When the Proxy/Server eventually receives an NA(MF) to return to the
original source, the Proxy/Server inserts a CRH-16 (while removing original source, the Proxy/Server inserts a CRH-16 (while removing
the CRH-32 if present) and performs the same reverse path forwarding the CRH-32 if present) and performs the same reverse path forwarding
that an ordinary MANET destination would perform as described above. that an ordinary MANET destination would perform as described above.
When the original source receives the NA, header compression state When the original source receives the NA(MF), header compression
will have been completely populated in both the forward and reverse state will have been completely populated in both the forward and
paths and the source and destination nodes can begin sending ordinary reverse paths and the source and destination nodes can begin sending
packets with OCH headers instead of full OAL headers. ordinary packets with OCH headers instead of full OAL headers.
The same procedures that appear above also apply when an NS(MF) The same procedures that appear above also apply when an NS(MF)
originating from a remote network arrives at a MANET border Proxy/ originating from a remote network arrives at a MANET border Proxy/
Server for a MANET that contains the final destination. The Proxy/ Server for a MANET that contains the final destination. The Proxy/
Server assumes the source role, inserts a CRH-16 with a non-zero/ Server assumes the source role, inserts a CRH-16 with a non-zero/
unique "C" AFVI and forwards it to the next MANET forwarding hop unique "C" AFVI and forwards it to the next MANET forwarding hop
toward the final destination. The forwarding process continues toward the final destination. The forwarding process continues
between successive MANET routers until the final destination receives between successive MANET routers until the final destination receives
the NS(MF). The final destination then prepares a responsive NA(MF) the NS(MF). The final destination then prepares a responsive NA(MF)
again while inserting a CRH-16 with a non-zero/unique "C" AFVI and again while inserting a CRH-16 with a non-zero/unique "C" AFVI and
skipping to change at page 87, line 51 skipping to change at page 88, line 51
will then cause the packets to visit the OMNI interface of each will then cause the packets to visit the OMNI interface of each
successive next-hop MANET node. successive next-hop MANET node.
4.13.4. Client/Gateway Route Optimization 4.13.4. Client/Gateway Route Optimization
Following multilink route optimization for specific underlay Following multilink route optimization for specific underlay
interface pairs, FHS/LHS Clients located on open INETs can invoke interface pairs, FHS/LHS Clients located on open INETs can invoke
Client/Gateway route optimization to improve performance and reduce Client/Gateway route optimization to improve performance and reduce
load and congestion on their respective Proxy/Servers. To initiate load and congestion on their respective Proxy/Servers. To initiate
Client/Gateway route optimization, the Client prepares an NS for Client/Gateway route optimization, the Client prepares an NS for
Route Optimzation (RO) message with its own MNP SRA GUA or SNP GUA as Route Optimization (RO) message with its own MNP SRA GUA or SNP GUA
the source and the SNP SRA GUA of the candidate Gateway as the as the source and the SNP SRA GUA of the candidate Gateway as the
destination while creating a NCE for the Gateway if necessary. The destination while creating a NCE for the Gateway if necessary. The
NS(RO) message must be encapsulated as an atomic fragment and not NS(RO) message must be encapsulated as an atomic fragment and not
subject to OAL fragmentation. subject to OAL fragmentation.
The Client then includes an Interface Attributes sub-option for its The Client then includes an Interface Attributes sub-option for its
underlay interface as well as an authentication signature but does underlay interface as well as an authentication signature but does
not include window synchronization parameters. The Client then not include window synchronization parameters. The Client then
performs OAL encapsulation with its own SNP GUA as the source and the performs OAL encapsulation with its own SNP GUA as the source and the
SNP SRA GUA of the Gateway as the destination while including a SNP SRA GUA of the Gateway as the destination while including a
randomly-chosen Identification value, then performs L2 encapsulation/ randomly-chosen Identification value, then performs L2 encapsulation/
skipping to change at page 90, line 46 skipping to change at page 91, line 46
performs OAL fragmentation followed by L2 encapsulation/fragmentation performs OAL fragmentation followed by L2 encapsulation/fragmentation
then forwards the resulting carrier packets directly to the source then forwards the resulting carrier packets directly to the source
Client. Client.
Following the initial NS/NA(RO) exchange, both Clients mark their Following the initial NS/NA(RO) exchange, both Clients mark their
respective (source, target) underlay interface pairs as "trusted" for respective (source, target) underlay interface pairs as "trusted" for
no more than ReachableTime seconds. The Clients can then begin no more than ReachableTime seconds. The Clients can then begin
exchanging ordinary data packets as OCH encapsulated carrier packets. exchanging ordinary data packets as OCH encapsulated carrier packets.
While the Clients continue to exchange packets via the direct path While the Clients continue to exchange packets via the direct path
avoiding all Proxy/Servers and Gateways, they should perform avoiding all Proxy/Servers and Gateways, they should perform
additional NS/NA exchanges via their local Proxy/Servers to refresh additional NS/NA(RO) exchanges via their local Proxy/Servers to
NCE state as well as send additional bubbles to the peer's Origin refresh NCE state as well as send additional bubbles to the peer's
address information if necessary to refresh NAT state. Origin address information if necessary to refresh NAT state.
Note: these procedures are suitable for a widely-deployed but basic Note: these procedures are suitable for a widely-deployed but basic
class of NATs. Procedures for advanced NAT classes are outlined in class of NATs. Procedures for advanced NAT classes are outlined in
[RFC6081], which provides mechanisms that can be employed equally for [RFC6081], which provides mechanisms that can be employed equally for
AERO using the corresponding sub-options specified by OMNI. AERO using the corresponding sub-options specified by OMNI.
Note: each communicating pair of Clients may need to maintain NAT Note: each communicating pair of Clients may need to maintain NAT
state for peer to peer communications via multiple underlay interface state for peer to peer communications via multiple underlay interface
pairs. It is therefore important that Origin Indications are pairs. It is therefore important that Origin Indications are
maintained with the correct peer interface and that the NCE may cache maintained with the correct peer interface and that the NCE may cache
skipping to change at page 91, line 38 skipping to change at page 92, line 38
Client returns an IPv6 ND Redirect message to inform the source that Client returns an IPv6 ND Redirect message to inform the source that
that target can be reached directly. The contents of the Redirect that target can be reached directly. The contents of the Redirect
message are the same as specified in [RFC4861], and should also message are the same as specified in [RFC4861], and should also
include any RIOs with MNP information corresponding to the target. include any RIOs with MNP information corresponding to the target.
In the same fashion, when a Proxy/Server forwards an OAL packet (or In the same fashion, when a Proxy/Server forwards an OAL packet (or
original IP packet/parcel) from a Host or Client connected to one of original IP packet/parcel) from a Host or Client connected to one of
its downstream ANETs to a peer within the same downstream ANET, the its downstream ANETs to a peer within the same downstream ANET, the
Proxy/Server returns an IPv6 ND Redirect message. Proxy/Server returns an IPv6 ND Redirect message.
All other route optimization functions are conducted per the NS/NA All other route optimization functions are conducted per the NS/
messaging discussed in the previous sections. NA(RO) messaging discussed in the previous sections.
4.14. Neighbor Unreachability Detection (NUD) 4.14. Neighbor Unreachability Detection (NUD)
AERO nodes perform Neighbor Unreachability Detection (NUD) per AERO nodes perform Neighbor Unreachability Detection (NUD) per
[RFC4861] either reactively in response to persistent link layer [RFC4861] either reactively in response to persistent link layer
errors (see Section 4.11) or proactively to confirm reachability. errors (see Section 4.11) or proactively to confirm reachability.
The NUD algorithm is based on periodic control message exchanges and The NUD algorithm is based on periodic control message exchanges and
may further be seeded by IPv6 ND hints of forward progress, but care may further be seeded by IPv6 ND hints of forward progress, but care
must be taken to avoid inferring reachability based on spoofed must be taken to avoid inferring reachability based on spoofed
information. For example, IPv6 ND message exchanges that include information. For example, IPv6 ND message exchanges that include
skipping to change at page 92, line 31 skipping to change at page 93, line 31
as the source may perform additional reachability probing through as the source may perform additional reachability probing through
NS(NUD) messages over the SRT secured or unsecured spanning tree, or NS(NUD) messages over the SRT secured or unsecured spanning tree, or
through NS(NUD) messages sent directly to an underlay interface of through NS(NUD) messages sent directly to an underlay interface of
the target itself. While testing a target underlay interface, the the target itself. While testing a target underlay interface, the
source can optionally continue to forward OAL packets/fragments via source can optionally continue to forward OAL packets/fragments via
alternate interfaces or maintain a small queue of carrier packets alternate interfaces or maintain a small queue of carrier packets
until target reachability is confirmed. until target reachability is confirmed.
NS(NUD) messages are encapsulated, fragmented and transmitted as NS(NUD) messages are encapsulated, fragmented and transmitted as
carrier packets the same as for ordinary original IP data packets/ carrier packets the same as for ordinary original IP data packets/
parcels. The source encapsulates the NS message the same as parcels. The source encapsulates the NS(NUD) message the same as
described in Section 4.13.2 and includes an Interface Attributes sub- described in Section 4.13.2 and includes an Interface Attributes sub-
option with ifIndex set to identify its underlay interface used for option with ifIndex set to identify its underlay interface used for
forwarding. The source then includes an in-window Identification, forwarding. The source then includes an in-window Identification,
performs OAL fragmentation followed by L2 encapsulation/fragmentation performs OAL fragmentation followed by L2 encapsulation/fragmentation
then forwards the resulting carrier packets into the unsecured then forwards the resulting carrier packets into the unsecured
spanning tree, either directly to the target if it is in the local spanning tree, either directly to the target if it is in the local
segment or directly to a Gateway in the local segment. segment or directly to a Gateway in the local segment.
When the target receives the NS(NUD) carrier packets, it performs L2 When the target receives the NS(NUD) carrier packets, it performs L2
reassembly/decapsulation, verifies that it has a NCE for this source reassembly/decapsulation, verifies that it has a NCE for this source
skipping to change at page 93, line 43 skipping to change at page 94, line 43
serves to confirm neighbor reachability. When a Client's underlay serves to confirm neighbor reachability. When a Client's underlay
interface attributes change, the Client is responsible for updating interface attributes change, the Client is responsible for updating
the MAP Proxy/Server through new RS/RA exchanges using the FHS Proxy/ 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 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 a proxy to perform some IPv6 ND exchanges on the Client's behalf
without consuming bandwidth on the Client underlay interface. without consuming bandwidth on the Client underlay interface.
Note: when a Client's underlay interface address changes, the Client Note: when a Client's underlay interface address changes, the Client
and/or its (former) FHS Proxy/Server for this interface must and/or its (former) FHS Proxy/Server for this interface must
invalidate any AFVs based on the (changed) interface. Future data invalidate any AFVs based on the (changed) interface. Future data
packet forwarding will then trigger a new multilink forwarding NS/NA packet forwarding will then trigger a new multilink forwarding NS/
exchange to re-seed new AFVs in the path. NA(MF) exchange to re-seed new AFVs in the path.
Mobility management considerations are specified in the following Mobility management considerations are specified in the following
sections. sections.
4.15.1. Mobility Update Messaging 4.15.1. Mobility Update Messaging
Mobile Clients (and/or their MAP Proxy/Servers) accommodate mobility Mobile Clients (and/or their MAP Proxy/Servers) accommodate mobility
and/or multilink change events by sending secured uNA Mobility and/or multilink change events by sending secured uNA Mobility
Management (MM) messages to each active neighbor. When a node sends Management (MM) messages to each active neighbor. When a node sends
a uNA(MM) message to each specific neighbor on behalf of a mobile a uNA(MM) message to each specific neighbor on behalf of a mobile
 End of changes. 28 change blocks. 
109 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/