| Internet-Draft | BP SAND | October 2026 |
| Sipos & Deaton | Expires 12 April 2027 | [Page] |
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). This protocol defines a general-purpose advertisement mechanism with an initial set of message and data types able to be advertised by participating nodes in a BPv7 network. The focus of this document is for advertisement to topological neighbors about local neighborhoods but can be expanded upon in the future through extension points.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 12 April 2027.¶
Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Deployments of Bundle Protocol version 7 (BPv7) nodes have required a significant amount of configuration for both the node being enrolled in the BPv7 network as well as the pre-existing (one-hop neighbor) nodes expected to communicate with the new node. The configuration consists of both BP-layer parameters, such as identity and security capabilities, as well as underlying convergence layer (CL) and associated transport parameters.¶
When nodes are in the same administrative domain, these parameters might be easy to find and the burden is solely about configuring the nodes. But when nodes need to configure across administrative domains simply finding the parameters could be an operational challenge, and if the parameters change keeping them synchronized is yet more complexity. Administrative domains might be crossed at the boundary between organizations (e.g., when bridging two BP wide-area networks) but they can also be crossed within a single host or platform where there are nodes from different vendors present which need to interoperate.¶
Additional considerations for discovery within a BP network are related to the expectation of challenged nature of a delay-tolerant network (DTN) more generally. This means long one-way light-time (OWLT) delays between neighbors, expected time-varying discontinuities between neighbors, and a variety of CL transport types, each with associated parameters, capabilities, and limitations. More detailed descriptions of the challenges of DTNs can be found in "Delay-Tolerant Network Architecture" [RFC4838].¶
Earlier research into discovery within a BP network led to development of the draft experimental "IP Neighbor Discovery" protocol [I-D.irtf-dtnrg-ipnd], but that protocol is intimately tied to its use of UDP datagram "beacons" and necessary use of an Internet Protocol (IP) underlay network. It also would require allocation of well-known UDP port number and IP multicast addresses or pre-configuration of those parameters across network nodes, but no such allocations were ever made.¶
To mitigate the need for manual parameter discovery and configuration, an online neighborhood discovery protocol can be used, and such a protocol is defined in this document. The Secure Advertisement and Neighborhood Discovery (SAND) protocol operates at and above the BP-layer, as shown in Figure 1, which insulates it from strict dependence on any specific CL for its message transport and allows the use of Bundle Protocol Security (BPSec) for message security. The full protocol stack of this document uses the UDP Convergence Layer (UDPCL) version 2 [I-D.ietf-dtn-udpcl] as a zero-configuration default (Section 4.6) for its any-source multicast (ASM) capability but SAND could be, and is expected to be, used over other CL types (to include unicast transports, see Section 2.1) which might be informed by lower-layer discovery protocols (see Section 2.4).¶
+-------------------------+ | Secure Discovery (SAND) | -\ +-------------------------| | | BPv7 + BPSec | -> Application Layer +-------------------------+ | | CL + opt. security | -/ +-------------------------+ | TCP/UDP/etc. | ---> Transport Layer +-------------------------+ | IPv4/IPv6 + ASM | ---> Network Layer +-------------------------+ | Link-Layer Protocol | ---> Link Layer +-------------------------+
The separation of SAND from its transport is illustrated more clearly in Figure 2, where the SAND entities communicate to each other via SAND PDUs, their transport supported by BP Agents communicating via BP PDUs, and farther under that specific pairings or groupings (depending on unicast or multicast transport) of CL Adaptors communicating by various PDUs, themselves supported by specific underlayer network (ULN) technologies.¶
+---------------+ +---------------+
| Node | ... | Node |
| | | |
| +-----------+ | | +-----------+ |
Control | |SAND Entity|<=======>|SAND Entity| |
Plane | +-----------+ | | +-----------+ |
~~~~~~~~|~~~~~~~~~~~~~~~|~~~~~|~~~~~~~~~~~~~~~|~~~~
Data | +-----------+ | | +-----------+ |
Plane | | BP Agent |<=======>| BP Agent | |
| +-----------+ | | +-----------+ |
| +-----------+ | | +-----------+ |
| |CL Adaptors|<=======>|CL Adaptors| |
| +-----------+ | | +-----------+ |
| +-----------+ | | +-----------+ |
| |ULN Endpts.|<=======>|ULN Endpts.| |
| +-----------+ | | +-----------+ |
+---------------+ +---------------+
This document describes the format of the protocol data units passed between BP nodes for neighborhood discovery and defines behavior at message source and destination nodes. This document is specifically limited to one-hop messaging between neighbors and reserves any discussion of multi-hop advertisement with forwarded messages to later specifications.¶
This document does not address:¶
This section explains use cases for which the SAND protocol defined in this document serves as a supporting role. Other use cases might be supported by or enhanced by SAND and are left to other documents to explain.¶
This case is the simplest to explain, to discover enough information about BP neighbors to forward to them and receive from them without any prior in-band configuration needed. It relies on a critical assumption about its operating environment: that nodes are listening on multicast group destinations for one or more default convergence layer (see Section 4.6) which is reachable from each advertising node through some shared medium.¶
Given that assumption, any SAND participant can (periodically or based on link status events, see Section 7.4) advertise itself to and/or solicit from potential neighbors using the well-known BP group destination (Section 9.1) and the lower-layer multicast group. There is no guarantee that any other lower-layer multicast group members exist, happen to be listening at, or are in fact reachable at any specific time.¶
This case is when another, lower-layer discovery mechanism (see Section 2.4) has prompted the node that some lower-layer neighbor exists and is reachable. Information about that lower-layer neighbor is then used by the SAND participant to advertise itself to and/or solicit from the potential new neighbor using the well-known BP group destination (Section 9.1) and the lower-layer unicast destination address. There is no guarantee that just because a lower-layer neighbor exists that it will also be a SAND participant.¶
Once a SAND participant BP neighbor is known to exist (with specific compatible CL instances), there is both operational and diagnostic value in verifying reachability to and from that neighbor regardless of the presence (or absence) of other BP traffic with that neighbor. Each node can periodically send Local Topology Advertisement messages to known neighbors that contain at least the SAND singleton EID for the neighbor itself. The message itself conveys reachability to the neighbor and the presence of the neighbor within the message conveys near-past reachability from that neighbor. This BP-layer information can be combined with lower-layer mechanisms for reachability or link metrics discovery to drive routing decisions on a node.¶
As the title of this document implies, one of the most complex use cases of this protocol is to discover the topology of the local 2-hop neighborhood. This is an extension of the simple reachability discovery case where each advertising node includes all known 1-hop neighbors in its Local Topology Advertisement so that each neighbor is made aware of each other within the 2-hop neighborhood. The means by which these advertisements are transported (either as group destinations in BP and underlayer or singleton/unicast destinations) is an implementation choice based on the availability of multicast in the underlayer(s) and any need for context-specific filtering (Section 7.3) of the data.¶
A secondary use case of this protocol is to allow an advertising node to distribute arbitrary credentials to other participating nodes. This enables capabilities such as using short-term auto-renewed (STAR) signing certificates with the BPSec COSE Context [I-D.ietf-dtn-bpsec-cose] without requiring each BIB on every bundle to contain a copy of the certificate chain. Other BP-based applications could also make use of credentials discovered via SAND, but such uses are left to other specifications.¶
While applications are free to use their own payload structures with BP non-singleton destinations, this protocol provides extensibility (Section 2.3) of both message types and data parameters which can enable an implementation to maintain, advertise, and discover application-specific data. The benefit to the application in this case would be that it interacts with the information bases of the local SAND entity rather than need to deal with messaging and transport logic (Section 4) provided by SAND.¶
This document defines CBOR structure using the Concise Data Definition Language (CDDL) [RFC8610]. The entire CDDL structure can be extracted from the XML version of this document using the XPath expression:¶
'//sourcecode[@type="cddl"]'¶
The following initial fragment defines the top-level rules of this document's CDDL.¶
start = sand-adu-seq / sand-msg¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document re-uses the following terms from IETF network topology model [RFC8345].¶
Additional terminology used within the SAND protocol includes the following.¶
The service of this protocol is the discovery of security credentials and capabilities of peer nodes within a 2-hop neighborhood without needing any pre-configuration on the participating node or on other nodes in the network.¶
Each participating node uses per-underlayer and per-neighbor timers to determine when to solicit and when to advertise data. Some external events (e.g. network- or link-layer discovery) can be used to reset timers so that discovery can be completed more quickly (see Section 7.4).¶
The types of data able to be advertised by a node are the following, each associated with a subsection defining its message type and structure. Each type of data can be associated with a desired update time interval to ensure timely synchronization between peers.¶
The protocol defined in this document depends on BPv7 and BPSec for its transport (see Section 4) and is otherwise only loosely coupled to underlying protocols of its data plane (see Figure 2). Because of this, the SAND protocol can be used by participating nodes operating convergence layers which are based on IP technology, Ethernet (or equivalently-framed) media access control (MAC) technology, Consultative Committee for Space Data Systems (CCSDS) space data link protocol (SDLP) technology, or any other arbitrary protocol layering.¶
This technology independence applies not only to the data plane used to transport SAND PDUs, but also how ULN technologies and related CL instances are advertised to peers. This document registers code points for well-known ULN parameters, CL types, and CL parameters corresponding to IP-based, MAC-based, and SDLP-based data planes. Beyond this, arbitrary protocol layering can be identified by either future registrations or by private-use code points.¶
Because of its neutrality, some of the general-purpose information base and parameter definitions require each ULN technology or CL type to define how the general parameter relates to its specific technology. For example, the CL roles defined in this document (see Section 5.4.1) are "initiator" and "responder". The definition of an initiator role is CL-specific but is expected to involve initiating outgoing protocol conversations/connections/sessions, while a responder role is expected to involve listening for and responding to incoming ones.¶
Although the SAND transport is neutral about underlayer technologies, there are aspects of SAND which need to have well-defined relationships to entities and terminology of specific technologies. This includes how SAND information bases (Section 3) are constructed from the advertising node internal state and how SAND message data (Section 5) are interpreted by other participating nodes.¶
When applied to IP underlayer technology [RFC8200] [RFC8344], each TP corresponds with an IP "interface" and TP parameters are interpreted as applying to that single interface. Each CL instance under such a TP represents how transport layers (and above) in the IP architecture bind to that interface. In the IP architecture, addresses are assigned to the interface as a "zone" and transports bind to those addresses (and optionally zones). Because zone identifiers are internal to a node, there is no strict relationship in SAND between an advertising node's (internal) zone identifiers and TP Index values in ULN Advertisement messages.¶
When applied to CCSDS SDLP technology [CCSDS-SDLP], each TP corresponds with the local endpoint of a physical channel and TP parameters are interpreted as applying to that channel. Each CL instance under such a TP corresponds with a "service access point" of a single data link service on that channel. In the SDLP architecture, identifiers are assigned to entire nodes (a "spacecraft" or a "ground system") rather than specific channels, so when all parameters are otherwise equal multiple distinct channels can be coalesced into one TP in ULN Advertisement messages. There can be operational convenience to keeping distinct TP Index values for physical channels, so any coalescing is optional.¶
Because this protocol is meant to be used for zero-configuration discovery, there are several cases where identifiers used in SAND messages need to be interpreted without additional context and cannot rely on vague interpretation by participating entities. These are explained below, with detailed definitions later in Section 3 and Section 5.¶
The point of including CL instances (Section 5.4) from an advertising node is to allow other participating nodes to be able to use those instances to forward bundles to the advertising node without additional configuration. Because of this, the definition of each CL Type within SAND needs to extend from just below the BP PDU (and BP Agent behavior) all the way down to whatever portions of the underlying protocol stack (and protocol entity behavior) are needed to unambiguously transfer BP PDUs to the advertising node.¶
This is why LTP alone cannot be the bottom of a fully specified CL Type. It does not have its own mechanism of either discovering a mapping from LTP Engine ID to its segment transport protocols (and their parameters) or for a sending LTP engine to be able to positively identify its own segment transport endpoint for receiving report segments. More details are explained in Appendix A.¶
Endpoints in an underlayer network translate into TP instances (Section 5.3) from an advertising node. Because advertisements need to be interpreted from the point of view of another participating node, the ULN names and/or addresses being advertised must be somehow reachable by a neighbor node to be useful.¶
For the case of IP technology, this means that link-local addressing is meaningful only in cases where there is an expectation that participating nodes will also have an address under the same prefix and there is reachability to the advertising node. Additionally, using IP as the "bottom" of a fully specified CL type (Section 2.2.1) assumes that there is some other mechanism by which the participating nodes ensure IP reachability (e.g., the IPv4 Address Resolution Protocol [RFC826] or IPv6 Neighbor Discovery Protocol [RFC4861]). There is an expectation that routeable IP prefixes and addresses will be properly assigned by relevant internet numbering authorities [RFC7020] so that their uses do not collide across ULNs.¶
In the case of SDLP technology, each protocol uses a spacecraft identifier (SCID) to identify either the sending or receiving node, rather than a specific (physical or logical) channel terminating at that node. The SCID identifies the receiving node in Earth-to-space "forward" modes and the sending node in space-to-Earth "return" modes, as explained in Section 2.2 of [CCSDS-SDLP]. The determination of which SCID to use for inter-satellite links or more complex cases is mission-specific. Is there a good reference for conventions here? The use of more fine grained "virtual channel" identifiers allows differentiation of frames within a data link instance (similar to IP differentiated services [RFC2474]) but these identifiers are not meant to have well-known meaning outside of that individual instance. A node is free to re-use virtual channel identifiers for entirely different purposes when communicating with different neighbors or even over different links with the same neighbors.¶
Future specifications can use this same messaging and transport mechanism to define additional message modes, types, and data content including types for private or experimental use.¶
This document specifies only the use of SAND for one-hop advertisement over either a unicast or multicast convergence layer. Future specifications could extend this to define multi-hop flooding of SAND Bundles in order to distribute data more widely for link-state-style routing algorithms.¶
Altering the transport profile can be done without changing the SAND PDU or message structure of Section 5, and would allow re-using much of the logic defined in Section 4.¶
The set of SAND message types (as integer code points) is defined in an IANA registry in Section 9.3.1. This allows for future specifications to add new message types as well as reserving blocks of code points for private use and experimental use. New message types could be used for BP-node-related discovery, BP-routing-related discovery, or even application data discovery facilitated by SAND.¶
The set of message metadata parameters (as integer map keys) is defined in individual IANA registries in Section 9.3.2. This allows future specifications to augment message semantics if necessary.¶
The set of message-type-specific data parameters (as integer map keys) is defined in an IANA registry in Section 9.3.2. This allows future specifications to expand the envelope of technologies supported by SAND without needing a change in message structure or semantics.¶
For example, a non-IP-based CL type can define new parameters (either IANA-registered or within a private-use block) to express other address families. As another example, a specific implementation can augment existing CL-type-specific parameters (negative keys) without needing to define a new CL type code point, so there is a backward compatibility with implementations that do not support the new parameters.¶
There are specific message data parameters which define and use an IANA registry for extensible values. In this document, these parameters are the CL Type (Table 20) within the CL Advertisement message (Section 5.4), and the Routing Type (Table 24) within the Local Topology Advertisement message (Section 5.5). Both of these parameters allow additional type-specific parameters to be used and reserve blocks of value code space for private use and experimental use.¶
Many of the structural, behavioral, and especially timing definitions in this specification follow the model of MANET messaging [RFC5444] and MANET NHDP [RFC6130] in both terminology and semantics. This is intentional to allow an implementer to understand BP discovery with very similar logic to MANET discovery. Where the NHDP is concerned with IP routers discovering reachable IP neighbors and routes, SAND is concerned with BP nodes discovering reachable BP neighbors and routes.¶
A node participating in the SAND protocol is expected to use lower-layer discovery mechanisms as necessary to enroll in a local network, obtain network-layer address(es) and parameters, and possibly discover network-layer neighbor nodes and routers. This might involve the use of IPv4 Internet Router Discovery Protocol (IRDP) [RFC1256] or IPv6 Secure Neighbor Discovery Protocol (SEND) [RFC3971] [RFC4861] to determine IP neighbors, the Dynamic Host Configuration Protocol (DHCP) [RFC2131] [RFC8415] to assign addresses and network-level parameters, or the Dynamic Link Exchange Protocol (DLEP) [RFC8175] to discover connectivity and specific IP neighbor nodes.¶
The robust and delay-tolerant protocol in this document is also compatible with the DNS-Based Service Discovery (DNS-SD) of BP routers by edge nodes [I-D.sipos-dtn-edge-zeroconf]. The SAND protocol can be used to enroll an edge router in a BP network and synchronize routing information across a variety of network and link types, while DNS-SD is used within IP stub underlay networks (or enclaves) at the edges of the BP network for simpler and more synchronous edge nodes.¶
SAND operates by each participating node keeping a persistent store of its enrolled underlayer networks, 1-hop neighbors, symmetric 2-hop neighbors along with attributes for each type of entity. These are used as the basis for outgoing SAND message contents and are updated as part of message reception processing.¶
The discussion in this section is in support of interoperable SAND implementations by providing a conceptual information model [RFC3444] which is abstracted from implementation details about how data conforming to the information model is actually structured, maintained, stored, accessed, etc. This information model is not normative for a SAND entity, and where there are normative statements in this section they are all related somehow to observable protocol behavior.¶
There are also relationships between this information model and the extensibility discussed in Section 2.3 which are left as an implementation matter to resolve. The information model presented here applies only to the base protocol defined in this document with hints about where extensibility might affect this model or the more concrete data model of an implementation.¶
This category of information is based on a participating node's knowledge of its own ULN and PKI configuration. It exists as input to SAND processing and messaging and is unaffected by the results of processing or reception of messages.¶
The ULN information described in Table 1 allows a participating node to define different profiles for different networks (IP or otherwise) accessible by the node through local termination points. As defined in Section 6, when assembling and sending SAND messages much of the data can be filtered-down based on what is accessible via a termination point associated with the network-layer source of a SAND message (among other possible additional filtering, see Section 8.1).¶
| Name | Description |
|---|---|
| Termination Point Index | This is a locally-unique numeric identifier for a network interface or equivalent termination point. Whether or not this index corresponds in some way to other identifiers is an implementation matter and does not affect this protocol. |
| Properties below are based on the above unique key columns. | |
| Accessible Network Set | This is the set of ULN names and addresses assigned to the termination point and associated subnetworks accessible to this node via the termination point. For IP underlayers, these are respectively DNS names, IP addresses, and CIDR-form of subnetwork definitions conforming to BCP 122 [RFC4632]. |
| Link MTU | This is the configured or discovered maximum transmission unit (MTU) of the first-hop network link for the underlayer. Because this is a link MTU it excludes any network packet header overhead and is network-protocol-independent. This also represents a maximum outgoing size and not necessarily the maximum incoming size. This is not necessarily the same as a path MTU between any peers on this network, and a path MTU can be directional. |
| ULN Labels | This is the set of (integer-valued) labels associated with this TP instance. The label "This Instance" is dynamically applied during message construction and will not appear in this table. |
| SAND Timer Configuration | This is the set of timers needed to configure SAND activities, as defined in Table 2. |
The items in Table 2 represent the set of timer configuration needed to operate a participating node. As an information model, details such as specific units or encoding forms are left as an implementation matter. Because SAND uses the DTN time epoch and encoded form, SAND timer configuration SHOULD have a resolution down to at least one millisecond.¶
| Name | Scope | Description |
|---|---|---|
| Minimum Time Interval | default and per-message-type | This represents the shortest time interval between sending messages of the same type on a particular ULN or to a specific singleton destination. |
| Maximum Time Interval | default and per-message-type | This represents the longest time interval between sending messages of the same type on a particular ULN or to a specific singleton destination. This is used as a timeout for Periodic Update messaging. The Maximum Time Interval MUST be longer than the Minimum Time Interval by some factor. |
| Validity Duration | default and per-message-type | This is embedded in messages optionally and used for SAND Bundle lifetimes. The Validity Duration MUST be longer than the Maximum Time Interval by some factor. |
The Identity information of Table 3 is a logical table used both as a source for sending Credential Advertisement messages as well as for deriving BPSec policy used to send signed payloads and/or receive encrypted payloads.¶
| Name | Description |
|---|---|
| Encoded Certificate | This is the DER-encoded X.509 certificate contents. |
| Properties below are based on the above unique key columns. | |
| Thumbnails | These are thumbnails of the encoded certificate compatible with x5t, used as a selector. The algorithm SHA-256 (-16) is the interoperable minimum to support [RFC9360]. |
| Key Usage | This is the extracted Key Usage value, from Section 4.2.1.3 of [RFC5280], used as a selector. |
| Validity Time Interval | This is the extracted Validity interval, from Section 4.1.2.5 of [RFC5280], used as a selector. |
The trust anchor information of Table 4 is a logical table used for validating received peer certificates and for deriving BPSec policy used to receive signed payloads.¶
| Name | Description |
|---|---|
| Encoded Certificate | This is the DER-encoded X.509 certificate contents. |
| Properties below are based on the above unique key columns. | |
| Subject Key Identifier | This is the extracted Subject Key Identifier, from Section 4.2.1.2 of [RFC5280], used as a selector. |
| Validity Time Interval | This is the extracted Validity interval, from Section 4.1.2.5 of [RFC5280], used as a selector. |
The convergence layer information of Table 5 is a logical table separated from the network information of Table 1 because many BP node deployments are expected to have CL instances that are bound to "any endpoint" addresses and can operate across multiple networks. Even in cases where a CL establishes persistent sessions which might be bound to a specific endpoint address or network, the CL instance as a whole can operate simultaneous sessions across many networks.¶
When used as a source for sending Convergence Layer (CL) Advertisement messages the advertised CL List is expected to be, but not required to be, filtered-down based on the termination point and/or network on which the message will be sent. Besides being filtered-out for a specific network, a CL instance SHALL NOT be represented differently across different termination points.¶
The effective removal of a CL instance is to store and advertise the same combination of CL Type and Termination Point Index but include no Bind Addresses or other parameters. This will cause the CL instance to no longer be associated with its previous parameters and thus unusable by neighbors.¶
| Name | Description |
|---|---|
| CL Type | This is the type of CL being represented, which need not be unique when there are multiple instances of a CL operating on a single node (with different parameters presumably). |
| Termination Point Index | An index which corresponds to one of the underlayer network entries of Table 1 and distinguishes different instances of a CL type. |
| Properties below are based on the above unique key columns. | |
| Bind IP Addresses | This is the set of IP addresses to which the CL instance is bound (for either listening/receiving or connecting/sending). This includes both IPv4 and IPv6 addresses, and can include the "any endpoint" IPv4 and IPv6 addresses (0.0.0.0 and :: respectively). |
| Bind Port Number | This is the specific transport-layer port number to which the CL instance is bound. This includes the default port number for each CL type. |
| Transport Security | This indicates whether transport security is required, prohibited, or neither (meaning it can be opportunistic or conditional) by the CL instance. |
| Roles | This indicates the logical roles which this CL instance is able to perform among "initiator" or "responder" options. A single CL instance can be capable of both roles. |
| Type-Specific Parameters... | Each CL type (see Section 5.4) able to be represented by SAND can have a set of parameters specific to that type. |
An information base for 1-hop neighbor existence and intrinsic properties is managed separately from other information bases which represent relationships between nodes. Neighbor information can be received from any number of ULNs and is aggregated together into these information bases. In some cases the original received termination point properties are significant and kept, and in others they are discarded in order to have a single record representing the entire neighbor node separate from its ULNs.¶
The neighbor node information of Table 6 is a logical table of immediate neighbors of this node. Multiple sources of information are aggregated together into this table.¶
| Name | Description |
|---|---|
| Node ID | This is the SAND Singleton EID for the node. |
An information base for 1-hop neighbor reachability in Table 7 is a logical table relating 1-hop neighbor nodes from Table 6 to a specific ULN termination point from Table 1 on which the node is reachable or on which messages have been received. Due to having multiple-network connectivity, it is possible to have multiple records identifying the same 1-hop Neighbor but each will have their own set of path metrics for a specific network.¶
| Name | Description |
|---|---|
| Local Termination Point Index | This is a cross-reference to the unique index from Table 1, the local termination point which has seen messages from the node. |
| Neighbor Node ID | This is a cross-reference to the unique identifier from Table 6. |
| Neighbor Termination Point Index | This is the neighbor-provided index for its termination point corresponding to this record. |
| Properties below are based on the above unique key columns. | |
| Latest Timestamps | This is the latest bundle creation timestamp (Section 4.2.7 of [RFC9171]) for each SAND Message Type (Section 9.3.1) received from the neighbor on this termination point, which is used to filter-out old, out-of-order messages in Section 4.5. |
| Timeout | This is the absolute local-clock time when this record becomes invalid. |
| Reachability | An indication of whether this neighbor has been only received from (HEARD), or if this node is present in that neighbor's own 1-hop neighbor list (SYMMETRIC), or if no messages have been received after some time (LOST). |
| Properties below are received directly from the advertising node. | |
| DNS Name Set | This is the set of DNS Names assigned to the neighbor node and accessible on the associated ULN. |
| IP Address Set | This is the set of IP addresses assigned to the neighbor node and accessible on the associated ULN. |
| Link MTU | This is the configured or discovered MTU of the first-hop link for the neighbor on the associated ULN. Similar to the local interface Link MTU, the actual Path MTU to and from this peer might be reduced from any one-hop Link MTU and might be directional. |
| ULN Labels | This is the set of (integer-valued) labels associated with this instance. The same neighbor TP Index can have different labels if it appears in records with different local TP Index. |
| Routing Metrics | This is the set of routing metrics for expected path delay, maximum data rate, and bit error rate in each direction between the two termination points. |
| Name | Description |
|---|---|
| Local Termination Point Index | This is a cross-reference to the unique index from Table 1, the local termination point which has seen messages from the node. |
| Neighbor Node ID | This is the SAND Singleton EID for the node. |
| Neighbor Termination Point Index | This is the neighbor-provided index for its termination point corresponding to this record. |
| CL Type | This is the type of CL being represented, which need not be unique when there are multiple instances of a CL operating on a neighbor node-and-ULN. |
| Properties below are based on the above unique key columns. | |
| CL Parameters | These are the transport and network parameters (see Table 5), as reported in Convergence Layer (CL) Advertisement messages. |
This category of information is about an individual node, or pairs of nodes, independent of the location of the node in the network topology relative to this node.¶
An information base for 2-hop neighbors is limited to only those which have symmetric reachability between that node and one of the 1-hop neighbors from Table 6. This information includes simplified path metrics between the 1-hop and 2-hop neighbors. Due to having multiple-network connectivity, it is possible to have multiple records identifying the same 2-hop Neighbor but each will have their own set of path metrics for a specific pair of termination points.¶
| Name | Description |
|---|---|
| Node ID | This is the SAND Singleton EID for the node. |
| Properties below are based on the above unique key columns. | |
| Latest Timestamps | This is the latest bundle creation timestamp (Section 4.2.7 of [RFC9171]) for each SAND Message Type (Section 9.3.1) received from the node, which is used to filter-out old, out-of-order messages in Section 4.5. |
The network information base does not include any CL information because that is only needed for reaching 1-hop neighbors. Only coarse routing metrics are needed between peer nodes outside of 1-hop neighbors.¶
| Name | Description |
|---|---|
| Left Node ID | This is a cross-reference to a unique identifier from Table 9. |
| Left Termination Point Index | This is the index for the termination point of the left node corresponding to this record. |
| Right Node ID | This is a cross-reference to a unique identifier from Table 9. |
| Right Termination Point Index | This is the index for the termination point of the right node corresponding to this record. |
| Properties below are based on the above unique key columns. | |
| Routing Metrics | This is the set of routing metrics between the left and right node. |
The Peer Certificate Information of Table 11 is used as a way to store and cache certificates received via Credential Advertisement messages and validated in a time-independent way.¶
This means that certificates SHALL only be considered for caching by a node unless they have been part of a chain validated in accordance with the procedures of Section 6 of [RFC5280], up to a root CA from the Trust Anchor information of Table 4, while ignoring validity times. In addition to the base validation, all end-entity certificates SHALL only be considered for caching by a node if it conforms to the certificate profile of Section 4 of [I-D.ietf-dtn-bpsec-cose]. The Peer Certificate Information SHALL be de-duplicated from the Trust Anchor information of Table 4 by ignoring root CA certificates.¶
| Name | Description |
|---|---|
| Node ID | This is the SAND Singleton EID for the node. |
| Encoded Certificate | This is the DER-encoded X.509 certificate contents. |
| Properties below are based on the above unique key columns. | |
| Thumbnails | These are thumbnails of the encoded certificate compatible with x5t, used as a selector. The algorithm SHA-256 (-16) is the interoperable minimum to support [RFC9360]. |
| Subject Key Identifier | This is the extracted Subject Key Identifier, from Section 4.2.1.2 of [RFC5280], used as a selector. |
| Key Usage | This is the extracted Key Usage value, from Section 4.2.1.3 of [RFC5280], used as a selector. |
| Validity Time Interval | This is the extracted Validity interval, from Section 4.1.2.5 of [RFC5280], used as a selector. |
The SAND relies on BPv7 for end-to-end transport, one or more CL for one-hop transport, and BPSec for message security (both end-to-end and one-hop).¶
Within BPv7, two types of well-known endpoint identifier (EID) are used as source and/or destination for bundles transported between SAND participants.¶
Beyond its necessary use as a bundle EID, the SAND Singleton EID also serves as a unique identifier for the participating node and a unique and stable correlator for the SAND information bases (Section 3).¶
For the remainder of this document a bundle with a source matching the SAND Singleton EID will be referred to as a SAND Bundle. A SAND Bundle will have a destination of either the SAND Group EID or another SAND Singleton EID. This is illustrated by the following text form EID Pattern [I-D.ietf-dtn-eid-pattern].¶
imc:TBA1.TBA2|ipn:*.*.TBA3¶
A SAND Bundle has the following basic characteristics:¶
bstr items, each containing an encoded SAND Message as defined in Section 5.¶
; The actual ADU is the sequence ~sand-adu-seq, not array enveloped
sand-adu-seq = [
version: 1,
+ adu-item
]
adu-item = bstr .cborseq sand-msg
¶
Each encoded SAND Message SHOULD use CBOR core deterministic encoding requirements from Section 4.2.1 of [RFC8949]. Each message in this ADU is bstr-wrapped and the Message Type item is the front of the encoded message, which allows a SAND processor to quickly determine if the specific message is of interest and skip over it if not.¶
Because multiple SAND Messages can be sent in a single bundle to which a Hop Limit applies, all messages in a single bundle need to have the same restriction (or non-restriction) of Hop Limit.¶
In order to properly handle a SAND Bundle, the previous-hop node needs to be positively identified. This occurs by using one of the following (in priority order):¶
A SAND Bundle which is forwarded over a CL which includes an authenticated identity SHOULD NOT contain a Previous Node extension block. Otherwise, a SAND Bundle which is forwarded from a node which is not its source SHALL contain a Previous Node extension block to indicate that the node sending it is not its source. This last requirement is more strict than Section 4.3.1 of [RFC9171] to ensure that the forwarding node identity can always be determined for a SAND bundle.¶
All SAND Bundles SHALL contain a Block Integrity Block (BIB) which targets the payload block. If that BIB does not include the primary block as additional authenticated data (AAD) then the BIB SHALL also target the primary block. The BIB MAY target any other blocks in the SAND Bundle.¶
The BIB targeting the payload block SHALL have a Security Source identifying the same node as the bundle Source EID.
Due to node and network security policy, the Security Source EID MAY be different than the bundle Source EID.
For example, a bundle source of ipn:974848.10.3 might have an associated Security Source of ipn:974848.10.0 but both identify the same IPN node.¶
Any SAND Bundles which contain a Previous Node block SHALL also contain a BIB which targets that Previous Node block. If that BIB does not include the primary block as additional authenticated data (AAD) then the BIB SHALL also target the primary block. The BIB MAY target any other blocks in the SAND Bundle. Similar to the payload, any BIB targeting the Previous Node block SHALL have a Security Source identifying the same node as the Previous Node block.¶
Any BIB used by SAND SHALL authenticate the bundle source EID and provide proof-of-possession (PoP) of the private key bound to the bundle source EID via PKIX certificate. This could be done using a cryptographic signature as available in the COSE Context [I-D.ietf-dtn-bpsec-cose] because the primary block Creation Timestamp functions as a unique nonce for PoP.¶
A SAND Bundle MAY contain a Block Confidentiality Block (BCB) which targets the payload block when being transported over an insecure CL to a known set of recipients. If the BCB acceptors are not using group keys or known individual-recipient keys, the SAND Bundle SHOULD NOT be transported over a multicast CL.¶
When BPSec blocks can contain either certificate contents or thumbprints, the use of thumbprints is RECOMMENDED along with the use of Credential Advertisement messages to convey full credentials between nodes. To avoid the bootstrapping issue described in Section 8.5, the requirements of that section need to be met by a participating node.¶
Like MANET discovery and routing protocols, all of the message types defined in this document contain the full set of data of a particular type from an advertising node. The processing of any one message does not rely on incremental changes caused by the message or processing of any preceding-in-time messages of the same type. This also makes SAND Message processing idempotent and immune to duplicate reception, which is an expected property of BPv7 transport.¶
Because of this, the reception of a message sent earlier than the last-received message of the same type from the same source can be completely ignored. This logic applies per-message-type so a single SAND Bundle can contain some messages which are superseded along with others which are not. This comparison logic below along with the BPv7 requirement of timestamp uniqueness provide a strict ordering of all bundles from a source.¶
After receiving and processing each SAND Message, a node SHALL record the Reference Time from the message (using the bundle Creation Timestamp as alternative) along with the bundle source and message type. After receiving but before fully processing each SAND Message, a node SHALL look up the latest processed Reference Time based on the bundle source and message type. If the received message is identical to or earlier than the latest processed timestamp it SHALL be ignored by the application. The timestamp comparison SHALL be based on ordering of the DTN Time followed by the Sequence Number. Ignoring a superseded message SHALL NOT be considered a failure of processing the message, its containing ADU, or its containing bundle.¶
Part of the ability of the SAND to be a discovery protocol is the need for initial authenticated messaging without any pre-configuration of any participating node. This is accomplished by using one or all of the following as needed on each ULN termination point:¶
There is also the possibility of using one of the CCSDS space data link protocols in a broadcast mode over a specific virtual channel, but there is no well-known virtual channel identifier (VCID) reserved by SANA for this purpose. All participating nodes would need to have prior agreement about which VCID to use for this service, so this strategy is not truly zero-configuration.¶
All SAND-participating nodes SHALL listen for UDPCL packets on default port 4556 (defined in Section 6.2 of [I-D.ietf-dtn-udpcl]) and by joining IP multicast group(s) defined in Section 6.1 of [I-D.ietf-dtn-udpcl] on all local termination points on which the entity has an IP address and over which the entity is participating in discovery. Nodes MAY listen for UDPCL packets destined for other (unicast) addresses and/or on other ports as needed.¶
When sending SAND Bundles over an IP-based ULN to a group destination (see Section 6), participating nodes will use this default UDPCL with an IP multicast configuration. Because a multicast destination is used, the advertising node MAY need to condition certain UDP and IP parameters based on a specific ULN termination point to send from. The means by which an entity does this is implementation specific.¶
To send bundles using the UDPCL on a specific local termination point:¶
If a specific destination IP address is given that SHALL be used as its destination.¶
Otherwise, use one or more of the following:¶
All SAND-participating nodes MAY listen for BTP-U messages on default ethertype by joining multicast group defined in Section 4.2.1 of [I-D.ek-dtn-ethernet] on all local termination points over which the entity is participating in discovery.¶
When sending SAND Bundles over an Ethernet-only ULN to a group destination (see Section 6), participating nodes will use this default BTPU-over-Ethernet with a MAC multicast configuration. Because a multicast destination is used, the advertising node MAY need to condition certain Ethernet parameters based on a specific ULN termination point to send from. The means by which an entity does this is implementation specific.¶
To send bundles using BTPU-over-Ethernet on a specific local termination point:¶
If a specific destination MAC address is given that SHALL be used as its destination.¶
Otherwise, if the termination point has an assigned Ethernet MAC address, a BTPU-over-Ethernet transfer SHALL be sent using the Ethernet multicast address for "All BP Nodes" as its destination.¶
A SAND Message is the top-level encoded structure exchanged between nodes. Messages are encoded according to the following general requirements, which match the CDDL in Figure 3.¶
A SAND Message SHALL consist of a CBOR sequence of the following:¶
int16 identifying the type of the message.
The registry of message types is IANA-managed and defined in Section 9.3.1.¶
sand-generic-map rule.
All keys in the metadata map SHALL be of type int16 identifying the purpose of each map value.
The registry of metadata parameters is IANA-managed and defined in Section 9.3.2.¶
sand-generic-map rule.
All keys in a message data map SHALL be of type int16 identifying the purpose of each associated map value.
Together each map key and value are referred to as a "parameter" in this document.
Each message type definition must include details about the parameters in its associated data map, including what each map represents and which parameters are required to be present in a map.¶
sand-msg = $sand-msg .within sand-msg-structure
sand-msg-structure = [
sand-msg-type,
; Metadata about this message
msg-meta: sand-generic-map,
; One or more map containing type-specific parameters
+ msg-data: sand-generic-map
]
sand-msg-type = int16
sand-generic-map = {
* sand-label => sand-value,
}
; Generic map label
sand-label = int16
; Generic map value
sand-value = any
; Signed integer that fits in 16-bit two's complement form
int16 = (-32768 .. 32767) .within int
; Negative part of int16 for private values
priv16 = -32768 .. -1
The initial message metadata are listed below and correspond with the CDDL of Figure 4.¶
This pair uses key 2 and value type dtn-time indicating the absolute time of the start of validity of this message in the DTN time epoch (see Section 4.2.6 of [RFC9171]).
If no Reference Time is present, the message SHALL be treated as being valid from the containing bundle's Creation Timestamp.
The Reference Time is also used as the epoch for any schedule structure in the same message, defined later in this section.¶
For nodes with low-fidelity timing needs or having a low-precision clock this value SHOULD be omitted. Otherwise, this value SHALL be present to avoid any difference between message creation time and the BPA-sourced Creation Timestamp.¶
This pair uses key 3 and value type time-duration indicating the validity-time of the message contents in milliseconds.
If no Validity Duration is present, the message SHALL be treated as being valid through the containing bundle's Lifetime.
The Validity Duration SHALL be interpreted as starting at the Reference Time from the same message, if present, or the bundle's creation timestamp.¶
For nodes with low-fidelity timing needs this value SHOULD be omitted. Otherwise, this value SHALL be sourced from the Validity Duration of Table 2.¶
time-duration indicating the periodic interval of the message type in milliseconds.
If no Repetition Interval is present, the message SHALL NOT be assumed to be sent at a fixed periodic interval.¶
; CDDL generic for a specific message type
; The type-id is from "SAND Message Types" registry
; The data-map defines type-specific labels
sand-msg-gen<type-id, data-map> = [
msg-type: type-id
msg-meta: {
* $$msg-meta-grp,
* priv16 => any
},
+ msg-data: data-map
]
$$msg-meta-grp //= (
2: dtn-time,
)
$$msg-meta-grp //= (
3: time-duration,
)
$$msg-meta-grp //= (
4: time-duration,
)
; Duration in DTN units of milliseconds
time-duration = uint
Some of the advertisements defined in this document associate an optional validity schedule with select data. Because the advertisements are expected to be sent by nodes periodically on the order of minutes, the form of this schedule is very simplified and focused only on a short-term time horizon using the Reference Time of the same message as its zero-offset epoch. When any schedule is present within a message the Schedule Reference Time item SHALL be present in the message and used as the schedule epoch time.¶
The schedule consists of pairs of duration values, with each pair representing an interval of time during which the schedule applies (and the gaps between intervals representing time during which the schedule does not apply).¶
schedule = [+ schedule-interval-pair] schedule-interval-pair = ( offset: time-duration, length: time-duration .gt 0, )
The Data Solicitation message type informs recipients that the sender desires specific types of SAND data from its peers. A peer entering a network SHOULD send a Data Solicitation message after an implementation defined time delay.¶
The Data Solicitation message SHALL be identified by message type 1. Each message with this type SHALL contain a single data map. The message data pairs are listed below and correspond with the CDDL of Figure 6.¶
int16) values.
The Message Type List SHALL contain at least one item.
Each Message Type List item SHALL be unique (no duplication).
The order of items within the array SHALL NOT be treated as significant by the recipient.¶
Each Data Solicitation message SHALL contain a Message Type List. The Data Solicitation message SHALL NOT be used to request a Data Solicitation message type. Any solicitation of a Data Solicitation message type SHALL be ignored by the receiver.¶
$sand-msg /= sand-msg-gen<1, {+ $$solicit-grp }>
; Message type list
$$solicit-grp //= (
-1: [+ sand-msg-type]
)
The Credential Advertisement message contains identity-binding credentials which identify the advertising node and contain key material for different security purposes. Each credential is itself verifiable up to a trusted root which is assumed to be configured in receivers of the advertisement.¶
Credentials in this message are sourced from the Identity Information Base of Table 3. Each credential can contain validity time intervals which have no strict relationship to the validity time of the containing advertisement message or the lifetime of the containing bundle, and do not relate to any SAND-form of schedule. The creator of a Credential Advertisement message MAY filter-in or filter-out credentials based on their validity time.¶
Each message with this type SHOULD contain credentials valid at the time of creation. Each message with this type MAY contain credentials valid only in the past or future. Those non-present-time credentials could be needed to verify old signatures or to pre-load future rollover keys respectively.¶
The Credential Advertisement message SHALL be identified by message type 2. Each message with this type SHALL contain a single data map. TBD: one map per purpose? The message data pairs are listed below and correspond with the CDDL of Figure 7.¶
COSE_X509 for COSE [RFC9360] to convey PKIX certificates as an unordered "bag".
Each bag MAY contain multiple end-entity certificates identifying the advertising node with different validity time or different extension items.
Each bag SHOULD contain intermediate CA certificates up to, but not including, the root CA needed to verify all end-entity certificates.¶
Each Credential Advertisement SHALL contain at least one end-entity credential identifying the advertising node. A Credential Advertisement SHALL NOT contain any end-entity credential that does not identify the advertising node.¶
The Credential Advertisement message is populated using the data identified in Table 3, part of the Local Node Information Base described in Section 3.1.¶
$sand-msg /= sand-msg-gen<2, {+ $$cred-grp }>
; X509 Bag
$$cred-grp //= (
-1: COSE_X509 ; From [RFC 9360]
)
The ULN Advertisement message contains information about the ULN termination points, providing recipients information about communicating with the advertising node via the underlayer. Each ULN Advertisement message SHALL contain at least the termination point on which a SAND Bundle has been sent. Each ULN Advertisement message MAY contain any other termination points on the node. It is an implementation matter to choose which underlayer networks are advertised in a particular message.¶
Each ULN Advertisement message SHALL be transported with a Hop Limit of 1. Only 1-hop neighbors are capable of using underlayer network parameters so there is no need to forward this to any other nodes in the network.¶
The ULN Advertisement message SHALL be identified by message type 8. Each message with this type SHALL contain a separate data map for each ULN termination point being advertised. This message corresponds with the CDDL of Figure 8 and the following minimum instance parameters. These parameters are also in the IANA registry defined in Section 9.3.3.¶
uint.
This index uniquely identifies the termination point within the advertising node, and allows correlating changes to its properties across time.¶
$sand-msg /= sand-msg-gen<8, {+ $$uln-grp }>
; Termination Point Index
$$uln-grp //= (
0: uln-tp-ix-value
)
uln-tp-ix-value = uint
Each data map in this message SHALL have a unique Termination Point Index parameter. Each Termination Point Index value is arbitrary and SHALL NOT be used for any other purpose than correlating other SAND data from the same advertising node. An advertising node SHALL use each Termination Point Index consistently over time, using the same index across all messages to identify the same entity. An advertising node with only simple connectivity MAY use Termination Point Index zero as a default when only a single logical TP is needed.¶
Each termination point being advertised SHOULD be reachable via the ULN over which the enveloping message is sent. Advertising ULN termination points which are not reachable by receiving SAND participants is simply a waste of advertising resources and possibly by resources on other participants trying to determine reachability. An implementation could simplify its internal logic by advertising the same full set of termination points to all of its neighbors, regardless of reachability.¶
Each TP is expected to have varying parameter sets, with items corresponding to specific technology associated with the TP (see Section 2.1).¶
The general, technology-non-specific ULN parameters are listed below and correspond with the CDDL of Figure 9.¶
schedule as defined in Figure 5.
Each time at which the schedule is valid indicates when the termination point is expected to be usable for traffic to and from the ULN.
This corresponds to the TP-related schedule as described in Section 2.3.2 of [I-D.ietf-tvr-requirements].
If this parameter is absent the termination point SHALL be treated as always valid.¶
mtu-size indicating the link MTU, as seen by the termination point of the advertising node, in units of octets.
If this parameter is absent then other means of configuring or estimating link MTU are needed.
Even when present, the link MTU only sets an upper bound on the path MTU to the advertising node if a path traverses multiple links.¶
uln-label items.
Labels enable special filtering or processing of specific TP instances.
If this parameter is absent then the TP will not have any associated labels.
The registry of ULN Label code points is IANA-managed and defined in Section 9.3.3.¶
; Validity Schedule
$$uln-grp //= (
1: schedule,
)
; Link MTU
$$uln-grp //= (
4: mtu-size
)
mtu-size = uint .gt 0
; ULN Labels
$$uln-grp //= (
7: [+ uln-label]
)
uln-label = int16
When present, the Link MTU SHALL adhere to the lower limit of 68 octets for IPv4 [RFC791] or 1280 for IPv6 [RFC8200] when those technologies are used on the termination point. Other ULN technologies will still have an MTU value but with a different lower bound.¶
The set of available ULN Label code points is split between a range of well-known values and a range reserved for private and experimental use. This document defines a single ULN Label "This Instance" which is used to mark a single TP instance as being the one associated with the actual data plane over which the SAND Bundle was forwarded. The ULN Label "This Instance" SHALL NOT be present on more than one TP instance in a single message. The ULN Label "This Instance" SHOULD be present on one TP instance when the node has multiple, uniquely identifiable instances. The ULN Label "This Instance" SHALL be present on one TP instance in any message where there is ambiguity of which TP is associated with the message (e.g., when using link-local addresses, or use of any SDLP).¶
There are several common ULN parameters related to IP networks: a DNS name or IPv4/IPv6 address used to communicate with the node, and information common to links using that termination point.¶
The IP-related parameters are listed below and correspond with the CDDL of Figure 10.¶
tstr or array of tstr from DNS names in accordance with [RFC1034].
If this parameter is absent the node SHALL be treated as not having a DNS name on the ULN.¶
This pair uses key 3 and value type ip-addr-ctr from IPv4 or IPv6 addresses encoded as 4-byte or 16-byte strings respectively.
The encodings are consistent with the types ipv4-address and ipv6-address from Section 5 of [RFC9164]).
If this parameter is absent the node SHALL be treated as not having a specific IP address on the ULN.¶
This address list MAY contain link-local addresses if the sender has an expectation that CL instances (Section 5.4) will be usable over the associated IP endpoint.¶
mac-addr-ctr from EUI-48 or EUI-64 addresses encoded as 6-byte or 8-byte strings respectively.
The encodings are consistent with the unwrapped CBOR tag 48 from Section 2.4 of [RFC9542]).
If this parameter is absent the node SHALL be treated as not having a specific MAC address on the ULN.¶
mac-vlan-id holding a single 12-bit integer VLAN ID [IEEE-802.1Q].
If this parameter is absent the node SHALL be treated as not having a specific externally visible VLAN ID at the node interface.
Trunking along an Ethernet path farther away from the node can still use VLAN separately from this ID being present or absent at the interface of the node itself.¶
; DNS Name List
$$uln-grp //= (
2: dns-name-ctr
)
dns-name-ctr = dns-name / [+ dns-name]
; Should agree with actual DNS restrictions in [RFC 1034]
dns-name = tstr .abnf ("subdomain" .det dns-name-syntax)
dns-name-syntax = '
subdomain = label *("." label)
label = letter [[ldh-str] let-dig]
ldh-str = let-dig-hyp *(let-dig-hyp)
let-dig-hyp = let-dig / "-"
let-dig = letter / digit
letter = %x41-5A / %x61-7A
digit = %x30-39
'
; IP Address List
$$uln-grp //= (
3: ip-addr-ctr
)
ip-addr-ctr = ip-address / [+ ip-address]
; Agrees with untagged bstr contents from [RFC 9164]
ip-address = ipv4-address / ipv6-address
ipv4-address = bstr .size 4
ipv6-address = bstr .size 16
; MAC Address List
$$uln-grp //= (
5: mac-addr-ctr
)
mac-addr-ctr = mac-address / [+ mac-address]
; Agrees with untagged bstr contents from [RFC 9542]
mac-address = eui48-address / eui64-address
eui48-address = bstr .size 6
eui64-address = bstr .size 8
; MAC VLAN ID
$$uln-grp //= (
8: mac-vlan-id
)
mac-vlan-id = 0 .. 0xFFF
Unlike IP-related ULN termination points (see Section 5.3.2), a termination point which represents access to a CCSDS data link does not necessarily need to advertise its own identity in order to communicate over the data link. Each version of SDLP uses a unique, version-qualified SCID to identify either the sending or receiving node within each data link frame.¶
ccsds-scid indicating the Transfer Frame Version Number and Spacecraft Identifier (SCID) number of the advertising node in the CCSDS ecosystem.
Together these two numbers compose the derived global SCID (GSCID), but they are represented in SAND as separate values.
The registry of qualified SCID is maintained by SANA [SANA-SCID].
If this parameter is absent then other means of determining an associated SCID are needed, or when the advertising node only uses the data frame SCID as the source entity.¶
; Spacecraft Identifier
$$uln-grp //= (
6: ccsds-scid
)
ccsds-scid = [
; Transfer frame version number
version: 1..4,
; Spacecraft identifier
scid: uint
]
The CL Advertisement message indicates CL entities operating on the node sending the message, including both initiator and responder roles where applicable, and any parameters necessary for peers to make use of those CL instances. Each instance can also have an associated validity schedule.¶
Each CL Advertisement message SHALL be transported with a Hop Limit of 1. Only 1-hop neighbors are capable of using CL data so there is no need to forward this to any other BP nodes in the network.¶
The CL Advertisement message SHALL be identified by message type 3. Each message with this type SHALL contain a separate data map for each CL instance being advertised. This message corresponds with the CDDL of Figure 12 and the following minimum instance parameters. These parameters are also in the IANA registry defined in Section 9.3.4.¶
int16 identifying the type of CL being defined.
Possible CL Type values are defined Section 9.3.4 where, similar to message types, positive values are for well-known CL types and negative values are for private or experimental types.¶
uint.
This index correlates to a Termination Point entry from the Underlayer Network (ULN) Advertisement from the same advertising node.¶
$sand-msg /= sand-msg-gen<3, cl-recv>
cl-recv = $cl-recv .within sand-generic-map
; CDDL generic to provide minimum and common CL parameters
; The cl-type is from "SAND CL Types" registry
cl-base<cl-type> = (
0: cl-type .within int16,
cl-tp-ix,
$$cl-common-grp
)
; Corresponding ULN TP Index
cl-tp-ix = (
1: uln-tp-ix-value
)
Each CL Advertisement SHALL contain at least one CL instance. Each CL instance SHALL contain at least the CL Type and Termination Point Index parameters. A CL instance MAY have a non-unique CL Type (Section 5.4) parameter, indicating multiple instances of a particular CL are operating on a node. Each CL instance SHOULD be reachable via the ULN (and its termination point) over which the enveloping message is sent. Advertising CL instances which are not reachable by receiving SAND participants is simply a waste of advertising resources and possibly by resources on other participants trying to determine reachability.¶
It is an important distinction that the CL parameterization is about the capability of receiving bundles on the advertising node. It is not about ability of the node to forward bundles, which may in fact be more or less broad than its ability to receive. For example, in the situation where a node has an ephemeral IP address and no DNS name that node may not listen with any CL yet, because some CLs are bidirectional, it may have symmetric (BP layer) connectivity to some set of peer nodes. Even in that case there is still value in discovering the presence of the non-listening node because there is the potential for a contact (coming from that node) to allow bundle routes to other nodes "behind" that non-listening node.¶
The general, technology-non-specific CL parameters are listed below and correspond with the CDDL of Figure 13.¶
bool indicating whether transport security is required (when true) or prohibited (when false).
Details about how to interpret this common parameter are CL-type-specific.
If this parameter is absent there is no information about the required policy.¶
This pair uses key 6 and value type uint containing flags indicating which CL-specific roles the advertising node can act as.
Details about how to interpret this general parameter are CL-type-specific.¶
The role flag at bit 0 indicates that the node can act in a responder role.
The role flag at bit 1 indicates that the node can act in an initiator role.
If this parameter is absent it is assumed to be 0b11 (the node can be either role).¶
; Security Required, if any, for this CL
$$cl-common-grp //= (
5: bool
)
; CL-type-defined roles
$$cl-common-grp //= (
6: uint .bits cl-role-flags
)
cl-role-flags = &(
responder: 0,
initiator: 1,
)
When acting in the initiator role only, the CL MAY still include specific transport parameters. For example, a source bind port number (Section 5.4.2) for bidirectional CL protocols such as LTP/UDP (to address the issues discussed in Appendix A).¶
The following are CL parameters common to all IP-based transports as part of fully specified CL types. A parameter being present in this section does not imply that it is relevant to all CL types; each CL type defines the parameters which are applicable to it.¶
uint indicating the IP-based transport-layer port number to which the CL is bound.
If this parameter is absent, an IP-based CL type shall be treated as using the default (i.e., IANA assigned) port number SHALL for that type.¶
ip-addr-ctr from IPv4 or IPv6 addresses encoded as 4-byte or 16-byte strings respectively.
Each address represents a local destination to which the CL is bound in order to receive traffic.
If this parameter is absent, an IP-based CL type SHALL be treated as if it was bound to the "any endpoint" IPv4 and IPv6 addresses (0.0.0.0 and :: respectively).
If a node has either IPv4 or IPv6 addresses assigned but is not listening on the associated address family, this list SHALL contain the associated "any destination" bind address on which it is listening.¶
ip-addr-ctr from IPv4 or IPv6 addresses encoded as 4-byte or 16-byte strings respectively.
Each address represents a multicast group for which the CL is a member in order to receive traffic.
If this parameter is absent, an IP-based CL type SHALL be treated as if it does not participate in any multicast group.¶
mac-addr-ctr from EUI-48 or EUI-64 addresses encoded as 6-byte or 8-byte strings respectively.
Each address represents a local destination to which the CL is bound in order to receive traffic.
If this parameter is absent, the CL instance SHALL be treated as if it was bound to the "any endpoint" MAC address(es).¶
mac-addr-ctr from EUI-48 or EUI-64 addresses encoded as 6-byte or 8-byte strings respectively.
Each address represents a multicast group for which the CL is a member in order to receive traffic.
If this parameter is absent, the CL instance SHALL be treated as if it does not participate in any multicast group.¶
; IP-based transport bind port number
$$cl-common-grp //= (
4: 1 .. 0xFFFF
)
; IP bind address(es)
$$cl-common-grp //= (
3: ip-addr-ctr
)
; IP multicast address(es)
$$cl-common-grp //= (
7: ip-addr-ctr
)
; MAC bind address(es)
$$cl-common-grp //= (
8: mac-addr-ctr,
)
; MAC multicast address(es)
$$cl-common-grp //= (
9: mac-addr-ctr,
)
A ULN Advertisement (Section 5.3) from a node can contain any combination of DNS Name List, IP Address List, MAC Address List, and Link MTU items. Because of this individual CL Instances MAY contain additional DNS names and/or addresses specific to that instance. Duplication between underlayer DNS name or address and CL instance values SHOULD be avoided, but has no effect on the interpretation of the values.¶
If multiple values are present in IP Address List for a CL it is an implementation matter to choose which one to attempt first, and whether multiple attempts are made sequentially or simultaneously. One possible algorithm to handle multiple network addresses for the same service is Happy Eyeballs [RFC8305], but details are likely to be CL-type-specific.¶
The following are CL parameters common to CCSDS data links as part of fully specified CL types. A parameter being present in this section does not imply that it is relevant to all CL types; each CL type defines the parameters which are applicable to it. These parameters are in addition to ULN TP information defined in Section 5.3.3 to construct global identifiers in the data plane.¶
Within this document, the term "AOS-SDLP" is used to mean the Virtual Channel Packet service of the Advanced Orbiting Systems SDLP (AOS-SDLP) [CCSDS-AOS]. Within this document, the term "USLP" is used to mean the Multiplexer Access Point Packet service of the Unified Space Data Link Protocol (USLP) [CCSDS-USLP]. Other services provided by those data link entities are not used here.¶
This pair uses key 10 and value type uint containing an enumerated value from the following list.¶
If this parameter is absent for a CL type which uses an SCID, the CL instance SHALL be treated as if it will accept packets with DESTINATION mode.¶
uint, each with a valid range between 0 and 64 inclusive.
Each integer represents an AOS-SDLP or USLP Virtual Channel Identifier (VCID) to which the CL is bound in order to receive traffic.
If this parameter is absent for a CL type which uses a VCID, the CL instance SHALL be treated as if it will accept on any virtual channel.¶
uint, each with a valid range between 0 and 16 inclusive.
Each integer represents a USLP Multiplexer Access Point Identifier (MAPID) to which the CL is bound in order to receive traffic.
If this parameter is absent for a CL type which uses a MAPID, the CL instance SHALL be treated as if it will accept on any access point.¶
; USLP frame SCID use
$$cl-common-grp //= (
10: &(
SOURCE: 0,
DESTINATION: 1
)
)
; SDLP VCID
$$cl-common-grp //= (
11: [+ ccsds-vcid]
)
ccsds-vcid = 0..64
; SDLP MAPID
$$cl-common-grp //= (
12: [+ ccsds-mapid],
)
ccsds-mapid = 0..16
This CL type specifically refers to the TCP Convergence Layer (TCPCL) version 4 [RFC9174]. This CL type SHALL be identified by code point 1.¶
If the Bind Port Number parameter is absent, the default TCPCL port 4556 SHALL be used.
The Transport Security Required parameter SHALL indicate both the Contact Header USE_TLS flag and the post-negotiation policy enforcement (i.e., when the session will be disallowed).
The Roles parameter SHALL indicate whether the TCPCL entity on the node can function as either active connector (value "initiator") or passive listener (value "responder") or both.¶
The CL-specific parameters are listed below and correspond with the CDDL of Figure 16. These are also registered in the IANA registry defined in Section 9.3.4.¶
$cl-recv /= {
cl-base<1>,
* $$cl-tcpclv4-grp
}
$$cl-tcpclv4-grp //= (
-1: [+ tcpcl-msg-type]
)
tcpcl-msg-type = 0 .. 0xFF
$$cl-tcpclv4-grp //= (
-2: [+ tcpcl-ext-type], ; session extension types from [IANA-BP]
)
$$cl-tcpclv4-grp //= (
-3: [+ tcpcl-ext-type], ; transfer extension types from [IANA-BP]
)
tcpcl-ext-type = 0 .. 0xFFFF
This CL type specifically refers to the UDPCL Version 2 of [I-D.ietf-dtn-udpcl]. This CL type SHALL be identified by code point 2.¶
If the Bind Port Number parameter is absent, the default UDPCL port 4556 SHALL be used. The Transport Security Required parameter SHALL indicate the need for DTLS security when receiving CL messages. The Roles parameter SHALL indicate whether the UDPCL entity on the node can function as either transfer sender (value "initiator") or receiver (value "responder") or both.¶
The CL-specific parameters are listed below and correspond with the CDDL of Figure 17. These are also registered in the IANA registry defined in Section 9.3.4.¶
$cl-recv /= {
cl-base<2>,
* $$cl-udpclv2-grp
}
$$cl-udpclv2-grp //= (
-1: [+ ext-key], ; ext-key from [I-D.ietf-dtn-udpcl]
)
The CL types defined in this section are variations of using the Licklider Transport Protocol (LTP) [RFC5326] to transport as a convergence layer protocol. Because SAND code points are fully specified, the full CL protocol stacks registered by this specification are the following.¶
The CCSDS profile of BPv7 includes a specification for this in Appendix TBD of [CCSDS-BPv7] using Client Service ID (CSID) value 5. Additionally the LTP-over-UDP binding is defined in Section 3.3 of [RFC7122]. The combination of LTP CSID 5 with UDP segment transport SHALL be identified by code point 3.¶
There is also an LTP-over-EPP binding, using EPP Protocol Identifier code point 1, defined in Appendix B2 of [CCSDS-LTP]. The combination of LTP CSID 5 with EPP segment transport over AOS-SDLP SHALL be identified by code point 7. The combination of LTP CSID 5 with EPP segment transport over USLP SHALL be identified by code point 8.¶
There is also a CCSDS experimental BPv7 specification which has allocated LTP CSID value 4 for aggregating BP PDUs. The use of LTP CSID 4 to transport one or more BP PDUs as defined in Appendix B2.1.4 of [CCSDS-BPv7-OB] SHALL be identified by code point 252.¶
While there is no concrete specification for transporting BPv7 bundles over LTP using other LTP CSID values [IANA-LTP] [SANA-LTP], this specification makes an allocation to allow a node to advertise that it is using other combinations of protocols. The use of LTP CSID 1 to transport single BP PDUs as defined for BPv6 in Appendix B3 of [CCSDS-BPv6] SHALL be identified by code point 253.¶
If the Bind Port Number parameter is absent for LTP-over-UDP, the default LTP port 1113 SHALL be used. The Transport Security Required parameter has no use because the BPv7 binding to LTP does not specify a transport-layer security mechanism. The Roles parameter SHALL indicate whether the LTP entity on the node can function as either session sender (value "initiator") or session receiver (value "responder") or both.¶
The CL-specific parameters are listed below and correspond with the CDDL of Figure 18. These are also registered in the IANA registry defined in Section 9.3.4.¶
uint to advertise the specific Engine ID used by this LTP entity when sending and correlating LTP segments.
Knowing the Engine ID of a peer before initiating or responding to LTP sessions is necessary for some implementations.¶
$cl-recv /= {
cl-base<(3/7/8/252/253)>,
* $$cl-ltp-grp
}
; LTP Engine ID
$$cl-ltp-grp //= (
-1: uint,
)
; LTP extension support
$$cl-ltp-grp //= (
-2: [+ uint]
)
This CL type specifically refers to the transport of BTP-U PDUs [I-D.ietf-dtn-btpu] in Ethernet frames [I-D.ek-dtn-ethernet]. This CL type SHALL be identified by code point 4.¶
When this CL type is present, its parent TP instance SHALL contain at least a MAC Address List parameter. The parent TP instance MAY contain a MAC VLAN ID parameter to indicate that the frames associated with this binding use a VLAN tag.¶
This CL type does not make use of any of the IP-related parameters (Section 5.4.2) or the Transport Security Required parameter. The Roles parameter SHALL indicate whether the BTPU entity on the node can function as either transfer sender (value "initiator") or receiver (value "responder") or both.¶
The CL-specific parameters are listed below and correspond with the CDDL of Figure 19. These are also registered in the IANA registry defined in Section 9.3.4.¶
This parameterization assumes there is a single well-known ethertype assigned by [I-D.ek-dtn-ethernet] and used by all implementations. Is there a need to expose transfer ID window size for receiver? Would it affect sending behavior?¶
$cl-recv /= {
cl-base<4>,
* $$cl-btpuoe-grp,
}
; Hint Type support
$$cl-btpuoe-grp //= (
-1: [+ btpu-hint]
)
btpu-hint = 0x00 .. 0x7F
The CL types defined in this section are variations of using the CCSDS Encapsulation Packet Protocol (EPP) [CCSDS-EPP] as a simple convergence layer, having the existing EPP Protocol Identifier code point 4 [CCSDS-BPv7-OB], framed in one of the SDLP types. Because CL Type code points are fully specified, the full CL protocol stacks registered by this specification are the following.¶
The EPPCL using EPP over AOS-SDLP SHALL be identified by code point 5. The parameter for VCID defined in Section 5.4.3 applies to this CL Type.¶
The EPPCL using EPP over USLP SHALL be identified by code point 6. The parameters for Source-or-Destination, VCID, and MAPID defined in Section 5.4.3 apply to this CL Type.¶
These CL types do not make use of any of the IP-related parameters (Section 5.4.2) or the Transport Security Required parameter. Any additional data-link-related parameters or security indications are exchanged outside of BP SAND.¶
This document specifies no CL-specific parameters, which corresponds with the CDDL of Figure 20.¶
$cl-recv /= {
cl-base<(5/6)>,
* $$cl-epp-grp,
}
While there is no concrete specification for transporting BPv7 bundles over TCPCL version 3 [RFC7242], this specification makes an allocation to allow a node to advertise that it is using this combination of protocols. This CL type SHALL be identified by code point 254.¶
If the Port Number parameter is absent, the default TCPCL port 4556 SHALL be used. The TCPCL version 3 does not specify a transport-layer security mechanism.¶
This document specifies no CL-specific parameters, which corresponds with the CDDL of Figure 21.¶
$cl-recv /= {
cl-base<254>,
* $$cl-tcpclv3-grp
}
While there is no concrete specification for transporting BPv7 bundles over the experimental UDPCL [RFC7122], this specification makes an allocation to allow a node to express that it is using this combination of protocols. This CL type SHALL be identified by code point 255.¶
This document specifies no CL-specific parameters, which corresponds with the CDDL of Figure 22.¶
$cl-recv /= {
cl-base<255>,
* $$cl-udpcl7122-grp
}
The Local Topology Advertisement message allows a participating node to enumerate the 1-hop neighbors with which the advertising node can communicate (via some unspecified CL or combined aggregate of CLs). Each neighbor is identified by its SAND Singleton EID which is unique across a BP network.¶
Each 1-hop neighbor (peer) is associated with a reachability status and a set of communication metrics similar to the behavior of MANET NHDP [RFC6130]. The source(s) of the metrics are not specified by this document, but might come from estimating based on SAND traffic exchanged with the peer. In addition, some of the data comprising the Local Topology Advertisement message is sourced from the Neighbor Information Base, such as Reachability and Path Metrics as discussed in Table 7.¶
The Local Topology Advertisement message SHALL be identified by message type 5. Each message with this type SHALL contain a separate data map for each 1-hop neighbor being advertised. The message parameters are listed below and correspond with the CDDL of Figure 23. These parameters are also in the IANA registry defined in Section 9.3.5.¶
embed-eid-structure from Section 4 of [I-D.ietf-dtn-eid-pattern] representing the unique SAND Singleton EID for the neighbor node.¶
This pair uses key 1 and value type uint containing an enumerated value indicating the status of communication with the neighbor.
The value is one of the following:¶
$sand-msg /= sand-msg-gen<5, {+ $$localtopo-grp }>
; Node ID
$$localtopo-grp //= (
; Type from [I-D.ietf-dtn-eid-pattern]
0: embed-eid-structure
)
; Reachability
$$localtopo-grp //= (
1: &(
HEARD: 1,
SYMMETRIC: 2,
LOST: 3,
)
)
; Routing Metrics List
$$localtopo-grp //= (
2: [+ nbr-metrics]
)
Each data map represents a combination of a 1-hop neighbor node, its direct parameters, and routing metrics associated with traffic from and to that node. Each message with this type SHALL contain at least one data map (neighbor). Each data map in this message SHALL have a unique Node ID parameter.¶
Each Routing Metrics map is associated with a specific routing type and a set of metrics for BP and underlayer traffic from and to that node. Some of the Routing Metrics parameters are common across all algorithms and some are inputs to a specific routing algorithm.¶
It is expected that two nodes which each see the other as a 1-hop neighbor will provide opposite and similar metrics between each other. If the mutual neighbor nodes don't support the same routing algorithms, the total set of metrics will be different. Because there is no specific synchronization between neighbors, even when mutual neighbors advertise the same metric items there is no guarantee or expectation that they will have the same values. It is an implementation detail for how to reconcile routing metrics between mutual neighbors (e.g. by averaging between neighbors' advertisements) when needed for input to routing algorithms.¶
The common routing metrics are listed below and correspond with the CDDL of Figure 24. These are also registered in an IANA registry defined in Section 9.3.5.¶
int16 identifying a specific routing algorithm.
The registry of SAND routing types is IANA-managed and defined in Section 9.3.5.¶
uint identifying a specific termination point index (local to the advertising node) with which these metrics are associated.
This can correlate with other Termination Point Index values expressed through Underlayer Network (ULN) Advertisement messages.
Including these index values on metrics allows a node to express having multiple paths to reach a 1-hop neighbor, each with different metrics.¶
This pair uses key 1 and value type uint containing an enumerated value indicating the link direction associated with the metrics in the item.
The value is one of the following:¶
This pair uses key 2 and value type schedule as defined in Figure 5.
Each time at which the schedule is valid indicates when communication is expected to be available (in the associated Direction).¶
This is different than the resource schedule of the node itself, and represents availability of the shared network between the advertising node and this peer.¶
nbr-metrics = $nbr-metrics .within sand-generic-map
; CDDL generic for reachability metrics
; The rtg-type is from "SAND Routing Types" registry
nbr-metrics-base<rtg-type> = (
0: rtg-type .within int16,
metrics-tp-ix,
metrics-direction,
* $$nbr-metrics-common-grp,
)
; Corresponding ULN TP Index
metrics-tp-ix = (
3: uln-tp-ix-value
)
; Direction relative to neighbor
metrics-direction = (
1: &(
TRANSMIT: 1,
RECEIVE: 2,
)
)
; Validity Schedule
$$nbr-metrics-common-grp //= (
2: schedule
)
This routing type captures metrics needed for input to the Schedule-Aware Bundle Routing (SABR) algorithm [CCSDS-SABR] defined by CCSDS.¶
The SABR routing metrics are listed below and correspond with the CDDL of Figure 25. These are also registered in an IANA registry defined in Section 9.3.5. Metrics parameters with negative keys are delegated to an algorithm-specific registry.¶
unsigned-fraction indicating the expected maximum data rate of traffic in octets per second.
This data rate is measured at the underlying link layer, not just the throughput of BP PDUs.¶
time-duration indicating the expected one-way light time (OWLT) of traffic in milliseconds.
This delay is measured between the two BP nodes so it is more than just the free-space propagation delay, it also includes any expected underlay, CLA, and BPA processing time.¶
unsigned-fraction indicating the expected bit error rate (BER) of traffic as a ratio.
This BER is measured at the underlying link layer and includes errors which are caught by underlayer checksums (e.g., where the CL segment/frame is lost).¶
$nbr-metrics /= {
nbr-metrics-base<0>,
? nbr-rtm-datarate,
? nbr-rtm-delay,
? nbr-rtm-ber
}
; Maximum data rate in bytes-per-second
nbr-rtm-datarate = (
-1: unsigned-fraction
)
; One-way delay
nbr-rtm-delay = (
-2: time-duration
)
; Estimated BER as a ratio
nbr-rtm-ber = (
-3: unsigned-fraction
)
; Same structure as tag #4 "decimal fraction" but limited in domain
unsigned-fraction = [
exp: (-20 .. 20) .within int,
mantissa: uint,
]
For conciseness of encoding, the unsigned-fraction values SHOULD limit the mantissa to less than 8 bits.
This limits the precision of encoded values but because these are all rough estimates that should be sufficient for contact planning purposes.¶
There is no required combination of RX and TX parameters for any peer. Because these might be estimated from traffic or some kind of underlying discovery protocol (e.g., DLEP) it is possible to obtain estimates for some subset of these but not all of them.¶
For both RX and TX Data Rate values, the rate is averaged over the entire valid time, so it is actually average-of-maximum rate. Another way to think of it is that the sum-total valid time duration multiplied by the data rate value will yield a total data volume that is transferable from (or to) the peer within the validity duration.¶
The Endpoint Advertisement message contains information about the endpoints registered on the advertising node at the time of the message formation. This information does not include information about the registration state (active or passive, as defined in Section 3.1 of [RFC9171]).¶
When creating Endpoint Advertisement messages, the advertising node MAY filter advertised endpoints to prevent visibility of particular endpoints to particular underlayer networks or destination nodes. Each advertised endpoint SHOULD be reachable as a bundle destination on the node sending the message. Advertising unreachable endpoints wastes resources on the sender and participating nodes. Because a node is expected to have a possibly large number of endpoints registered with similar advertised parameters, each endpoint definition is organized around an EID Pattern rather than a single EID.¶
The Endpoint Advertisement message SHALL be identified by message type 7. Each message with this type SHALL contain a separate data map for each endpoint being advertised. The message parameters are listed below and correspond with the CDDL of Figure 26. These parameters are also in the IANA registry defined in Section 9.3.6.¶
bstr embedding an EID Pattern as defined in Section 4 of [I-D.ietf-dtn-eid-pattern].
Each of the other items in the parent definition applies to all EIDs matched by this pattern.
For singleton endpoints, the node-identifying portion of the pattern SHALL agree with the advertising node.¶
This pair uses key 5 and value type uint containing flags indicating which aspects of payload security are required for communicating with this endpoint.
If this parameter is absent there is no information about the required policy.¶
The security flag at bit 0 indicates that the payload SHALL be a target of a BIB that the node can accept. The security flag at bit 1 indicates that the payload SHALL be a target of a BCB that the node can accept. The security flag at bit 2 indicates that any accepted security block SHALL bind to the primary block as AAD.¶
$sand-msg /= sand-msg-gen<7, {+ $$endpoint-grp }>
$$endpoint-grp //= ( * priv16 => any )
; EID Pattern
$$endpoint-grp //= (
0: embed-eid-pattern, ; From [I-D.ietf-dtn-eid-pattern]
)
; Payload Security Required
$$endpoint-grp //= (
5: uint .bits endpoint-sec-flags
)
endpoint-sec-flags = &(
need-bib: 0,
need-bcb: 1,
bind-primary: 2,
)
Each message with this type SHALL contain at least one data map. Each data map SHALL have a unique EID Pattern parameter. There SHALL NOT be any intersection between EID Pattern parameters across multiple maps.¶
Each participating node SHOULD register and advertise a singleton endpoint for the SAND application itself. This allows SAND Bundles to be transported with payload confidentiality to specific peer nodes. The endpoint SHOULD use the well-known service number from Section 9.2 when the Node ID uses the IPN scheme.¶
An advertisement for the SAND singleton endpoint SHALL contain at least a Payload Security Required value.¶
This section outlines the ways in which SAND Messages (Section 5) can be combined into SAND Bundles (Section 4.2) and transported to other SAND-participating nodes. Because SAND messages can be combined in many ways and because the contents of each message can be filtered-out based on the need for data privacy or operational security considerations, these modes are not exhaustive of how SAND messages can be used to advertise to and discover about peers.¶
When a node first enrolls in a network, or when a node is informed of a link state change to active, it SHOULD send a Group Hello message set with a Hop Limit of 1 using one or more default convergence layer (Section 4.6). Because this is a group BP destination, it will be sent as a plaintext payload. This message set consists of the following:¶
The node SHALL include a Data Solicitation message if the time since the last Data Solicitation on that termination point has exceeded an implementation-defined threshold.¶
For a new enrollment, a node SHOULD solicit all of the following: Credential Advertisement, ULN Advertisement, CL Advertisement, Local Topology Advertisement. For link state change, a node SHOULD solicit at least Local Topology Advertisement.¶
When a node is informed by some lower-level discovery mechanism that a specific peer is reachable via IP address, it SHOULD send a Targeted Hello message set with a Hop Limit of 1 using the Default Convergence Layers with the peer's IP address as destination. This message set contains the same messages and data as the Group Hello and is also sent as plaintext payload when peer BP identity and security information is not yet available.¶
After receiving a Data Solicitation message from an authorized sender, a participating node SHALL wait and then send a targeted advertisement to the Source Node ID of the Data Solicitation message. The means by which a participating node authorizes any peer to have a Data Solicitation message acted upon, or authorizes targeted advertisement to that peer is an implementation matter. The wait time SHALL be calculated to avoid sending each advertisement type more frequently than a locally-configured time interval. The wait time MAY include a random jitter [RFC5148] depending on the underlayer network on which the targeted advertisement is to be sent.¶
A participating node MAY send periodic update advertisements based on an internal timer associated with the message type being advertised and the Destination EID being advertised to. A periodic update advertisement SHOULD be sent with an actual interval shorter than or equal to the Repetition Interval (Section 5) sent with associated message type and destination.¶
This section explains various operational topics based on guidance of the IETF Operations and Management Area Working Group [RFC5706].¶
The choice of which types of data to advertise, in the form of different SAND message types being transmitted, is an operational decision of the advertising node alone. The reception and delivery of Data Solicitation messages can inform an advertising node that there is a desire to receive specific types of data. The use of Data Solicitation SHALL NOT override local policy about what can be advertised by a node. The use of Data Solicitation is also not meant to limit the types of data being advertised by a node.¶
Depending on the exact use case for which SAND advertisement is being used (see Section 1.2), different types of data will be more or less useful. For example, when used to express the liveliness of expected links there is little value in including long-lived credentials or unchanging CL instances with every advertisement.¶
The choice of which instances of the various types of data to advertise is an operational decision of the advertising node alone. This choice can involve a node filtering-in specific instances to include or filtering-out specific instances to exclude advertising. The choice of which instances to filter-in or filter-out and how to parameterize those filters is entirely an implementation matter on the advertising node.¶
One simple reason to filter instances would be to exclude ULN termination points or entire ULNs which are not enabled for advertisement or discovery. This corresponds with a strategy to either "only advertise relevant data" or "only advertise dynamic data" to avoid advertising data which is either irrelevant to discovery or not expected to change.¶
Another possible reason to filter instances is related to ULN visibility or limiting cross-ULN-technology exposure of parameter types. For example, only advertising IP-related CL instances or DNS-based credentials when advertising is enabled only on IP-related termination points. This reason is not quite security related, and not concerned with leaking data across different underlayers (see Section 7.3 for details about that).¶
The choice of which types or instances of data to advertise can also be dependent on the ULN over which the advertisement will be made, or dependent on the (BP-layer) destination to or source from which the advertisement is addressed. This is slightly different than the choices discussed in Section 7.1 and Section 7.2, which would apply filtering to all advertisement from a node, and requires more visibility into or control over message transport than those choices.¶
A simple strategy for destination-specific filtering could be to only advertise certain types or instances of data when using singleton destinations for which some amount of security (at BP-layer or below) can be guaranteed. Other advertisement to a group destination (if enabled) could be restricted to contain only enough information to attempt reaching the advertising node and establishing a more secure channel.¶
A possible strategy for termination-point-specific filtering would be to only advertise credentials or CL instances which are relevant to a specific ULN reachable via termination points for which advertisement is enabled. This is slightly different than the blanket filtering discussed in Section 7.2 because different ULNs being advertised on will see different instances of data being advertised, each tailored to relevancy on that ULN. For example, when a ULN uses a private PKIX CA hierarchy an advertising node can filter-in certificates under the associated root of trust when sending Credential Advertisement messages on that ULN.¶
When these kinds of context-specific filtering strategies are orthogonal, they can be combined. For example filtering based on ULN technology and based on BP destination when advertising CL instances (e.g., only advertise IPv6-based CLs via an IPv6-only termination point).¶
Using these context-specific filtering strategies can result in a kind of "split brain" situation, where different neighbors observe different (possibly non-overlapping) sets of data associated with an advertising node. Because of this careful consideration needs to be made when choosing to filter-in or filter-out data instances across different contexts.¶
Another aspect of choice for an advertising node is when to send specific types and instances of advertised data.¶
One valid strategy is for a node to have independent timers associated with different types of data, instances of data, and/or ULN termination points, and periodically sending an associated SAND message containing the state of that data. This makes advertisement behavior more deterministic and provides predictable message sizes and rates. The message metadata parameter Repetition Interval is meant to express an associated timer interval when this strategy is used and allow a message receiver to adapt to the expected message rates. In this case the parameter Validity Duration is expected to be on the same order of magnitude as the Repetition Interval.¶
Another strategy is for a node to send SAND messages only when its associated state has changed. This strategy additionally requires some hysteresis threshold so that frequent, small state changes do not cause excessive advertisement messaging. The message metadata parameter Validity Duration does not apply in this case, as the message content will need to be valid until a superseding message (see Section 4.5) is sent. Using this strategy exclusively is vulnerable to messages being lost because of SAND bundles not being delivered (for any number of possible, even temporary, reasons).¶
An even more extreme strategy is to send messages only when solicited by some other node. Messages sent in response to solicitations can, but do not need to, be specifically directed to the soliciting node. So one possible variation of this strategy is to send advertisements to a group destination in response to solicitations (themselves having either group or singleton destinations).¶
A hybrid of these strategies would use timers to provide a baseline average of messaging interval, with some way for a change of associated state or a received solicitation to trigger an early send along with some hysteresis or cool-down logic to prevent excessive messaging. The use of timers allow the use of appropriate Validity Duration and Repetition Interval parameters, and the superseding logic covers cases of earlier-than-expected sending.¶
Just because a SAND message has been received by a participating node and its transport meets all of the needed conditions of Section 4 does not imply that the receiving node needs to actually use the message or all of the data contained within. This specification defines a mechanism with mandatory-to-implement structures and code points (meaning that implementations need to be able to properly interpret them) but none of these mechanisms are mandatory-to-use by either an advertising node (the sender) or a discovering node (a receiver).¶
The choice of a discovering node to authorize use of specific data (for reasons discussed below) is an implementation matter on that node. Authorization for use of SAND data can be dependent on the SAND data/message type, SAND bundle source or destination, or CL-related parameters about the reception of the bundle PDU. Authorization for use of specific data can also be conditional on previously discovered or negotiated data about the advertising node.¶
Beyond the logic to authorize use of data, it can also be helpful for a discovering node to cull irrelevant data. It is an implementation matter on the discovering node for how to identify irrelevant data, but some examples are below. One reason for such data to be present in the first place is when the advertising node does not use context-specific advertisement (Section 7.3) and includes credentials, ULN instances, and/or CL instances which do not apply to all discovering nodes which can receive the associated SAND messages.¶
One example of this is an advertising node which includes non-IP ULN or CL parameters in its advertisements, which simply cannot be interpreted by an IP-only discovering node. The culling applies only to the internal representation of data within the discovering node and not to any subsequent messaging. This culling is a clear example because a software change would be needed on the discovering node to be able to support the unhandled parameters.¶
Another example is the case where a node advertises ULN instances and/or CL instances with addresses logically unreachable to the discovering node. This does not mean that the addresses need to be probed, just when one or more of the addresses does not have a possible route from the discovering node. Care must be taken in this situation because a routing check failing at the time of reception does not mean that the routing check will not succeed at some later time due to subsequent changes to the discovering node's routing configuration.¶
When the context-specific advertisement (Section 7.3) is used by an advertising node, it is necessary to relate advertised data to CL instances in two ways:¶
When context-specific authorization (Section 7.5) is used by a discovering node, it is necessary to relate received SAND messages to their original enveloping SAND Bundle as well as the local CL instance over which the bundle was received. The means by which the CL-related reception details are parameterized and retained with the received bundle is an implementation matter and not all BPA--application interfaces will allow such deep visibility. In the absence of such visibility, context-specific authorization might not be available on a node.¶
This section separates security considerations into threat categories based on guidance of BCP 72 [RFC3552].¶
Because this protocol is involved in enrollment of a node into a BP network, any initial zero-configuration group messaging (Section 6.1) from a participating node necessarily has a plaintext payload.¶
One avoidance of passive leaking is for the advertising node to filter-out sensitive data from its initial messages as described in Section 7. This could include not disclosing certain DNS names or IP addresses assigned to termination points, certain CL instances, or certain 1-hop neighbors from advertisement messages. It could also include not disclosing certificates from CAs or with key purposes which are sensitive. Because the initial group messaging is termination point-specific, the filtering-out of data does not need to be symmetric across all termination points on which the node is participating in SAND.¶
Another possible mitigation is to avoid group messaging entirely on a termination point and rely on lower-layer network peer discovery to identify potential participants and then attempt to use UDPCL with DTLS (or some underlayer-specific equivalent) to establish secure transport with the peer. While more secure from eavesdroppers, this method is more time- and resource-consuming than group messaging. This method also assumes that transport-layer security is even possible while in some environments only BP-layer security is viable.¶
It is important to consider that if end-to-end confidentiality is not applied to the payload of a SAND bundle, its messages need to be treated as observable by middleboxes and/or eavesdroppers. Just because a bundle is marked with a hop limit of 1 and is expected to traverse a single forwarding hop to its destination does not provide any assurance that it will not be observed by some middlebox (operating at BP layer or below).¶
Even if group messaging is prohibited or restricted, and confidentiality is provided to messages targeted to a specific node, the data itself may leak details that should be hidden from the discovering node. The only mitigation for these kinds of leaks is to perform destination-specific filtering as described in Section 7.3. This filtering will be separate from (and possibly in addition to) any TP-specific filtering that might be applied based on the underlayer through which the SAND bundle will be forwarded.¶
Regardless of whether the SAND messages are kept confidential (using BPSec or lower-layer security) there is a possibility for an on-path attacker to record and replay SAND bundles.¶
Because this specification defines rules for superseding messages in Section 4.5 and there is already an expectation that redundant transmissions can happen normally in the Default Convergence Layers, the only bad effect of SAND bundle replay is to waste network resources on the path(s) to the bundle destinations.¶
The behaviors described in this section all amount to a potential denial-of-service to a participating node. The denial-of-service could be limited to an individual node, or could affect all entities on a host or network segment.¶
Because there is a Data Solicitation mechanism it is possible to attempt an amplification attack by soliciting many types of data, with corresponding large bundle size, using a small request bundle. A mitigation of this kind of attack is to treat solicitation requests in the context of minimum and maximum update intervals. Rather than causing a set of advertisements directly, the solicitation is treated as an update timer reset and is limited according to that timer interval.¶
A participating node may, intentionally or not, use singleton or group messaging to overwhelm a link or network, requiring the receiving node to process the data. This kind of attack applies to BP Agents generally and is not specific to SAND messaging. The victim node can block bundles or CL reception from network peers which are thought to be incorrectly behaving within the network.¶
Because the Default Convergence Layers include UDP transport, the recommended configurations of this document need to result in behaviors which conform to the limitations of "UDP Usage Guidelines" BCP 145, specifically Section 4 of [RFC8085]. This protocol uses the "congestion avoidance" strategy by having implementations choose appropriate timer intervals for minimum SAND updates and, when applicable, for UDPCL redundant transmission explained in Section 3.3.1 of [I-D.ietf-dtn-udpcl].¶
For BP nodes enrolling in a network for the first time, with proper authorization to do so, other participating nodes will not be able to authenticate SAND Bundles per the requirements of Section 4.4 without having associated end-entity certificates available.¶
A participating node SHOULD have the ability for an application to inspect the payload of a bundle as part of BPSec processing in order to extract necessary certificates from Credential Advertisement messages. If that is not possible, an advertising node SHOULD include necessary certificates within any BIB needed to satisfy requirements of Section 4.4. Determination of this need is a network administration matter outside the scope of this document.¶
In environments where PKI is not available for the BP-layer, the SAND could be operated without the requirements of Section 4.4 but doing so is outside the scope of this document. Even in cases where there is network-layer or link-layer security, specifically source authentication with proof-of-possession, having an authorized lower-layer identity does not imply unlimited BP-layer authorization. Part of the purpose of BP-layer integrity protection is to prevent a misconfigured node from polluting topology information bases of BP routers.¶
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of code points in existing registries and creation of new SAND registries in accordance with BCP 26 [RFC8126].¶
Within the URI Schemes registry group of [IANA-URI], the registry titled "'imc' Scheme Well-known Group Numbers for BPv7" has been updated to include the following entry.¶
| Value | Description | Reference |
|---|---|---|
| TBA1 | SAND Participants | [This specification] |
Within the URI Schemes registry group of [IANA-URI], the registry titled "'imc' Scheme Well-known Service Numbers for BPv7" has been updated to include the following entry.¶
| Value | Description | Reference |
|---|---|---|
| TBA2 | SAND Messaging | Section 4 of [This specification] |
Within the URI Schemes registry group of [IANA-URI], the registry titled "'ipn' Scheme URI Well-known Service Numbers for BPv7" has been updated to include the following entry.¶
| Value | Description | Reference |
|---|---|---|
| TBA3 | SAND Messaging | Section 4 of [This specification] |
EDITOR NOTE: Registry group and registries to-be-created upon publication of this specification.¶
IANA will create the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND] to contain registries associated with the SAND protocol.¶
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND Message Types" and initialize it with the contents of Table 15. For positive code points the registration procedure is Specification Required. Negative code points are reserved for use on private networks for functions not published to the IANA.¶
Specifications of new message types need to define the code point (an int16 integer), as well as what message metadata are required and allowed within the message and how to interpret the message data maps.
The definition of each message type SHALL include the semantics of each valid data map item within the message.
Specifications need to define how those CBOR data are used by a node to relate the encoded message to the agent's information bases.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| -32768 to -1 | Reserved | [This specification] |
| 0 | Reserved | [This specification] |
| 1 | Data Solicitation | Section 5.1 of [This specification] |
| 2 | Credential Advertisement | Section 5.2 of [This specification] |
| 8 | ULN Advertisement | Section 5.3 of [This specification] |
| 3 | CL Advertisement | Section 5.4 of [This specification] |
| 5 | Local Topology Advertisement | Section 5.5 of [This specification] |
| 7 | Endpoint Advertisement | Section 5.6 of [This specification] |
| 9 to 32511 | unassigned | |
| 32512 to 32767 | Reserved for private and experimental types | [This specification] |
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND Message Metadata Parameters" and initialize it with the contents of Table 16. The registration procedure is Specification Required.¶
Specifications of new metadata parameters need to define the code point (an int16 integer) as well as the CBOR form and meaning of the associated value.
Specifications need to define how those CBOR parameters are used by a node to relate the encoded message to the node's information bases.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| 2 | Reference Time | Section 5 of [This specification] |
| 3 | Validity Duration | Section 5 of [This specification] |
| 4 | Repetition Interval | Section 5 of [This specification] |
| 5 to 32511 | unassigned | |
| 32512 to 32767 | Reserved for private and experimental metadata | [This specification] |
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND ULN Advertisement Parameters" and initialize it with the contents of Table 17. The registration procedure is Specification Required.¶
Specifications of new ULN data parameters need to define the code point (an int16 integer) as well as the CBOR form and meaning of the associated value.
Specifications need to define how those CBOR parameters are used by a node to relate the encoded message to the node's information bases.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| -32768 to -1 | Reserved | [This specification] |
| 0 | Termination Point Index | Section 5.3 of [This specification] |
| 1 | Validity Schedule | Section 5.3.1 of [This specification] |
| 2 | DNS Name List | Section 5.3.2 of [This specification] |
| 3 | IP Address List | Section 5.3.2 of [This specification] |
| 4 | Link MTU | Section 5.3.1 of [This specification] |
| 5 | MAC Address List | Section 5.3.2 of [This specification] |
| 6 | CCSDS Spacecraft Identifier | Section 5.3.3 of [This specification] |
| 7 | ULN Labels | Section 5.3.1 of [This specification] |
| 8 | MAC VLAN ID | Section 5.3.2 of [This specification] |
| 9 to 32511 | unassigned | |
| 32512 to 32767 | Reserved for private and experimental parameters | [This specification] |
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND ULN Labels" and initialize it with the contents of Table 18. For positive code points the registration procedure is Specification Required. Negative code points are reserved for use on private networks for functions not published to the IANA.¶
Specifications of new ULN Labels need to define the label value (an int16 integer), as well as the purpose and meaning of the presence or absence of the label in any TP instance.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| -32768 to -1 | Reserved for private and experimental use | [This specification] |
| 0 | Reserved | [This specification] |
| 1 | This Instance | Section 5.3.1 of [This specification] |
| 2 to 32767 | unassigned |
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND CL Common Parameters" and initialize it with the contents of Table 19. The registration procedure is Specification Required.¶
Specifications of new CL common parameters need to define the code point (an int16 integer) as well as the CBOR form and meaning of the associated value.
Specifications need to define how those CBOR parameters are used by a node to relate the encoded message to the node's information bases.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| -32768 to -32513 | Reserved for private and experimental type-specific parameters | [This specification] |
| -32512 to -1 | Delegated to SAND CL Type-Specific Parameters registry | [This specification] |
| 0 | CL Type | Section 5.4 of [This specification] |
| 1 | Termination Point Index | Section 5.4 of [This specification] |
| 3 | IP Bind List | Section 5.4.2 of [This specification] |
| 4 | Bind Port Number | Section 5.4.2 of [This specification] |
| 5 | Transport Security Required | Section 5.4.1 of [This specification] |
| 6 | Role | Section 5.4.1 of [This specification] |
| 7 | IP Multicast List | Section 5.4.2 of [This specification] |
| 8 | MAC Bind List | Section 5.4.2 of [This specification] |
| 9 | MAC Multicast List | Section 5.4.2 of [This specification] |
| 10 | SCID Source-or-Destination | Section 5.4.3 of [This specification] |
| 11 | VCID List | Section 5.4.3 of [This specification] |
| 12 | MAPID List | Section 5.4.3 of [This specification] |
| 14 to 32511 | unassigned | |
| 32512 to 32767 | Reserved for private and experimental common parameters | [This specification] |
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND CL Types" and initialize it with the contents of Table 20. For positive code points the registration procedure is Specification Required. Negative code points are reserved for use on private networks for functions not published to the IANA.¶
Specifications of new CL types need to define the CL Type value (an int16 integer), as well as the other CL parameters required and allowed.
The definition of each CL type SHALL include the semantics of each valid data map item within the message.
The definition of each CL type SHALL include details about how data map items are used by a participating node to transfer bundles to the advertising node via that CL.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| -32768 to -1 | Reserved for private and experimental use | [This specification] |
| 0 | Reserved | [This specification] |
| 1 | TCPCLv4 | Section 5.4.4.1 of [This specification] |
| 2 | UDPCLv2 | Section 5.4.4.2 of [This specification] |
| 3 | LTPCL CSID 5 Over UDP | Section 5.4.4.3 of [This specification] |
| 4 | BTP-U Over Ethernet | Section 5.4.4.4 of [This specification] |
| 5 | EPP Over AOS-SDLP | Section 5.4.4.5 of [This specification] |
| 6 | EPP Over USLP | Section 5.4.4.5 of [This specification] |
| 7 | LTPCL CSID 5 Over EPP over AOS-SDLP | Section 5.4.4.3 of [This specification] |
| 8 | LTPCL CSID 5 Over EPP over USLP | Section 5.4.4.3 of [This specification] |
| 9 to 251 | unassigned | |
| 252 | LTPCL CSID 4 Over UDP | Section 5.4.4.3 of [This specification] |
| 253 | LTPCL CSID 1 Over UDP | Section 5.4.4.3 of [This specification] |
| 254 | TCPCLv3 | Section 5.4.4.6 of [This specification] |
| 255 | Experimental UDPCL | Section 5.4.4.7 of [This specification] |
| 256 to 32767 | unassigned |
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND CL Type-Specific Parameters" and initialize it with the contents of Table 21. The registration procedure is Specification Required.¶
Specifications of new type-specific parameters need to define the associated CL type, parameter code point (an int16 integer), and the CBOR form and meaning of the associated value.¶
| CL Type | Code | Name | Reference |
|---|---|---|---|
| TCPCLv4 | |||
| 1 | -1 | Message Type Support | Section 5.4.4.1 of [This specification] |
| 1 | -2 | Session Extension Type Support | Section 5.4.4.1 of [This specification] |
| 1 | -3 | Transfer Extension Type Support | Section 5.4.4.1 of [This specification] |
| UDPCLv2 | |||
| 2 | -1 | Extension Support | Section 5.4.4.2 of [This specification] |
| LTPCL Variants | |||
| 3,7,8,252,253 | -1 | Engine ID | Section 5.4.4.3 of [This specification] |
| 3,7,8,252,253 | -2 | Extension Support | Section 5.4.4.3 of [This specification] |
| BTPU Variants | |||
| 4 | -1 | Hint Support | Section 5.4.4.4 of [This specification] |
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND Neighbor Parameters" and initialize it with the contents of Table 22. The registration procedure is Specification Required.¶
Specifications of new neighbor parameters need to define the code point (an int16 integer) as well as the CBOR form and meaning of the associated value.
Specifications need to define how those CBOR parameters are used by a node to relate the encoded message to the node's information bases.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| -32768 to -1 | Reserved | [This specification] |
| 0 | Node ID | Section 5.5 of [This specification] |
| 1 | Reachability | Section 5.5 of [This specification] |
| 2 | Routing Metrics | Section 5.5 of [This specification] |
| 3 to 32511 | unassigned | |
| 32512 to 32767 | Reserved for private and experimental parameters | [This specification] |
| Code | Name | Reference |
|---|---|---|
| -32768 to -32513 | Reserved for private and experimental type-specific parameters | [This specification] |
| -32512 to -1 | Delegated to SAND Routing Metrics Type-Specific Parameters registry | [This specification] |
| 0 | Routing Type | Section 5.5.1 of [This specification] |
| 1 | Direction | Section 5.5.1 of [This specification] |
| 2 | Validity Schedule | Section 5.5.1 of [This specification] |
| 3 | Termination Point Index | Section 5.5.1 of [This specification] |
| 4 to 32511 | unassigned | |
| 32512 to 32767 | Reserved for private and experimental common parameters | [This specification] |
| Code | Name | Reference |
|---|---|---|
| -32768 to -1 | Reserved for private and experimental use | [This specification] |
| 0 | Reserved | [This specification] |
| 1 | SABR | Section 5.5.1.1 of [This specification] |
| 2 to 32767 | unassigned |
| Routing Type | Code | Name | Reference |
|---|---|---|---|
| SABR | |||
| 1 | -1 | Maximum Data Rate | Section 5.5.1.1 of [This specification] |
| 1 | -2 | Delay | Section 5.5.1.1 of [This specification] |
| 1 | -3 | Bit Error Rate | Section 5.5.1.1 of [This specification] |
EDITOR NOTE: registry to-be-created upon publication of this specification.¶
IANA will create, under the "Bundle Protocol Secure Advertisement and Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a registry titled "SAND Endpoint Parameters" and initialize it with the contents of Table 26. The registration procedure is Specification Required.¶
Specifications of new endpoint parameters need to define the code point (an int16 integer) as well as the CBOR form and meaning of the associated value.
Specifications need to define how those CBOR parameters are used by a node to relate the encoded message to the node's information bases.¶
Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶
| Code | Name | Reference |
|---|---|---|
| -32768 to -1 | Reserved | [This specification] |
| 0 | EID Pattern | Section 5.6 of [This specification] |
| 5 | Payload Security Required | Section 5.6 of [This specification] |
| 6 to 32511 | unassigned | |
| 32512 to 32767 | Reserved for private and experimental parameters | [This specification] |
The core LTP specification in Section 5 of [RFC5326] relies on an underlying transport to convey each LTP "segment" PDU between sending and receiving LTP engines for its normal operation. Each segment is associated with exactly one LTP session which is used to transfer a single contiguous "block" of data, which is treated as opaque bytes by each LTP engine. All sessions handled by an LTP engine are associated with a state machine independent of any other session.¶
When using "red part" block data within a session, which is the requirement from CCSDS uses of LTP [CCSDS-BPv7-OB] [CCSDS-BPv7] as a CL, segments need to be conveyed in both directions between the block-sending engine to the block-receiving engine. Some of the segments contain block data, some contain reception reports, and others have acknowledgement or cancellation data.¶
Each LTP session is uniquely identified by the pair consisting of the LTP Engine ID of the entity that initiated the session and a Session ID issued by that entity. Beyond being independent of each other, the state machine of an LTP session is not at all bound to the specific transport (or its parameters) used to convey LTP segments in either direction from an LTP engine. This means that successful LTP operation can occur over unidirectional transports with dissimilar protocol stacking in either direction between any two engines, even using dissimilar stacks for different segments within a single LTP session. It also means that there is no guarantee that a transport which does allow for bi-directional capability is able to be used by both engines for that capability.¶
In more concrete terms, the current definition of LTP segment transport over UDP/IP in Section 3.3 of [RFC7122] does not require any relationship between the listening address-and-port on the block-sender side and block-receiver side. An implementation sending segments via UDP datagrams from a particular address-and-port is not obligated to listen for datagrams on that same address-and-port. In cases where the datagram source port is from the dynamic range but the listening port is the well-known number (which is a common implementation pattern), there is no in-band way for the receiving LTP engine to correlate the two or to even know about the listening port of its peer without prior configuration.¶
Similarly, the definition of segment transport over EPP/SDLP [CCSDS-LTP] does not relate the virtual channel (VC), multiplexer access point (MAP), or even SCID used for one direction with any VC or MAP used for the opposite direction.¶
A consequence of this in BP SAND is that successful use of LTP in a zero-configuration case between any two nodes requires each block-sending node to advertise its LTP listening parameters, including appropriate roles (Section 5.4.1), so that they can be used by a block-receiving node for transport of report segments back to the sending node. Future updates to LTP binding specifications could require or recommend more strict relationships to make zero-configuration use more straightforward.¶
This section contains some simple scenarios which show how the various capabilities of BP SAND are needed in specific circumstances, and how some of the different Operational Considerations affect how a SAND deployment can be used.¶
These examples illustrate that while SAND shares many concepts with MANET NHDP [RFC6130], the fact that BP naming (and numbering) is associated with each node while IP numbering is associated with each interface changes the nuance of how information is managed, exchanged, and synthesized. Some examples also illustrate the subtleties of CCSDS SDLP numbering as an underlayer technology.¶
In this example, a BP router (Node A) has connectivity to an IP-based ULN through one TP (index 0), through which it acts as a router for nodes with time-varying operation (e.g., a power schedule) or time-varying links (e.g., caused by geometry or kinematics). This is depicted in Figure 27 for the BP topology layer [RFC8345], which does not explicitly show any time-variance in the links. The other nodes on that ULN can be reachable separately or simultaneously depending on the state of those time-varying links. When there is traffic between the edge nodes and the links are not up simultaneously the router acts as storage for that traffic.¶
+--------+ +--------+ +--------+
| Node A | | Node B | | Node C |
+----+---+ +----+---+ +----+---+
{0} {0} {0}
/ \ | |
| -------------' |
'------------------------------'
The router and the edge nodes all have IPv6 link-local and/or global addresses as long as they are in the same prefix and are reachable at the ULN layer when links are up. This supporting network is depicted in Figure 28 for the IP underlayer, depicting the possible links in that topology layer.¶
+--------+
.---->{}| Node B |
+--------+ v +--------+
| Node A |{}
+--------+ ^ +--------+
'---->{}| Node C |
+--------+
The router advertises its presence on the IP-based ULN through its TP to the edge nodes when its internal schedule indicates that link(s) should be up and the other node(s) reachable. In turn, those participating edge nodes can advertise their own credentials and local topology so that the router can confirm its own reachability (and possibly also link metrics as seen by the nodes). After that, the router can include those edge nodes in its own local topology advertisement so that each edge can observe that its peer nodes are reachable indirectly via that router.¶
This scenario can be extrapolated to any number of edge nodes operating on the same time-varying ULN.¶
In this example, a BP router (Node A) has connectivity to an arbitrary ULN through one TP (index 0), able to reach nodes attached to that ULN or reachable via other routers, and to an IP-based ULN through another TP (index 1), through which it acts as a router (just as in Appendix B.1) as well as a gateway to other reachable nodes. This is depicted in Figure 29 for the BP topology layer.¶
+----------+ +--------+ +--------+
| Node A | | Node B | | Node C |
+--+----+--+ +----+---+ +----+---+
{0} {1} {0} {0}
| / \ | |
---------- | ------------' |
other ULN | '-----------------------------'
----------
In this scenario, it is an implementation or policy decision about whether or not the routing node advertises any or all of: the existence of its own TP index 0, any particular parameters associated with the other ULN, or any 1-hop neighbors on that other ULN. When possible, the router will avoid including CL instances associated with TP index 0 when advertising via TP index 1.¶
This scenario can be extrapolated to any number of edge nodes in the BP stub network accessing a larger network via a gateway.¶
In this example, a BP router (Node A) has connectivity to an IP-based ULN through one TP (index 0), through which it acts as a router for nodes on disjoint IP prefixes. This is depicted in Figure 30 for the BP topology layer, which does not explicitly show the multiple addresses assigned to router TP index 0.¶
+--------+ +--------+ +--------+
| Node A | | Node B | | Node C |
+----+---+ +----+---+ +----+---+
{0} {0} {0}
/ \ | |
| -------------' |
'------------------------------'
In this scenario, the BP topology is superficially identical to the example in Appendix B.1 but the router's TP is associated with multiple IP addresses, each in different prefix associated with a different edge node. This supporting network is depicted in Figure 28 for the IP underlayer, illustrating the separate IP interfaces and possible links in that topology layer.¶
+--------+
{}------->{}| Node B |
+--------+ +--------+
| Node A |
+--------+ +--------+
{}------->{}| Node C |
+--------+
This scenario can be extrapolated to any number of edge nodes operating on any number of disjoint ULNs, either through the same physical link or through any number of separate links.¶
The multi-homed scenario of Appendix B.3, which can be modeled as multiple ULN addresses associated with the same TP, can be generalized to a scenario where the routing node accesses different neighbors using entirely different ULN technologies.¶
In this example, a BP router (Node A) has connectivity to multiple ULN through multiple TPs, through which it acts as a router for nodes on disjoint underlayer network and/or link technologies. This is depicted in Figure 32 for the BP topology layer, which does not explicitly show the technologies associated with each TP or ULN.¶
+--------+ +--------+ +--------+
| Node A | | Node B | | Node C |
+--+---+-+ +----+---+ +----+---+
{0} {1} {0} {0}
| | | |
| '------------' |
'-------------------------------'
This scenario of a router reaching different neighbors through different protocol stacks, with BP being the consistent layer throughout, is typical of architectural discussion in the CCSDS.¶
Thanks to Sarah Heiner at JHU/APL for pre-draft review to make the document clear and readable in its first draft. Thanks to Leonardo Babun at JHU/APL for editorial review and feedback. Thanks to Oleksandr Nazymko at D3TN for trial implementation and editorial feedback.¶
This section is to be removed before publishing as an RFC.¶
[NOTE to the RFC Editor: please remove this section before publication, as well as the reference to [RFC7942] and [github-dtn-demo-agent].]¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations can exist.¶
An example implementation of the this draft of SAND has been created as a GitHub project [github-dtn-demo-agent] and is intended to use as a proof-of-concept and as a possible source of interoperability testing. This example implementation uses D-Bus as the CL-BP Agent interface, so it only runs on hosts which provide the Python "dbus" library.¶