Internet DRAFT - draft-miedzowicz-tdp-topology-discover
draft-miedzowicz-tdp-topology-discover
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]
