Delay-Tolerant Networking Neighbor Messaging Protocol

1.4. Definitions Specific to This Protocol

This section contains definitions specific to the DTN Neighbor Messaging Protocol.¶

TBD

4.1. Map Key Conventions

This specification follows the pattern of [RFC8152] to use positive-valued map keys to indicate common parameters and negative-valued map keys to indicate type-specific parameters. This convention also applies to subordinate maps within NMP messages.¶

; Generic map label
label = int
; Generic map value
value = any

4.2. Convergence Layer Parameterization

Where the NHDP is concerned with interfaces supporting IP addresses, with relatively few parameterizations, the NMP must convey CL information needed to send bundles to the node-being-discovered. Because different CLs are likely to have varying parameter sets, each CL is encoded as a CBOR map following the conventions of Section 4.1. There are several common CL parameters related to network- and transport-layer: a DNS name or IPv4/IPv6 address used to communicate with the node, and information about transport security policy.¶

It is also an important distinction that the CL parameterization is about the capability of delivering bundles to the discovered node. It is not about ability of the node to transmit bundles, which may in fact be more 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 common CL parameters are listed below and correspond with the CDDL of Figure 5.¶

CL Type:

This item contains a CBOR int value identifying the type of CL being defined. Possible CL Type values are defined Section 6.3.¶

DNS Name:

This item contains a CBOR tstr value containing the fully qualified domain name (FQDN) which resolves to an address on which the CL is listening.¶

IP Address:

This item contains a CBOR bstr value containing the address in network byte order (big-endian), which is either 4 octets for IPv4 or 16 octets for IPv6 address.¶

Port Number:

This item contains a CBOR uint value indicating the transport-layer port number. If this parameter is absent the default (i.e., IANA assigned) port number is used.¶

Transport Security Required:

This item contains a CBOR bool value indicating whether transport security is required (true) or prohibited (false). If this parameter is absent there is no information about the required policy.¶

; Convergence Layer (CL) structure
cl-listen = $cl-listen .within cl-listen-structure
cl-listen-structure = {
    cl-key-type<int>,
    * label => value,
}
; Common parameters for CL map
cl-key-type<val> = (
    1: val,
)

cl-dns-name-list = (
    2: [1*tstr],
)

cl-net-addr-list = (
    3: [1*net-address],
)
net-address = ipv4-address / ipv6-address
ipv4-address = bstr .size 4
ipv6-address = bstr .size 16

cl-transport-port = (
    4: uint .lt 0xFFFF
)

cl-transport-sec-require = (
    5: bool
)

$cl-listen /= {
    cl-key-type<1>,
    ? cl-dns-name-list,
    ? cl-net-addr-list,
    ? cl-transport-port,
    ? cl-transport-sec-require,
}

$cl-listen /= {
    cl-key-type<2>,
    ? cl-dns-name-list,
    ? cl-net-addr-list,
    ? cl-transport-port,
    ? cl-transport-sec-require,
}

4.3. HELLO Message

The HELLO message is variable sized and indicates the CLs supported by the transmitting node and of all the neighbors known to the transmitting node.¶

; HELLO message content
$nmp-msg /= hello-msg
hello-msg = {
    msg-key-type<1>,
    hello-validity-time,
    ? hello-interval-time,
    hello-clset,
    ? hello-nodeset,
    ? hello-peerset,
}
; Message-type-specific parameters
hello-validity-time = (
    -1: time-duration,
)
hello-interval-time = (
    -2: time-duration,
)
; Duration in DTN units of milliseconds
time-duration = uint

hello-clset = (
    -5: [1*cl-listen],
)

hello-nodeset = (
    -3: [1*hello-node],
)
hello-node = [
    nodeid: eid,
    clset: [1*cl-listen]
]

hello-peerset = (
    -6: [*hello-peer],
)
hello-peer = [
    nodeid: eid,
    status: hello-link-status,
]
hello-link-status = &(
    HEARD: 1,
    SYMMETRIC: 2,
    LOST: 3,
)

5.2. Messaging Without Authentication

In environments where PKI is not available, the NMP¶

6.1. Well-Known DTN Endpoints

EDITOR NOTE: sub-registry to-be-created upon publication of this specification.¶

IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], a sub-registry titled "Well-Known DTN Endpoints" and initialize it with the contents of Table 1. The registration procedure is Expert Review. Because any service name can be encoded as a text string, there is no provision for private or experimental registrations.¶

Specifications of new well-known DTN endpoints need to define the encoded (uint) value as well as the meaning of the service. Specifications need to define how it should be used by BP agents and if there are any special restrictions on how bundles are to be treated (either routing or delivery) when this endpoint is used as a bundle destination.¶

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).¶

6.2. NMP Message Type

EDITOR NOTE: sub-registry to-be-created upon publication of this specification.¶

IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], a sub-registry titled "NMP Message Type" and initialize it with the contents of Table 2. 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 Message Type value (an int), as well as the other message parameters required and allowed. Specifications need to define how those CBOR parameters are used by a BP agent 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).¶

6.3. NMP Convergence Layer Type

EDITOR NOTE: sub-registry to-be-created upon publication of this specification.¶

IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], a sub-registry titled "NMP Convergence Layer Type" and initialize it with the contents of Table 3. 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 int), as well as the other CL parameters required and allowed. Specifications need to define how those CBOR parameters are used by a BP agent to transfer bundles to the referred-to 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).¶