Network Working Group Rob Enns
INTERNET DRAFT Pedro Marques
Expiration Date: November 2003 Juniper Networks
Daemon Morrell
May 2003
Device Discovery Protocol (DDP)
draft-marques-ddp-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
The Device Discovery Protocol (DDP) allows network elements to
discover adjacent devices without relying on consistent network layer
configuration.
draft-marques-ddp-00.txt [Page 1]
Internet Draft draft-marques-ddp-00.txt May 2003
1. Introduction
When configuring a network device or performing diagnostics, it is
often helpful for a network operator to have information about other
directly adjacent network devices that may be present.
This protocol defines a low overhead mechanism which detects and
maintains information about adjacent systems, without requiring
consistent or correct network layer configuration, such as IP
addresses.
The protocol works by generating periodic 'Hello' messages containing
basic properties of the device such as hostname and IP address
configuration. Information collected from Hellos received from
neighboring devices is cached so that it can be presented to the user
on demand.
2. DDP Hello messages
DDP Hellos consist of a fixed header plus several system and
interface attributes encoded as a sequence of SNMP [RFC3416] variable
bindings (<OID, Value> pairs). This allows DDP to reuse syntax and
semantic definitions from existing MIBs and to be extensible via the
definition of new MIBs.
SNMP MIB-II [RFC1213], which defines managed objects that express
information about basic system attributes, is implemented almost
universally by networking devices. It is expected that DDP
implementations will be able to reuse both code and data content from
their existing SNMP support.
DDP Hellos can be seen as the equivalent of periodic SNMP traps sent
to a link-local multicast address.
DDP Hello messages are encapsulated in IP datagrams and transmitted
to a link-local IP multicast address.
2.1. IP header values
When generating a DDP Hello message, the following IP parameters
should be used:
IP Protocol
The IP Protocol value is TBD (via IANA assignment).
Time to Live
draft-marques-ddp-00.txt [Page 2]
Internet Draft draft-marques-ddp-00.txt May 2003
A TTL value of 1 is used.
TOS
A TOS value of 0.
Source Address
The device IP address on the interface if one has been
configured (or learned though an address assignment
mechanism). Otherwise 0.0.0.0 SHOULD be used.
Destination Address
The link-local scope multicast address 224.0.0.x assigned to
DDP (IANA).
2.2. DDP Hello header format
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 | Hold Time | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Device ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
This document defines version 1 of this protocol.
Hold Time
Maximum interval of time a receiver should cache this
information, in seconds.
Checksum
The 16 bit one's complement checksum [RFC1071] of the DDP
Hello message, including the fixed header (but excluding the
IP header).
Device Identifier
An indentifier believed to be unique for the device, encoded
draft-marques-ddp-00.txt [Page 3]
Internet Draft draft-marques-ddp-00.txt May 2003
in IEEE EUI-64 format [EUI64]. The device identifier
pameter is discussed in detail in Section 3.
2.3. Attributes
The body of a DDP Hello message, when non-empty, is a variable
binding list as defined by SNMP.
-- variable-binding list
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
VarBind ::=
SEQUENCE {
name ObjectName,
value ObjectSyntax
}
A variable-binding list, contained in a DDP Hello, is serialized
using the the Basic Enconding Rules [BER] with the additional
restrictions defined in Section 8 of RFC3417 [RFC3417].
3. Device Indentifier
DDP speaking devices MUST advertise the same identifier on all
generated Hello messages, for all interfaces. This identifier MAY be
constructed from a IEEE 48bit MAC address when one is present on the
system, according to the rules specified by the IEEE.
Absent a MAC address or other interface token, the device should
generate a local-scope EUI-64 identifier, with the "u" bit set to one
(1), via an implementation specific procedure likely to generate an
unique number.
When using a hardware token, such as a MAC address, the same
indentifier SHOULD be used across software restarts.
draft-marques-ddp-00.txt [Page 4]
Internet Draft draft-marques-ddp-00.txt May 2003
4. Maximum message length
The length of DDP Hello messages SHOULD be limited such that:
length <= MIN(1500, link MTU) - IP header length.
In links that support MTUs larger than 1500 bytes it is common to
find MTU misconfigurations where, for example, one end of a point-to-
point circuit is configured to a lower MTU value than the other end.
DDP can be useful in diagnosing such situations. Limiting the IP
datagram size to what is the most common MTU size may avoid the such
messages to be discarded at the link-layer.
This procedure also avoids the recurse to IP fragmentation. Data
segmentation at the application level is generally considered to be
preferable to IP fragmentation given that loss of one IP fragment
results in the need to discard any other IP fragment of the same
datagram. IP fragmentation can also lead to excessive resource
consumption, specially in the case of broadcasted or multicasted
packets. Such resource requirements may prove limiting in small
embedded systems.
When the attributes that a DDP speaker wishes to advertise exceed the
maximum message leght on a given interface, the sender should
generate multiple Hello messages, each containing a subset of the
attributes the sender wishes to advertise. The full set of attributes
should be transmited every advertising period.
5. Protocol operation
Received DDP Hello messages update the attributes associated with a
given Device Identifier. The receiver MAY choose to cache the all or
part of the received attributes upto the maximum Hold Time specified
by the sender.
The receiver of a DDP Hello message MAY wish to compare the length
and data checksum of the received packet with information it has
cached for that Device ID. In case of a match, it MAY ignore the
newly received Hello message and refresh the expiration time of the
cached information.
The default period for generating DDP Hello messages SHOULD be 60
seconds. Periodic timers should be jittered and SHOULD be different
between different interfaces.
Upon orderly shutdown, a DDP speaker SHOULD generate an update
containing a 0 Hold Time value so that neighboring devices can purge
draft-marques-ddp-00.txt [Page 5]
Internet Draft draft-marques-ddp-00.txt May 2003
their respective caches.
6. Configuration
A device that implements DDP SHOULD enable the protocol by default on
all interfaces. An implementation SHOULD be configurable so that the
protocol can be enabled and disabled globally and on a per-interface
basis.
While enabling the generation of DDP Hello messages by default may be
controversial, the basic assumption of the protocol is that a device
may be improperly configured. Relying on explicit configuration to
enable the protocol is bound to limit its usefulness.
7. Mandatory attributes
DDP speakers SHOULD include following list of managed objects in
their Hello advertisements:
sysDescr ::= {mib-2 system 1}
sysObjectID ::= {mib-2 system 2}
sysUpTime ::= {mib-2 system 3}
sysName ::= {mib-2 system 5}
sysServices ::= {mib-2 system 7}
ifTable ::= {mib-2 interfaces 2}
The following variables of the interface table entry
corresponding to the outgoing interface of this message should
be advertised:
ifType
ifMtu
ifPhysAddress
ifXTable ::= {ifMIBObjects 1}
The following values complement the ifTable entry for the
outgoing interface:
ifName
ifAlias
ipAddrTable ::= {mib-2 ip 20}
If an IP address in configured on the outgoing interface the
draft-marques-ddp-00.txt [Page 6]
Internet Draft draft-marques-ddp-00.txt May 2003
corresponding IpAddrTable entry variables shall be advertised:
IpAddrEntry.ipAdEntAddr
IpAddrEntry.ipAdEntNetMask
8. Recomended attributes for routers
It is recomended that layer 3 devices advertise a minimal set of
information for each routing protocol enabled on the interface where
a DDP Hello message is generated.
The following is the list of recomended variable IDs:
{ ospf ospfIfTable ospfIfEntry ospfIfAreaId }
{ isisObjects isisCirc isisCircTable isisCircEntry isisCircAdminState }
9. DDP MIB
A DDP MIB will be defined in order to provide additional objects that
are cosidered necessary or desirable.
As an example, it should be possible to advertise whether or not an
given interface has mpls processing enabled. The solution adopted by
the MPLS LSR MIB of using a separate ifIndex than the ifIndex used by
IP it is unncessarly complex and unsuitable for this protocol
10. Acknowledgments
11. Author's Addresses
12. References
[BER] "Information processing systems - Open Systems Interconnection
- Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1)", International Organization for Standardization.
International Standard 8825, December 1987.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997.
[RFC1071] R.T. Braden, D.A. Borman, C. Partridge, "Computing the
Internet checksum", RFC1071, September 1988.
draft-marques-ddp-00.txt [Page 7]
Internet Draft draft-marques-ddp-00.txt May 2003
Rob Enns
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
rpe@juniper.net
Pedro Marques
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
roque@juniper.net
Daemon Morrell
morrelldk@mindspring.com
[RFC1213] K. McCloghrie, M.T. Rose, "Management Information Base for
Network Management of TCP/IP-based internets:MIB-II", RFC 1213, March
1991.
[RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)", RFC 2578, April 1999.
[RFC3416] R. Presuhn, Ed., "Version 2 of the Protocol Operations for
the Simple Network Management Protocol (SNMP)", RFC 3416, December
2002.
[RFC3417] R. Presuhn, Ed., "Transport Mappings for the Simple Network
Management Protocol (SNMP)". December 2002.
draft-marques-ddp-00.txt [Page 8]