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 ( 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]