One document matched: draft-irtf-dtnrg-ipnd-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1112 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3171 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3171.xml'>
<!ENTITY rfc3376 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml'>
<!ENTITY rfc3927 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml'>
<!ENTITY rfc3986 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY rfc4838 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml'>
<!ENTITY rfc5050 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml'>
]>
<rfc category="exp" ipr="trust200902" docName="draft-irtf-dtnrg-ipnd-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<!--
$Id: draft-irtf-dtnrg-ipnd.xml 4785 2010-03-08 21:20:32Z dbrown $
$Author: dbrown $
$Date: 2010-03-08 16:20:32 -0500 (Mon, 08 Mar 2010) $
-->
<front>
<title abbrev="DTN-IPND">DTN IP Neighbor Discovery (IPND)</title>
<author initials='D.' surname="Ellard" fullname='Daniel Ellard'>
<organization>
Raytheon BBN Technologies
</organization>
<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city> <region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<email>dellard@bbn.com</email>
</address>
</author>
<author initials='D.' surname="Brown" fullname='Daniel W. Brown'>
<organization>
Raytheon BBN Technologies
</organization>
<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city> <region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<email>dbrown@bbn.com</email>
</address>
</author>
<date/>
<abstract>
<t>
Disruption Tolerant Networking (DTN) IP Neighbor Discovery
(IPND), is a method for otherwise oblivious nodes to learn of the
existence, availability, and addresses of other DTN participants.
IPND both sends and listens for small IP UDP announcement
"beacons." Beacon messages are addressed to an IP unicast, multicast,
or broadcast destination to discover specified remote
neighbors, or unspecified local neighbors in the topology, e.g.
within wireless range. IPND beacons advertise neighbor
availability by including the DTN node's canonical endpoint
identifier. IPND beacons optionally include service availability
and parameters. In this way, neighbor discovery and service
discovery may be coupled or decoupled as required. Once
discovered, new neighbor pairs use advertised availabilities
to connect, exchange routing information, etc. This document
describes DTN IPND.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Delay and Disruption Tolerant Networks (DTNs) <xref
target="RFC4838"/> make no presumptions about network topology,
routing, or availability. DTNs therefore attempt to provide
communication in challenged environments where, for instance,
contemporaneous end-to-end paths do not exist. Examples of such
DTNs arise in a variety of contexts including mobile social
networks, space communications, rural message delivery, military
networks, etc.
</t>
<t>
In many DTN scenarios, the identity and meeting
schedule of participating nodes is not known in advance.
Therefore, an important primitive is Neighbor Discovery (ND), or
the ability to dynamically discover other DTN nodes. This document
specifies Internet Protocol Neighbor Discovery (IPND). In
contrast to link or physical layer discovery, IPND enables a
general form of neighbor discovery across a heterogeneous range
of links, as are often found in DTN networks. IPND is particularly
useful in mobile, ad-hoc DTN environments where meeting
opportunities are not known a priori and connections may appear
or disappear without warning. For example, two mobile nodes
might come into radio distance of each other, discover the new
connection, and move data along that connection before physically
disconnecting.
</t>
<t>
In addition to discovering neighbors, it is often valuable to
simultaneously discover services available from that neighbor.
Examples of DTN services include a neighbor's available
Convergence Layer Adapters (CLAs) and their parameters (e.g.
<xref target="TCPCLA"/>), available routers (e.g. <xref
target="PROPHET"/>), tunnels, etc. Newly discovered nodes will
then typically participate in bundle <xref target="RFC5050"/>
routing and delivery.
</t>
<t>
In other situations it is useful to decouple service
discovery from neighbor discovery for efficiency and generality.
For example, upon discovering a neighbor, a DTN node might
initiate a separate negotiation process to establish 1-hop
connectivity via a particular convergence layer, perform routing
setup, exchange availability information, etc.
</t>
<t>
IPND beacons thus optionally advertise a node's available
services while maintaining the ability to decouple node and
service discovery as necessary. This flexibility is important to
various DTN use scenarios where connection opportunities may be
limited (thus necessitating an atomic message for all
availability information), bandwidth might be scarce (thus
implying that service discovery should be an independent
negotiation to lower beacon overhead), or connections have very
large round-trip-times (service negotiation is therefore too
costly with respect to time).
</t>
<t>
DTN IPND is designed to be simple, efficient, and general.
</t>
<t>
Although this document describes a neighbor discovery protocol
in terms of IP, the principles and basic mechanisms used in this
protocol may also be expressed in terms of other datagram protocols.
</t>
<t>
The remainder of this document describes DTN IPND.
</t>
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
The following terminology is used for describing DTN IPND.
</t>
<t>
<list style="hanging">
<t hangText="Bundle"> A PDU as defined in <xref target="RFC5050"/>.</t>
<t hangText="Node"> A DTN entity in the network that receives and
processes bundles.</t>
<t hangText="Beacon message"> An IPND-specific message, defined in
this document, used to announce the presence of a
DTN node and parameters with which to connect to that
node.</t>
<t hangText="Convergence layer adapter"> A convergence layer adapter
(CLA) sends and receives bundles on behalf of a node by
providing the conversion between bundles and a transport
protocol such as TCP or UDP.</t>
</list>
</t>
</section>
</section>
<section title="Protocol Description">
<t>
Nodes use DTN IPND beacons, small UDP messages in the IP
underlay, to advertise presence. Similarly, IPND beacons
received from other nodes serve to detect the availability of DTN
neighbors. Nodes SHOULD both send and receive beacons. These
beacon messages, detailed in <xref target="beacons"/>, may be
sent either as IP unicast, multicast, or broadcast UDP packets.
The beacon message content is agnostic to the underlying
transport mode.
</t>
<t>
Broadcast beacons are designed to reach unknown neighbors in
neighborhoods within the local network broadcast domain.
Multicast <xref target="RFC1112"/> beacons extend the scope of
beacon dissemination to potentially include multiple networks
across routed boundaries. On broadcast media such as Ethernet or
wireless, multicast and broadcast beacons are sent as link-layer
broadcast messages.
</t>
<t>
Broadcast and multicast discovery are described in <xref
target="multicast"/>. In contrast, unicast beacons are sent only
to explicitly known and enumerated neighbors as described in
<xref target="unicast"/>.
</t>
<t>
Upon discovering a neighbor, IPND can establish a connection
to the new neighbor via an IP-based Convergence Layer Adapter
(CLA), for example the TCP <xref target="TCPCLA"/> or UDP <xref
target="UDPCLA"/> CLA. The CLA then negotiates the connection
per its individual specification and installs the appropriate
next-hop routing information in the local node.
</t>
<section title="Beacon Period" anchor="beacon_period">
<t>
An IPND implementation SHOULD send beacons periodically. The
time interval between beacons SHOULD be appropriate for the
conditions of the network and MAY be configurable.
</t>
<t>
A receiving node SHOULD know the expected beacon interval and
use this parameter, along with the existence and time of
received beacons to determine whether state of the sender's
ability to transmit to the receiver, i.e., the up or down
state of the sender to receiver link. The exact algorithm for
determining the link status based on received beacons is
implementation-defined.
</t>
</section>
<section title="Unknown Neighbors" anchor="multicast">
<t>
In the general case, the IP addresses of potential
neighbors are not known in advance. To discover unknown
neighbors, IPND beacon messages are sent as IP packets with
either multicast or broadcast destination addresses. IPND MUST
support multicast IP destination addresses <xref
target="RFC1112"/> and multicast IGMP group membership <xref
target="RFC3376"/>. IPND MAY support IP broadcast destinations.
IPND multicast addresses SHOULD be from the IANA assigned local
network control block 224.0.0/24 <xref target="RFC3171"/>. This
block of multicast addresses is intentionally scoped to the local
network to prevent dissemination to the wider Internet.
</t>
<t>
IPND MAY also use other multicast addresses as required, such as
multicast addresses from the IANA assigned Internetwork Control
Block <xref target="RFC3171"/>.
</t>
<t>
In all cases, IPND MUST support a configurable IP time-to-live
value for all beacon messages.
</t>
</section>
<section title="Enumerated Neighbors" anchor="unicast">
<t>
IPND MUST support multicast or broadcast beacons and SHOULD support
both.
IPND SHOULD support unicast beacons. Since multicast or broadcast
discovery is not feasible over internetworks, the IP addresses of
potential neighbors reachable only across multiple underlay hops must be
explicitly enumerated for discovery. While the neighbor's address is therefore
known, the availability of that neighbor is not known. IPND thus
permits DTN nodes to discover available remote neighbors across
multiple IP underlay hops when provided with the addresses of those neighbors.
In
this way, IPND can be used to bridge IP-based DTNs while detecting
disconnections among and between the DTNs.
</t>
</section>
<section title="Allowing Data to Substitute for Beacons" anchor="suppress">
<t>
Sending data to an IP address matching a configured beacon destination
SHOULD suppress the generation of beacon messages to that destination
for a period of time up to but no longer than the beacon sending interval.
This suppression SHOULD NOT occur if the
parameters of a new beacon message would differ from the preceding
beacon including the <xref target="services"> advertised services </xref>
or <xref target="neighborhood_bloomfilter"> Neighborhood Bloom Filter (NBF)</xref>.
</t>
<t>
Upon receiving a data packet from a neighbor where
the packets do not represent a beacon, a node SHOULD behave as
if a beacon had been received from that neighbor, as follows.
If the data packet is addressed to this node via a unicast address,
then the behavior SHOULD be as if the implied received beacon
contains a Neighborhood Bloom Filter which indicates the membership
of the receiving node in the sender's 1-hop neighborhood.
Otherwise, if the destination address is multicast or broadcast,
then the receiving node should presume that the link is
bidirectional if and only if its state was bidirectional prior to
receiving the data packet. See <xref target="bidirectional"/>.
The sender's advertised services are presumed to be unchanged
since the sender's last received beacon. If no beacons have
previously been received from such a neighbor, then
it is presumed that there are no services associated with the sender.
</t>
</section>
<section title="Discovering Bidirectional Links" anchor="bidirectional">
<t>
Many routing protocols work correctly only when links are bidirectional.
In wired IP networks, link bidirectionality can often be presumed.
For other types of networks, such as Mobile Ad-Hoc Networks (MANETs) this
assumption often does not hold. If a link to a neighbor is said to be
"up" only because one or more beacon messages have been received from
that neighbor over a wireless medium, it is not generally safe
to assume that the link is bidirectional. In practice, MANET networks
often have links that are only unidirectional due to differences
in antennae, transmit power, hardware variability, multi-path
effects, etc.
</t>
<t>
To discover the bidirectionality of links, an IPND
<xref target="neighborhood_bloomfilter">Neighborhood
Bloom Filter (NBF) </xref> facility MAY be employed in which each
node advertises a Bloom filter representation of the set of
neighbors from whom it has
received enough recent beacons to be considered "up". Upon receiving
a beacon from an "up" neighbor that advertises an NBF which
represents a set containing
the receiving node's ID, then the link SHOULD be considered
bidirectional.
</t>
</section>
<!-- TODO: say something about linkchar -->
<section title="Beacon Message Format" anchor="beacons">
<t>
<xref target="beaconmsg"/> depicts the format of beacon messages.
Note that IPND follows the DTN convention of using Self-Delimiting
Numeric Values (SDNVs) <xref target="SDNV"/> to represent
variable length integers (denoted by *). IPND MUST use UDP
checksums to ensure correctness.
</t>
<figure title="Beacon Message Format" anchor="beaconmsg">
<artwork type="drawing">
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Flags | Beacon Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Len (*) | Canonical EID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Service Block (optional) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBF Length (*) (optional) | NBF Bloom Filter Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The beacon message is comprised of the following fields:
<list style="symbols">
<t>Version: An 8-bit field indicating the version of IPND
that constructed this beacon. The present document
describes version 0x02 of IPND. This version field is
incremented for IPND if either the IPND protocol is modified
or the Bundle Protocol version is incremented. In this way
the field can also be used to determine the BP version
supported by a potential DTN neighbor.</t>
<t>Flags: An 8-bit field indicating IPND processing flags.
Two flags are currently defined. 0x00 indicates that
no special processing should be performed on the beacon.
Semantics of bits are described here from least significant (LSb)
to most significant (MSb).
<list style="hanging">
<t hangText="Bit 0">
Source EID present: iff set, indicates that the source node's EID is
present in the beacon. If the EID is present, it is preceded
by an SDNV indicating its length.</t>
<t hangText="Bit 1">
Service Block present: iff set, indicates that a service block is present.
</t>
<t hangText="Bit 2">
Neighborhood Bloom Filter present: iff set, indicates that a Neighbor Bloom Filter is
present.
</t>
</list>
</t>
<t>Beacon sequence number: A two-octet unsigned integer value incremented
once for each beacon transmitted to a particular IP address.</t>
<t>EID Length: The byte length of the canonical EID contained
in the beacon. The EID length field is an SDNV and is
therefore variable length. A two-octet length is shown for
convenience of representation.</t>
<t>Canonical EID: The canonical end node identifier of the neighbor
advertised by the beacon message. The canonical EID is
variable length and represented as a Uniform Resource
Identifier <xref target="RFC3986"/>.</t>
<t><xref target="services">Service Blocks:</xref> Optional announced services in the beacon.</t>
<t><xref target="neighborhood_bloomfilter">Neighborhood Bloom Filter:</xref>
Optional length-prefixed bitfield
representing the source node's 1-hop neighborhood.</t>
</list>
</t>
<section title="Services" anchor="services">
<t>
As described previously, beacon messages may optionally
include service availability information. The services are
intended to represent available CLAs, routers, etc., but are
sufficiently general to accommodate unanticipated services
provided by the advertising node.
</t>
<t>
For example, the source IP address of a received beacon
suffices to identify the remote node at the IP level. However,
the IP address alone does not inform other processes via which
transport mechanism (e.g. TCP or UDP) or via which transport port
the remote node is offering a connection. Similarly, nodes do
not know which routers (e.g. <xref target="PROPHET"/>) are
running on a remote node in order to inform bundle exchange.
Therefore, beacons may contain service blocks.
</t>
<!--
<t>
An
end-node determines the length of the announced service blocks
as follows:
a node parses the beacon length and EID length SDNV
fields. Let v(b) represent the value of the beacon length and
v(e) represent the value of the EID length. The SDNV
representation of beacon and EID length is itself variable
length. Let l(b) represent the on-wire length of the beacon
length SDNV and l(e) represent the on-wire length of the EID
length SDNV. The total byte length of any option service blocks
is then:
</t>
<figure><artwork>
service block length = v(b) - 2 - l(b) - l(e) - v(e)
</artwork></figure>
-->
<t>
The format of a service block is given in <xref
target="servicesmsg"/>.
</t>
<figure title="Service Block Format" anchor="servicesmsg">
<artwork type="drawing">
+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of services (*) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name Len (*) | Service Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service 1
| Service Param Len (*) | Service Parameters (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name Len (*) | Service Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service 2
| Service Param Len (*) | Service Parameters (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
</artwork>
</figure>
<t>
A service block is comprised of the following fields:
<list style="symbols">
<t>Number of services: The number of services described in
the block.</t>
<t>Service Name Length: The length of the advertised service
name or description. The service name length is an SDNV and
is therefore variable length. The service name MUST
have non-zero length.</t>
<t>Service Name: An identifying name for the service, e.g.
"UDPCLA."</t>
<t>Service Parameters Length: The length of service-specific
parameters that accompany this announcement. The service
parameters length is an SDNV and is therefore variable
length.</t>
<t>Service Parameters: Service-specific parameters required
to use the service, e.g. "port=4453."</t>
</list>
</t>
</section>
<section title="Neighborhood Bloom Filter" anchor="neighborhood_bloomfilter">
<t>
In order to efficiently determine link bidirectionality, a node
represents the set of its 1-hop neighbors using a Bloom filter
referred to as the Neighborhood Bloom Filter (NBF). Upon
receiving a beacon from a neighbor that contains an NBF,
a node can quickly determine whether it is in the neighbor's
NBF set, and thereby determine whether the link is bidirectional.
</t>
<t>
Every node that might operate in an environment where discovered
links may not be bidirectional SHOULD include a Bloom filter
in some of its beacons which describes the membership of its 1-hop
neighbor set. The bits to set in the Bloom filter MUST
be computed by computing hash(es) on the canonical EID of each
1-hop neighbor considered to be "up".
</t>
<t>
Different networks naturally have distinct
requirements, tolerance for overhead, and node computing
resources, so the parameters of the Bloom filter such as
length, number and types of hash algorithms, etc., are
not mandated by IPND. However, all nodes participating in
such a DTN MUST use the same Bloom filter representation and
parameters if they send Bloom filters.
</t>
<t>
Bloom filter data, if present, MAY be ignored by a node if its
implementation does not provide for it, or if the parameters
of the Bloom filter cannot be determined with certainty.
</t>
<t>
Nodes in DTNs with a likelihood of unidirectional links
SHOULD provide Bloom filter data in
some broadcast or multicast beacons if the routing protocol
in use presumes that links are bidirectional.
</t>
<t>
A neighborhood Bloom filter need not be included on every beacon,
but one SHOULD be present on at least one broadcast or multicast
beacon following a change in the 1-hop neighborhood of the node.
A neighborhood Bloom filter MAY be present on every broadcast or
multicast beacon beacon.
</t>
<t>
A Bloom filter, if included in a beacon message, MUST be represented
by an SDNV, and MUST follow Service Blocks
field, if present, or the Canonical EID field if the Service Blocks
field is not present.
</t>
</section>
</section>
<!--
RB: COMMENT OUT THE FOLLOWING AS THEY'RE MOST IMPLEMENTATION
DETAILS THAT DON'T NEED TO BE NEGOTIATED OR INTERPRETED
BETWEEN NEIGHBORS AT THIS TIME.
-->
<!--
<section title="Parameters" anchor="params">
<t>
It is RECOMMENDED that implementations of IPND provide the
following configurable parameters:
</t>
<t>Parameters:
<list style="hanging" hangIndent="5">
<t hangText="BeaconAddress:">IPv4 address string specifying the beacon
address destination. As described previously, the beacon address
may be either IP unicast, multicast, or broadcast.
</t>
<t hangText="BeaconIPTTL:">Time-to-live specifying the beacon
IPv4 TTL value.
<vspace blankLines="1" />
Unless beacon messages are intended to be disseminated beyond the local
link, the BeaconIPTTL should always be 1.
</t>
<t hangText="BeaconPeriod:">Integer wall clock time between
sending periodic beacon messages. The inter-beacon delay granularity
SHOULD be at least 1 millisecond.
</t>
<t hangText="NeighborRecvTimeout:">The neighbor receive
timeout period. A minimum integer wall clock time
that MAY pass without receiving a beacon before declaring an existing
neighbor unreachable. The neighbor receive timeout SHOULD be at
least millisecond granularity.
</t>
</list>
</t>
<t>
The BeaconPeriod and NeighborRecvTimeout parameters should be
chosen to reflect the expected properties of the network connection
between two nodes that discover each other via this protocol and the
requirements of the users of the network. A typical BeaconPeriod for
most purposes would be on the order of several seconds, and a typical
NeighborRecvTimeout is a multiple of the BeaconPeriod.
</t>
</section>
-->
<section title="IPND and CLAs">
<t>
IP-based CLAs are generally expected to depend on an
IPND implementation module for their discovery
service. A CLA MAY opt not to use IPND, either because
that CLA does not require discovery or provides its own.
</t>
<t>
Once IPND discovers a new neighbor it MUST inform all
CLAs which depend on IPND of the
neighbor's existence and the discovered parameters. The exact means
by which IPND communicates with the CLAs is implementation
dependent.
</t>
<t>
Similarly, once IPND determines that a link has gone down, it
MUST inform all dependent CLAs of the link down event.
</t>
</section>
<section title="Disconnection">
<t>
Note that IPND SHOULD maintain state over all existing neighbors
in order to prevent CLAs from needlessly attempting to establish
connections between nodes that are already connected. To maintain
the current neighbor set, IPND removes stale neighbors after the
defined neighbor receive timeout period elapses without receiving
any beacon messages from a particular neighbor.
</t>
<t>
Upon detecting a neighbor that is no longer available, IPND
MAY provide hints to the CLA that the neighbor is gone. Note
that some CLAs themselves provide keepalive-type functionality
and therefore IPND is not necessarily required to detect down
neighbors. However, placing both discovery and availability
information in IPND provides a single, coherent point in the
system design to maintain neighbor information.
</t>
</section>
</section>
<section title="Relation to Other Discovery Protocols">
<t>
A variety of discovery protocols exist in other contexts
and domains. These discovery protocols include the ability to
discover available neighbors and services. For example, the IETF
zero configuration working group <xref target="RFC3927"/>, the
bonjour protocol <xref target="BONJOUR"/>, and the OLSR discovery
protocol <xref target="NHDP"/> all provide similar functionality.
</t>
<t>
Other rendezvous mechanisms are possible that allow a node to
find a neighbor of a particular type or with particular
properties. For example, the Domain Name System (DNS) or
Distributed Hash Tables (DHTs) could be used to find a neighbor
that provides an inter-planetary gateway. Such advanced
rendezvous schemes are beyond the scope of this document.
</t>
<t>
In contrast, DTN-IPND is designed to be DTN-specific,
efficient, and extremely lightweight. For instance, DTN-IPND is
capable of supporting arbitrary length DTN EIDs, and includes CLA
information in order to maximize the utility of each beacon
message without requiring multiple round-trip times in order to
perform complex protocol negotiation.
</t>
<t>
While DTN-IPND MAY be used in non-DTN environments, its use is
RECOMMENDED only in DTNs.
</t>
</section>
<section title="Implementation Experience">
<t>
BBN Technologies has implemented and deployed DTN IPND as part of
the SPINDLE <xref target="SPINDLE"/> project.
</t>
</section>
<section title="Security Considerations">
<t>
Neighbor discovery may be perceived as an impediment to
security because it advertises a potential target for attacks.
Discovering the existence of a particular node is orthogonal to
securing the services of that node. Nodes that desire or require
higher-levels of security SHOULD disable the broadcast IPND
beacons and rely instead on static neighbor configuration.
</t>
<t>
Further, neighbor discovery represents a potential source of
network congestion and contention. Therefore, careful
consideration should be made to the frequency and TTL scope of
beacons when setting implementation-specific parameters,
particularly when a setting affects larger regions of the
network.
</t>
</section>
<section title="IANA Considerations">
<t>
None at this time.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3986;
</references>
<references title="Informative References">
&rfc1112;
&rfc3171;
&rfc3376;
&rfc3927;
&rfc4838;
&rfc5050;
<reference anchor="PROPHET">
<front>
<title>Probabilistic Routing Protocol for Intermittently
Connected Networks
</title>
<author initials="A." surname="Lindgren">
<organization abbrev="Lulea">
Lulea University of Technology
</organization>
</author>
<author initials="A." surname="Doria">
<organization abbrev="Lulea">
Lulea University of Technology
</organization>
</author>
<date month="Mar" year="2006" />
</front>
<format type='HTML'
target='http://www.dtnrg.org/docs/specs/draft-lindgren-dtnrg-prophet-02.txt' />
</reference>
<reference anchor="TCPCLA">
<front>
<title>Delay Tolerant Networking TCP Convergence Layer Protocol
</title>
<author initials="M." surname="Demmer">
<organization abbrev="UCB">
UC Berkeley
</organization>
</author>
<author initials="J." surname="Ott">
<organization abbrev="HELFI">
Helsinki University of Technology
</organization>
</author>
<date month="Nov" year="2008" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-irtf-dtnrg-tcp-clayer-02.txt' />
</reference>
<reference anchor="UDPCLA">
<front>
<title>UDP Convergence Layers for the DTN Bundle
and LTP Protocols
</title>
<author initials="H." surname="Kruse">
<organization abbrev="OhioU">
Ohio University
</organization>
</author>
<author initials="S." surname="Ostermann">
<organization abbrev="OhioU">
Ohio University
</organization>
</author>
<date month="Nov" year="2008" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-irtf-dtnrg-udp-clayer-00.txt' />
</reference>
<reference anchor="SDNV">
<front>
<title>Using Self-Delimiting Numeric Values in
Protocols
</title>
<author initials="W." surname="Eddy">
<organization abbrev="Verizon">
Verizon
</organization>
</author>
<date month="Jan" year="2009" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-irtf-dtnrg-sdnv-01.txt' />
</reference>
<reference anchor="NHDP">
<front>
<title>MANET Neighborhood Discovery Protocol (NHDP)
</title>
<author initials="T." surname="Clausen">
<organization abbrev="lix">
LIX, Ecole Polytechnique
</organization>
</author>
<author initials="C." surname="Dearlove">
<organization abbrev="BAE">
BAE Systems ATC
</organization>
</author>
<author initials="J." surname="Dean">
<organization abbrev="NRL">
Naval Research Laboratory
</organization>
</author>
<date month="Mar" year="2009" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-ietf-manet-nhdp-09.txt' />
</reference>
<reference anchor="SPINDLE">
<front>
<title>Survivable Policy-Influenced Networking:
Disruption-tolerance through Learning and Evolution
</title>
<author initials="R." surname="Krishnan">
<organization abbrev="BBN">
BBN Technologies
</organization>
</author>
<date month="Oct" year="2006" />
</front>
<format type='HTML'
target='http://www.ir.bbn.com/projects/spindle' />
</reference>
<reference anchor="BONJOUR">
<front>
<title>Bonjour
</title>
<author initials="S." surname="Cheshire">
<organization abbrev="Apple">
Apple, Inc.
</organization>
</author>
<date month="Apr" year="2005" />
</front>
<format type='HTML'
target='http://www.apple.com/bonjour' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:41:45 |