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