Summary

  • The 28 October RTGWG draft, revision 35 proposes a private BGP overlay for aircraft mobility. Stub border routers send active mobile reachability to a small core; the core does not send a full BGP table back. The draft places continuous BGP sessions on secured ground links, not narrow aviation radio links.
  • A core border router may run eBGP for both the aviation overlay and its underlying network, with overlay routes resolving over underlying routes. The draft calls for separate AS identities and route policy, or separate BGP instances, to keep announcements from crossing between those domains. Naming an overlay does not configure the export filter.

A flight is a change event, not a broadcast order

An aircraft can change its serving ground station while the people depending on its communications still need a working path. The ATN/IPS BGP working-group draft proposes to treat that movement as a routing problem inside an aviation overlay. It does not require every flight event to become news for the global public BGP table. Nor does it make the aircraft maintain a continuous BGP peering session over its radio link. The draft says that kind of control traffic belongs on secured, well-connected ground infrastructure. Aviation links are constrained and can be intermittent; their job is hard enough without a routing protocol trying to chat through them.

The design divides ground border routers into stub ASBRs and core ASBRs. A stub advertises the mobile prefixes and addresses currently active in its area to a small set of core routers. It does not receive the core's BGP updates in return. It holds default routes toward the core and therefore does not need the full map. Core routers exchange the active map with one another inside a partition. Movement wholly inside a stub's domain can be handled locally; a move between stub domains changes which stub announces the mobile reachability. This is a deliberate information budget.

A router close to the radio access edge receives the amount of routing state it needs, not a copy of the entire sky.

The proposal uses ordinary BGP-4 machinery in a constrained topology rather than a new BGP wire protocol. Stub-to-core peering runs over secured direct links or tunnels; core-to-core links need their own protection. The draft permits BFD, specified in RFC 5880, as a faster way to detect failed peers or links. Faster detection matters when a path to a moving endpoint changes, but a fast alarm is only useful if the next valid route remains inside the right domain.

The border router has two uniforms

The sentence with the sharpest governance consequence appears in the protocol considerations. A core ASBR may speak eBGP in the aviation overlay and in the underlying INET. Aviation routes resolve over routes in that underlying network. The same box can therefore understand both maps. The draft says it needs separate local ASes and routing policy, or isolated BGP instances, to prevent routes from propagating from one BGP domain into the other.

That is a configuration decision, not a benefit automatically delivered by the word “overlay.” The underlying INET need not be the public Internet; it can be a provider network. The boundary still matters. If an operator exports mobile reachability into the underlying domain, the private topology no longer contains the updates it was built to contain. If an import policy is too broad, underlay state can also influence the aviation control plane in ways its designers did not intend. The draft's architecture gives operators a place to enforce separation. It cannot fill in their route maps, peer groups and local AS assignments for them.

There is a second handoff between BGP and DNS. For a much larger population of mobile nodes, the draft offers a variant that leaves only border-router addresses in BGP and stores the mapping from a mobile node to its serving stub in a DNS-based directory. When the client moves to a new stub, that stub replaces the old mapping. RFC 1035 supplies DNS's underlying model; the draft specifies a particular reverse-zone use for this architecture. This variant moves update pressure out of BGP, but it gives the mapping's freshness and authorization practical weight. A route to a border router is useful only if the lookup still names the correct border router for the moving client.

The draft also describes shortcuts around the default spanning-tree path. They may reduce detours, but the security section separates protected control and unoptimized paths from data on optimized paths, for which it calls for end-to-end higher-layer security. Likewise, it asks stub routers to rate-limit traffic toward low-rate aviation links. These are not decorative clauses. They identify where a route that is correct in a table can still become a poor service for the aircraft at the far end.

This is revision 35 of an active working-group Internet-Draft, intended as an Informational document. Its emulation results and worst-case update arithmetic are design evidence, not a production trace of worldwide air traffic. No official production route-export record in this source set shows whether a named operator has kept the overlay boundary intact. A real configuration and route trace would change that assessment. The immediate issue is visible without one: a core router with two BGP roles needs an explicit rule for which reachability is allowed to leave each role.

Official originals