One document matched: draft-irtf-dtnrg-ipnd-00.txt
Network Working Group R. Beverly
Internet-Draft D. Ellard
Intended status: Experimental BBN
Expires: February 10, 2010 August 9, 2009
DTN IP Neighbor Discovery (IPND)
draft-irtf-dtnrg-ipnd-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 10, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Beverly & Ellard Expires February 10, 2010 [Page 1]
Internet-Draft DTN-IPND August 2009
Abstract
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.
Beverly & Ellard Expires February 10, 2010 [Page 2]
Internet-Draft DTN-IPND August 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6
2.1. Unknown Neighbors . . . . . . . . . . . . . . . . . . . . 6
2.2. Enumerated Neighbors . . . . . . . . . . . . . . . . . . . 7
2.3. Beacon Message Format . . . . . . . . . . . . . . . . . . 7
2.3.1. Services . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Zero-length EID Beacons . . . . . . . . . . . . . . . 9
2.4. Connection Establishment . . . . . . . . . . . . . . . . . 9
2.5. Disconnection . . . . . . . . . . . . . . . . . . . . . . 10
3. Relation to Other Discovery Protocols . . . . . . . . . . . . 11
4. Implementation Experience . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Beverly & Ellard Expires February 10, 2010 [Page 3]
Internet-Draft DTN-IPND August 2009
1. Introduction
Delay and Disruption Tolerant Networks (DTNs) [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 is a variety of contexts including mobile
social networks, space communications, rural message delivery,
military networks, etc.
In many DTN scenarios, the identity and meeting schedule of other
participating nodes is not known in advance. Therefore, an important
primitive is Neighbor Discovery (ND), or the ability to dynamically
locate 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.
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. [TCPCLA]),
available routers (e.g. [PROPHET]), tunnels, etc. Newly discovered
nodes will then typically participate in bundle [RFC5050] routing and
delivery.
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.
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).
Beverly & Ellard Expires February 10, 2010 [Page 4]
Internet-Draft DTN-IPND August 2009
DTN IPND is designed to be simple, efficient, and general.
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.
The remainder of this document describes DTN IPND.
1.1. Terminology
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 [RFC2119].
The following terminology is used for describing DTN IPND.
Bundle: A PDU as defined in [RFC5050].
Node: A DTN entity in the network that receives and processes
bundles.
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.
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.
Beverly & Ellard Expires February 10, 2010 [Page 5]
Internet-Draft DTN-IPND August 2009
2. Protocol Description
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 Section 2.3, may be sent either as IP unicast, multicast,
or broadcast UDP packets. The beacon message content is agnostic to
the underlying transport mode.
Broadcast beacons are designed to reach unknown neighbors in
neighborhoods within the local network broadcast domain. Multicast
[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.
Broadcast and multicast discovery are described in Section 2.1. In
contrast, unicast beacons are sent only to explicitly known and
enumerated neighbors as described in Section 2.2.
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 [TCPCLA] or UDP [UDPCLA] CLA. The CLA then
negotiates the connection per its individual specification and
installs the appropriate next-hop routing information in the BPA.
2.1. Unknown Neighbors
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 [RFC1112] and multicast IGMP group membership [RFC3376].
IPND MAY support IP broadcast destinations. IPND multicast addresses
SHOULD be from the IANA assigned local network control block
224.0.0/24 [RFC3171]. This block of multicast addresses is
intentionally scoped to the local network to prevent dissemination to
the wider Internet.
IPND MAY also use other multicast addresses as required, such as
multicast addresses from the IANA assigned Internetwork Control Block
[RFC3171].
In all cases, IPND MUST support a configurable IP time-to-live value
for all beacon messages.
Beverly & Ellard Expires February 10, 2010 [Page 6]
Internet-Draft DTN-IPND August 2009
2.2. Enumerated Neighbors
IPND SHOULD support unicast beacons. IPND is primarily designed for
discovery of nodes in the current broadcast or multicast domain.
However, some situations mandate discovery across multiple Internet
IP overlay hops. Across the wide-area Internet, multicast or
broadcast discovery is not feasible. In such instances, the IP
addresses of potential neighbors must be explicitly enumerated.
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 overlay hops simply by
enumerating their addresses.
Note that unicast discovery scales with the square of the number of
enumerated nodes, i.e. one beacon packet per enumerated destination.
Therefore, unicast discovery is intended for relatively small numbers
of neighbors.
2.3. Beacon Message Format
Figure 1 depicts the format of beacon messages. Note that IPND
follows the DTN convention of using Self-Delimiting Numeric Values
(SDNVs) [SDNV] to represent variable length integers (denoted by *).
IPND MUST use UDP checksums to ensure correctness.
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 Len (*) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Len (*) | Canonical EID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Service Blocks (optional) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Beacon Message Format
The beacon message is comprised of the following fields:
o Version: A 1-byte field indicating the version of IPND that
constructed this beacon. The present document describes version
0x01 of IPND.
o Flags: A 1-byte field indicating IPND processing flags. Two flags
are currently defined. 0x00 indicates that no special processing
should be performed on the beacon. 0x01 indicates that no length
Beverly & Ellard Expires February 10, 2010 [Page 7]
Internet-Draft DTN-IPND August 2009
or local EID fields follow and allows for very short, efficient
beacons; see Section 2.3.2 for details.
o Beacon Length: The byte length of the beacon inclusive of the
entire beacon message, but exclusive of IP or UDP headers. The
length field is an SDNV and is therefore variable length. A two-
octet length is shown for convenience of representation.
o 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.
o 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 [RFC3986].
o Service Blocks: Optional announced services in the beacon,
described in Section 2.3.1.
2.3.1. Services
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.
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. [PROPHET]) are running on a remote node in order to inform
bundle exchange.
Therefore, beacons may contain service blocks. 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:
service block length = v(b) - 2 - l(b) - l(e) - v(e)
Beverly & Ellard Expires February 10, 2010 [Page 8]
Internet-Draft DTN-IPND August 2009
The format of a service block is given in Figure 2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name Len (*) | Service Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Param Len (*) | Service Parameters (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Service Block Format
A service block is comprised of the following fields:
o 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.
o Service Name: An identifying name for the service, e.g. "UDPCLA."
o 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.
o Service Parameters: Service-specific parameters required to use
the service, e.g. "port=4453."
2.3.2. Zero-length EID Beacons
A beacon with a 0x01 flag has special meaning and indicates a "zero-
length EID." IPND MUST support zero-length EID beacons. Neither the
beacon length, canonical EID, nor any service block fields are
present in these beacons, and the total length of the beacon is
therefore only two octets. Nodes SHALL assume that the canonical EID
of a zero-length EID is the dotted-quad URI representation of the
beacon's source IP address.
Zero-length beacons imply that any remote node receiving the beacon
may connect via the source IP address of the beacon, using the UDP
CLA on UDP port 4556. This optimization is made for efficiency and
ease of implementation reasons, for instance in constrained scenarios
where devices are unwilling or unable to implement SDNV and a default
connection procedure suffices.
2.4. Connection Establishment
Once IPND discovers a new node and the connection parameters, it may
initiate the connection. The exact means by which IPND communicates
with the CLAs is implementation dependent. The specified CLA should
establish the connection using the methods and conventions defined
Beverly & Ellard Expires February 10, 2010 [Page 9]
Internet-Draft DTN-IPND August 2009
for that CLA.
Note that two nodes may discover each other simultaneously and
attempt to initiate connections simultaneously. In instances of uni-
directional CLAs, IPND must provide uni-directional discovery.
However, in general, bi-direction CLAs such as TCP should attempt to
form a single connection rather than two separate connections. IPND
does not discern between uni and bi-directional connections or
address potential race conditions in bilateral connection
establishment.
2.5. Disconnection
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.
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.
Beverly & Ellard Expires February 10, 2010 [Page 10]
Internet-Draft DTN-IPND August 2009
3. Relation to Other Discovery Protocols
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 [RFC3927], the bonjour protocol [BONJOUR], and the OLSR
discovery protocol [NHDP] all provide similar functionality.
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.
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.
While DTN-IPND MAY be used in non-DTN environments, its use is
RECOMMENDED only in DTNs.
Beverly & Ellard Expires February 10, 2010 [Page 11]
Internet-Draft DTN-IPND August 2009
4. Implementation Experience
BBN Technologies has implemented and deployed DTN IPND as part of the
SPINDLE [SPINDLE] project.
Beverly & Ellard Expires February 10, 2010 [Page 12]
Internet-Draft DTN-IPND August 2009
5. Security Considerations
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.
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.
Beverly & Ellard Expires February 10, 2010 [Page 13]
Internet-Draft DTN-IPND August 2009
6. IANA Considerations
None at this time.
Beverly & Ellard Expires February 10, 2010 [Page 14]
Internet-Draft DTN-IPND August 2009
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
7.2. Informative References
[BONJOUR] Cheshire, S., "Bonjour", Apr 2005.
[NHDP] Clausen, T., Dearlove, C., and J. Dean, "MANET
Neighborhood Discovery Protocol (NHDP)", Mar 2009.
[PROPHET] Lindgren, A. and A. Doria, "Probabilistic Routing Protocol
for Intermittently Connected Networks", Mar 2006.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[SDNV] Eddy, W., "Using Self-Delimiting Numeric Values in
Protocols", Jan 2009.
[SPINDLE] Krishnan, R., "Survivable Policy-Influenced Networking:
Disruption-tolerance through Learning and Evolution",
Beverly & Ellard Expires February 10, 2010 [Page 15]
Internet-Draft DTN-IPND August 2009
Oct 2006.
[TCPCLA] Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
Convergence Layer Protocol", Nov 2008.
[UDPCLA] Kruse, H. and S. Ostermann, "UDP Convergence Layers for
the DTN Bundle and LTP Protocols", Nov 2008.
Beverly & Ellard Expires February 10, 2010 [Page 16]
Internet-Draft DTN-IPND August 2009
Authors' Addresses
Robert Beverly
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
US
Email: rbeverly@bbn.com
Daniel Ellard
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
US
Email: dellard@bbn.com
Beverly & Ellard Expires February 10, 2010 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 09:10:05 |