[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/