Bundle Protocol Regions for Network Scaling
draft-burleigh-regions-00

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]