Internet Engineering Task Force S. Burleigh Internet Draft IPNGROUP Intended status: Informational November 21, 2024 Expires: May 2025 Bundle Protocol Regions for Network Scaling draft-burleigh-regions-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 25, 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Burleigh Expires May 2025 [Page 1] Internet-Draft Bundle Protocol Regions November 2024 Abstract This document describes a mechanism for assembling a delay-tolerant network of arbitrary size from discrete sets of nodes - "regions" - within which delay-tolerant routing based on contact plans is computationally tractable. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Contact plan multiplicity......................................3 4. Inter-regional forwarding......................................4 5. Closing thoughts...............................................7 6. Security Considerations........................................8 7. IANA Considerations............................................8 8. References.....................................................8 8.1. Normative References......................................8 8.2. Informative References....................................8 1. Introduction A network node in the Internet is identified by its IP address, i.e., its location within the Internet topology. This makes the computation of a route through the network to a given node relatively simple and quick: the topology of the network is implicit in the hierarchical labeling of addresses, which enables address aggregation. Routing tables may be relatively small. A router need only look at the prefix of an address to determine which "next hop" to use for the forwarding of a packet. Delay-tolerant networking (DTN) [RFC4838] is different. One core principle of DTN, as implemented in DTN's core Bundle Protocol (BP) [RFC9171], is "late binding", the observation that nodes should be identified by name (possibly a numerical name) rather than by address, because transmission may take so long that a node's location in the network topology may change while a protocol data unit - "bundle" - destined for that node is in transit, invalidating the transmission. Nodes' identifiers are expected to be stable throughout the forwarding of bundles from source nodes to destination nodes; their addresses are not. A node identifier may have organizational significance, but it will not have topological significance. So in BP the route to a given node cannot be computed from the address of the node, since the address at which the node will reside Burleigh Expires May 2025 [Page 2] Internet-Draft Bundle Protocol Regions November 2024 upon bundle delivery is not necessarily known at the time the route must be computed. Route computation in a BP-based network will instead typically rest on explicit advance knowledge of time-varying network topology, a "contact plan" listing all anticipated episodes of connectivity between nodes [SABR]. BP routing is computationally intensive as it is sensitive not only to the anticipated lapses in connectivity but also to bundle expiration times and to conflicts between required quality of service and prior transmission commitments. This means that BP route computation can retard forwarding and degrade network performance unless the contact plan is relatively small. The "membership" of a contact plan, here termed a "region", is the set of all nodes that are cited in the plan's identified contacts as the anticipated senders and receivers of bundles. If the contact plan is small then its membership is necessarily small. The number of nodes among which routes may be computed - that is, the size of the network - is limited. This document discusses a possible remediation, the assembly of a large network from multiple small regions. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Contact plan multiplicity One way to enable the size of the network to increase is to configure multiple small contact plans - thus multiple small regions, individually identified by managed region numbers - that are interconnected. An interconnection between two operationally adjacent regions - here termed a "passageway" - is a node that is cited in both regions' contact plans. Bundles sourced in one region may be relayed via a passageway for delivery at a destination in another region. New regions may be established as needed, without limit, and formation of a passageway between two regions is simply a matter of editing their contact plans. Burleigh Expires May 2025 [Page 3] Internet-Draft Bundle Protocol Regions November 2024 Two regions between which a passageway exists are adjacent in a topology that is modeled by a graph whose vertices are regions and whose arcs are passageways. Bundles sourced at a BP node in one region may ultimately be delivered to a BP node in another region if there is a route, through that graph, between the two regions. Since this inter-regional forwarding does not require that any contact plan grow beyond computational tractability, and since the number of regions is not limited, the network may grow without limit. This then raises a new problem: how do we compute a route through the region graph? In order to forward bundles accurately through the region topology, a BP router must have some sort of knowledge of that topology; how is that knowledge acquired? In work performed to date on inter-regional forwarding [Madoery] [Alessi], region topology knowledge has been explicit: a probe bundle destined for some node is flooded throughout the network, forwarded over all passageways among all regions, and the response - returned along the path that is eventually found to have conveyed the bundle to its destination - constitutes a record of the path from the source to the destination, a series of region numbers. This enables the next-hop region for that destination to be recorded at every router along the path. However, recording next-hop information for all downstream destinations at every router may be prohibitively resource- intensive. Worse, ongoing dynamic region formation and interconnection could invalidate these discovered routes and could potentially introduce routing loops. 4. Inter-regional forwarding In inter-regional forwarding as originally conceived, each contact plan would be assigned a region number, by management, when it became desirable for nodes that were cited in that plan's contacts to exchange bundles with nodes that were not. Regions would therefore come into existence and interconnection dynamically; control over region topology would be solely at the discretion of the multiple network operators. It is likely that no single operator would ever have accurate current knowledge of the entire topology, and it is almost certain that this knowledge would never be concurrently shared by all network managers. As a result, we would expect relatively frequent errors in route computation. Suppose that we instead posit an abstract grid comprising an unlimited number of numbered regions in fixed topology, with the Burleigh Expires May 2025 [Page 4] Internet-Draft Bundle Protocol Regions November 2024 proviso that any region may be empty, i.e., may have no corresponding contact plan. That is, instead of composing the region topology dynamically by forming regions only when contact plans are managed, we declare a pre-existing static topology comprising regions with which contact plans may later be dynamically associated. In this concept, the regions exist independently of the contact plans. Abstract topological adjacency between regions is likewise fixed. Regions may be populated with contact plans without limit over time; functional interconnection between populated regions is then instantiated by contact plan management, establishing the passageways between topologically adjacent regions. Since the region topology is fixed, the numbers by which regions are identified may function as addresses, i.e., they may simply identify locations within the topology. This means that, for a given node, the identifying number of the region that is populated by the contact plan in which the node is cited may serve as the coarse-grained address of that node. Unlike node identifiers, which have at best organizational significance, nodes' region numbers would have topological significance. A node's region number would be expected to be stable throughout the forwarding of bundles from source region to destination region, because only the removal of the node from its contact plan - an administrative change rather than mere relocation due to a change in connectivity - could invalidate that coarse- grained address. The fixed, universally understood region topology, together with knowledge of the regions in which nodes reside, would therefore constitute sufficient information for computation of a route from any node in the network to any other node. The algorithm for computing such a route will depend on the nature of the region topology knowledge. Since the region numbers function as addresses, a hierarchical numbering of regions - for example, a tree structure - may enable address aggregation, much as in Internet addressing. So the following scheme is proposed: . The root region of the tree (i.e., of the region grid) is numbered zero. . Every region has exactly 8 topologically adjacent "child" branch regions. The number of each such region is the number Burleigh Expires May 2025 [Page 5] Internet-Draft Bundle Protocol Regions November 2024 of the parent region (with leading zero suppressed) followed by a number from 1 to 8. For example: . The regions branching off from the root region are numbered 1- 8. . The regions branching off from region 2 are numbered 21, 22, 23, 24, 25, 26, 27, 28. . The regions branching off from region 8932 are numbered 89321, 89322, etc. With this structure in place, forwarding a bundle from one region to another is straightforward: . We forward the bundle "outward" to a child branch region if the number of the forwarding region is a prefix of the number of the destination region. For example, if a bundle is being forwarded from a node in region 921 and the destination is a node in region 92186, then the node should forward the bundle to daughter branch region 9218; a node in that region will forward it directly to the destination region. . Otherwise we forward the bundle "inward" to the parent region. For example, if the bundle is being forwarded from a node in region 921 and the destination is a node in region 9245, then the node should forward the bundle to region 92; a node in region 92 will forward the bundle to region 924, which in turn will forward to region 9245. This scheme relies on knowing the identifying number of the region in whose contact plan the destination node is cited. This may be known: . By the flooding/response discovery mechanism originally prototyped for IRF. . Administratively, by assertion, just as IP addresses may simply be asserted. . By looking up the node ID in a directory. A directory mapping nodes' identifiers to the regions in which they reside would be similar to DNS but would be easier to synchronize across a DTN-based network. It is true that some or all of the nodes cited in a given contact plan might be removed from that Burleigh Expires May 2025 [Page 6] Internet-Draft Bundle Protocol Regions November 2024 contact plan and inserted into another, resulting in changes to the affected nodes' regions of residence. But such migrations should be infrequent as they would reflect substantial administrative changes by network operators that would incur other costs. Notionally, the incidence of those changes should be low because the original region occupied by a given contact plan may be chosen somewhat freely. The regions selected for the contact plans administered by a single organization: . Must be unoccupied. . Will preferably be richly interconnected. . May be selected to minimize the number of region interconnections that must be frequently traversed by bundles exchanged with other clusters of regions. This exercise would be a strategic planning problem that might lend itself to algorithmic optimization but is beyond the scope of this document. 5. Closing thoughts Implementation of this concept might not be expensive: . Establishing the grid of abstract numbered regions would require little effort: a central directory of regions, noting which ones are occupied, is needed and must be managed. . All that a network operator need do is select the regions to populate with its contact plans and advertise the numbers of the regions in which the operator's nodes reside. A minor extension to BP would remove any need for routers to retain any information at all about downstream destinations. The source node would simply attach to the bundle an extension block noting the number of the region in which the destination node resides, much as a postal envelope bears both the name and address of the destination. Modification of BP implementations would likewise be minor: computation of the region-space route to the region in which a destination node resides is trivial. Finally, the hierarchical nature of routing among regions excludes routing loops (outside of a given contact plan), while at the same time enabling the BP network to scale up without limit. Burleigh Expires May 2025 [Page 7] Internet-Draft Bundle Protocol Regions November 2024 6. Security Considerations Corruption of the destination region extension block would result in the mis-routing of bundles, a denial of service attack. One possible mitigation would be inclusion of that extension block in the list of targets of the BPSEC [RFC9172] Block Integrity Block protecting the bundle's primary block. 7. IANA Considerations No IANA action is proposed in this paper. 8. References 8.1. Normative References Not applicable. 8.2. Informative References [ALESSI] Alessi, Nicola, "Hierarchical Inter-Regional Routing Algorithm for Interplanetary Networks", Master's thesis, Alma Mater Studiorum - University of Bologna, 2019. [MADOERY] Madoery, Pablo G., et al, "Managing Routing Scalability in Space DTNs", in 6th IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE), 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC4838] Cerf, V., et al, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC9171] Burleigh, S., E. Birrane, and K. Fall, "Bundle Protocol Version 7", RFC 9171, January 2022. [RFC9172] Birrane, E., and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, January 2022. [SABR] Consultative Committee for Space Data Systems, "Schedule- Aware Bundle Routing", Recommended Standard CCSDS 734.3-B-1, July 2019. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Burleigh Expires May 2025 [Page 8] Internet-Draft Bundle Protocol Regions November 2024 Authors' Address Scott Burleigh IPNGROUP 1435 Woodhurst Blvd. McLean, VA 22102 United States of America Email: sburleig.sb@gmail.com Burleigh Expires May 2025 [Page 9]