Link Layer Discovery Protocol

Abstract: A method is provided in one example embodiment and includes communicating a query over a network to a plurality of entities that reside in a domain, the query including a request for data relating to energy use. The query can be generated by one or more computing devices belonging to the domain. A selected one of the computing devices can control power consumption for the entities in the domain. In other embodiments, a discovery protocol (DP) and a link layer discovery protocol (LLDP) is used for transporting events regarding the entities that connect or disconnect from the network. The entities send discovery events over a DP/LLDP protocol, identifying them as part of the domain. In yet other embodiments, the method includes querying a selected one of the entities to determine, if the selected entity moved to a certain energy level, an energy consumption value at the certain energy level.

Abstract: Current latency monitoring approaches for Software Defined Network often use the control plane as the infrastructure to inject time-stamp data packets as probe packets to measure the network latency at a particular time, but suffer from three major issues when the network latency needs to be continuously monitored: 1) the increased control plane's overhead, 2) the feasibility of using data packets as probe packets, and 3) the increasing measurement error using OpenFlow messages to measure the time from the controller to a switch as the network scale grows. To overcome these issues, this paper proposes link latency monitoring using time-stamped Link Layer Discovery Protocol (LLDP) packets, aided by a linear calibration function to reduce errors of measuring switch-controller delays. Time-stamping LLDP packets, which are used to discover the global network topology in SDNs, does not add extra workload to the control plane and the results always reach the controller thus while avoiding measurement failures that might occur in existing approaches. Our linear calibration function can reduce the measurement error to less than 5\% of the link latency measured by ping in a network with up to 30 switches and the link latency not less than 1ms.

Abstract: Link Layer Discovery Protocol (LLDP), which is widely used by the controller in Software-Defined Networking to discover the network topology, has been demonstrated to be unable to guarantee the integrity of its messages. Attackers could exploit this vulnerability to fabricate LLDP packets to declare a false link connecting two distant switches to the controller. By doing so, the controller would be misled to route flows to the false links, which leads to further DoS, eavesdropping and even hijacking attacks. This attack seems very similar to the well-known Worm-Hole Attack in wireless sensor networking (WSN). Nevertheless, in WSN, attackers are assumed to leverage an out-of-band wired channel to achieve the true packet transmission between the two cheating sensor nodes. Unfortunately, in SDN, there usually does not exist any out-of-band channels between the distant cheating switches. Flows misguided to the fake link will cause 100% packet loss, and thus be detected soon. In this article, we address this problem and propose the first True worm-hole attack in SDN, which could achieve packet transmission over the forged link without using any out-of-band channels. Instead, it introduces a relay host in the networks to build a completely in-band covert channel between the two cheating switches. Unlike the existing studies, a relay host is not required to be directly linked to them. Moreover, attackers are only assumed to poss the remote read and write privileges of the flow tables of the both cheating switches and do not have to alter any of their software or hardware. Our extensive experiments demonstrate the high feasibility of this attack. Both the increases of transmission delays and packet loss rates are within a reasonable range. We finally present and evaluate the countermeasures against the proposed attack.

Abstract: This document defines a protocol, and a set of management objects for use with IEEE 802 devices. In particular, it describes a physical topology discovery protocol and managed objects used for managing the protocol. The protocol is not restricted from running on non-802 media, however, a specification of this operation is beyond the scope of this document.