Independent Submission A. Miedzowicz Internet-Draft Independent Intended status: Standards Track Expires: June 10, 2015 December 2014 Topology Discovery Protocol (TDP) for Ethernet networks and framework definition draft-miedzowicz-tdp-topology-discover-00 Abstract This document defines a framework and a new protocol used to automatically discover the topology of a network based on IP connections and across any vendor that implements this protocol. With the information gathered from the network elements, a server will be able to create a database of connections between any two physical interfaces and display it in any format suitable by the vendor and which will be updated automatically if any changes are made. Status of This Memo This Internet-Draft is submitted 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. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. 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." This Internet-Draft will expire on June 10, 2015. Miedzowicz, A. Expires June 10, 2015 [Page 1] Internet-Draft Topology Discovery Protocol December 2014 Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Background ......................................................2 2. Terminology .....................................................3 3. Introduction ....................................................3 4. Protocol Description ............................................3 4.1. Protocol Operation .........................................3 4.2. Packet Format ..............................................4 4.3. Protocol events ............................................5 4.3.1. Sending a TDP packet ................................5 4.3.2. Receiving a TDP packet ..............................5 4.3.3. Reporting a TDP event to the TDS ....................5 4.4. Protocol Considerations ....................................5 5. Security Considerations .........................................5 6. IANA Considerations .............................................6 7. References ......................................................6 7.1. Normative References .......................................6 8. Acknowledgements ................................................6 1. Background One of the most critical and laborious tasks a network operator must do on a daily basis is to keep an accurate network topology diagram and connection database used both for planning and troubleshooting. Failure to do this task effectively will mean that fault finding times will be greatly increased and planning and delivery of new services, expansions, deployments, etc. will be affected by incorrect or incomplete information. Knowing where each end of each cable is connected to is invaluable for operators and tracking each connection should be done since deployment or it may become a very time-consuming and expensive project to undertake later after years of not having proper documentation in place. Current practices use various types of documents to depict the connections between any two network elements which is kept up-to-date manually and adds an extra task to the work of the engineer but must be done to run a healthy network. Miedzowicz, A. Expires June 10, 2015 [Page 2] Internet-Draft Topology Discovery Protocol December 2014 2. 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 RFC 2119 [RFC2119]. 3. Introduction This document defines a level 2 protocol named Topology Discovery Protocol (TDP) that will, by means of probe packets, assist in the creation of a topology map of the whole network and will reflect in a short time any changes that may ocurr. A device running TDP sends a probe packet to the MAC broadcast address on each of its connected ports with a randomly generated pattern which will be received and processed by the far end. Upon sending or receiving a TDP packet, the device will report this event to the Topology Discovery Server (TDS) indicating which was the pattern received or sent and which interface was the pattern sent or received on. With this information, the TDS will be able to determine the topology of the network by matching patterns sent on an interface with the ones received on the other. When matches are found between the sent pattern reported by a node and the pattern received by another node (or another interface in the same node), and if this match is found a predefined number of consecutive times, it is safe to determine that a connection exists between those two or more interfaces as well as the direction of the connection. Reporting of the events to the TDS can be done by using Simple Network Management Protocol (SNMP) [RFC1157] traps and defining new OIDs for each interface that will convey the pattern value. 4. Protocol Description 4.1. Protocol Operation TDP is a protocol running on layer 2 of the OSI model designed to work with Ethernet although other protocols are not discarded for future updates. A TDP packet is generated with a Discovery Probe (DP) which is a randomly generated 48-bit number which includes parts of the MAC address of the interface the packet is being sent from to minimise the generation of duplicate DPs by different nodes. The frequency the TDP is sent is governed by the timer T1 which can vary between 10 miliseconds to 2000 miliseconds. The value of T1, together with the number of consecutive matches the TDS will look for determines the time it will take the TDS to find the network topology. Miedzowicz, A. Expires June 10, 2015 [Page 3] Internet-Draft Topology Discovery Protocol December 2014 For example, if T1 is set to 1000 miliseconds and the TDS is set to wait for 5 consecutive matches before declaring that a connection between two endpoints is in place, the network topology will be discovered in 5 seconds. 4.2. Packet Format A summary of the contents of the TDP packet follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet address of destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ethernet address of destination| Ethernet address of sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet address of sender | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Probe | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Probe | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that each tick mark represents one bit position. Ethernet address of destination: 48 bits The destination MAC address. For TDP, this field must have the value FF:FF:FF:FF:FF:FF (broadcast address). Ethernet address of sender: 48 bits The source MAC address of the outgoing interface. Protocol Type: 16 bits Value that will represent TDP as the protocol carried (TBD). Discovery Probe (DP): 48 bits A randomly generated number which consists of two 24-bit parts. The 24 Most Significant Bits (MSBs) of the DP consists of the following: 12 MSBs of the Organisationally Unique Identifier (OUI) in the MAC address of the interface followed by the 12 LSBs of the Device ID of the MAC address of the interface. For example, the first part of the DP for an interface with a MAC address of 12:34:56:78:9A:BC will be 123ABC. The 24 Least Significant Bits (LSBs) of the DP consists of a randomly generated number. The algorithm to generate this number is implementation specific and out of the scope of this specification. Miedzowicz, A. Expires June 10, 2015 [Page 4] Internet-Draft Topology Discovery Protocol December 2014 4.3. Protocol events 4.3.1. Sending a TDP packet A TDP packet will be sent at every expiration of the T1 timer on each interface with an active connection. Upon sending the TDP packet, the event must be reported to the TDS identifying the port it was sent from and the DP sent. 4.3.2. Receiving a TDP packet When a TDP packet is received, the device must report to the TDS the DP value received and the interface the packet was received on. TDP packets must not be propagated to other ports in the device. 4.3.3. Reporting a TDP event to the TDS After a TDP packet is received or sent, the device must report this to the upstream server, the TDS, for topology discovery. To help interoperability, the preferred method for this notification is by means of SNMP traps as this is a widespread protocol widely supported amongst almost every vendor. However, vendors may choose to use other protocols for this purpose. An OID that reflects the interface used within the system must be specified in a way that uniquely identifies the physical port that was used to send or receive the TDP packet. Information such as rack, subrack, shelf, board slot, etc. can be used as part of the OID to correctly identify the interface. When the SNMP traps are received at the TDS, the server can match the patterns in the DPs reported by different interfaces (either in different devices or the same one). A configurable counter, C1, must be used to determine the number of consecutive matches the TDS records before establishing the one-way connection between the two endpoints. The value of C1 should vary between 2 and 10. It must be noted that the bigger the value of C1, the longer the TDS will take to find the topology. The way the topology is showed to the end user is implementation specific. 4.4. Protocol Considerations The TDS is able to create a topology map between any two active end nodes but passive devices such as hubs, optical and electrical patch panels, distribution frames, etc. will not be detected. 5. Security Considerations There are no security considerations for this protocol. Miedzowicz, A. Expires June 10, 2015 [Page 5] Internet-Draft Topology Discovery Protocol December 2014 6. IANA Considerations IANA is requested to allocate a value of the EtherType field in the Ethernet frame for the TDP protocol. 7. References 7.1. Normative References [RFC1157] Case, J., Fedor, M., Schoffstall, M., and Davin, J., "A Simple Network Management Protocol (SNMP)", RFC 1157, May 1990. 8. Acknowledgements The author would like to thank Gerardo Gruszka for his insight and support in the creation of this document. Author's Address Andres Miedzowicz Email: andres.miedzowicz@gmail.com Miedzowicz, A. Expires June 10, 2015 [Page 6]