WO2015199724A1

WO2015199724A1 - Link discovery in software-defined networks using a controller and network devices controlled by the controller

Info

Publication number: WO2015199724A1
Application number: PCT/US2014/044599
Authority: WO
Inventors: Ryan K. TIDWELL; Shaun Wackerly; Manfred R. Arndt
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2014-06-27
Filing date: 2014-06-27
Publication date: 2015-12-30
Anticipated expiration: 2016-12-27

Abstract

Systems, methods, and storage mediums for link discovery in software-defined networks containing a network controller and a plurality of controlled network devices controlled by the controller. The controller being interfaced with the controlled network devices over the network so as to allow the controller to control the controlled network devices for link discovery of the software-defined network.

Description

LINK DISCOVERY IN SOFTWARE-DEFINED NETWORKS USING A CONTROLLER AND NETWORK DEVICES CONTROLLED BY THE CONTROLLER

BACKGROUND

[0001] Software-defined networking is an approach to computer networking in which control decisions for routing traffic through the network can be decoupled from the network's physical infrastructure. Network devices in software-defined networks can communicate with a network controller to assist in determining the logical topology of the network.

BRIEF DESCRIPTION OF DRAWINGS

[0002] FIG. 1 is a diagram of a software-defined network including a network controller to allow link discovery in the network, according to an example.

[0003] FIG. 2 is a computing system including discovery instructions to allow link discovery in the network of FIG. 1, according to an example.

[0004] FIG. 3 is a computing system including a discovery module to allow link discovery in the network of FIG. 1, according to an example.

[0005] FIG. 4 is a flowchart of an improved method for link discovery in a software-defined network, according to an example.

[0006] FIG. 5 is a flowchart of an improved method for link discovery in a software-defined network, according to another example.

[0007] FIG. 6 is a flowchart of an improved method for link discovery in a software-defined network, according to another example.

[0008] FIG. 7 is a flowchart of an improved method for link discovery in a software-defined network, according to another example.

DETAILED DESCRIPTION

[0009] A network controller in a software-defined network can initiate a link discovery process to identify how network devices communicate to pass data throughout the network. This link discovery process can, for example, be used to create an overall logical topology of the network, which may be useful for troubleshooting connectivity issues and for the design and maintenance of the network. Although link discovery techniques currently exist, these techniques can be improved to more efficiently poll network devices for link information.

[0010] For example, link discovery can be performed on networks including a combination of controlled and uncontrolled network devices (herein referred to as a

"heterogeneous" network). Mapping a heterogeneous network can be challenging because in some situations, a network administrator may receive only limited connectivity information regarding the uncontrolled network devices. In such situations, the network controller may attempt to determine the topology of a network using indirect methods that are inefficient and can overload certain network devices.

[0011] One technique to improve the efficiency of the link discovery process in a software- defined network includes instructing controlled network devices to send a multicast link discovery advertisement with information that causes any client devices that receives the advertisement to disregard the advertisement. This can allow client devices with small processors such as certain Wireless Fidelity (Wi-Fi) access points or Internet Protocol (IP) phones to avoid being confused or overwhelmed by such discovery requests. This technique and others for improving the efficiency of the link discovery process are described further herein.

[0012] FIG. 1 illustrates an example of a network 100 including a network controller 102 connected to multiple network devices 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, and 126 via various wired or wireless data links. Network 100 can be implemented as a software-defined network (SDN) in which network controller 102 interfaces with the various network devices via a suitable Application Program Interface ("API"), or another suitable protocol (e.g., Open Flow and/or simple network management protocol (SNMP)). Controller 102 may interface with the network devices via an interface channel that connects each controlled device to controller 102 to allow controller 102 to configure and manage the device, receive events from the device, and send packets using the device. [0013] Controller 102 can, for example, be Implemented In part using a software program on a computing system connected to network 100. An example of such a computing system is described for example with respect to FIG. 2. In some implementations, controller 102 can be implemented on a standalone network device in network 100. Alternatively or in addition, controller 102 can be implemented on another network device in network 100, such as a network host or switch. Moreover, the

functionality of controller 102 may be split among multiple controllers or other devices.

[0014] In the example network 100 depicted in FIG. 1, the various network devices are in the form of data communication equipment (network switches for devices 106, 108, 110, 112, 114, 120, 122) and client devices (personal computers for devices 118 and 126 and printers for devices 116 and 124). It is appreciated however, that the improved systems, methods, and mediums described herein can be used or adapted for networks including more or fewer devices, different types of devices, and different network arrangements. For example, in some implementations, other data communication equipment (such as suitable modems, hubs, and bridges) and other client devices (such as suitable Wi-Fi access points or IP phones) can be included.

[0015] As described above, network 100 includes a combination of "controlled" network devices (e.g., controlled network devices 106, 108, 114, 120, and 122) and

"uncontrolled" network devices (e.g., uncontrolled network devices 110 and 112). As used herein, the term "controlled" is intended to include devices within the control domain of network controller 102, whereas the term "uncontrolled" is intended to refer to devices that are not within the control domain of network controller 102.

[0016] For Illustration, network 100 is described and illustrated as including only one

controller. However, it is appreciated that the improved systems, methods, and mediums described herein can be implemented in networks with multiple controllers. For example, in some networks, network devices are in communication with multiple controllers such that control of the network can be smoothly handed over to a second controller if a first controller fails. As another example, multiple controllers can work together to concurrently control a network. In such networks, a first controller can, for example, control certain network devices while a second controller can control other network devices. In view of the above, reference in this application to a single controller that controls the operation of a network is intended to include such multiple controller configurations and other suitable multiple controller configurations.

[0017] As depicted in FIG. 1, network controller 102 includes improved discovery

instructions 128 to more efficiently perform link discovery in network 100. Various implementations of such discovery instructions 128 will be discussed below with respect to the flow charts of FIGs. 3-7.

[0018] FIG. 2 illustrates an example of a computing system 130 connected to network

device 106. The description of computing system 130 and network device 106 refer to elements of network 100 for illustration, however, it is appreciated that computing system 130 and network device 106 can be used for link discovery of any suitable network. Moreover, network device of FIG. 2 corresponds to device 106 of FIG. 1, but the description of hardware and software of device 106 can be applied to another suitable device. Computing system 130 can be used to perform link discovery of network 100 and, as depicted in FIG. 2, can include a processor 132, memory 134, input/output (I/O) devices 136, and a communication interface 138. Computing system 130 can be in the form of a suitable server, desktop computer, laptop, tablet, or the like. In some implementations, software that provides the functionality of controller 102 can be stored on memory 134 of computing system 130 to be executed by processor 132 of computing system 130. In some

implementations, computing system 130 can be a standalone personal computer that is connected to controller 102 so as to receive information from network controller 102 for network discovery. In implementations where computing system 130 is a separate unit from network controller 102, computing system 130 can receive information from network controller 102 through indirect means. For example, computing system 130 may receive information from network controller 102 by Inserting a removable data storage device into computing system 130. In such an example, the removable data storage device can, for example, be in the form of a USB thumb drive or a storage disc containing information from network controller 102.

[0019] Processor 132 of computing system 130 can, for example, be In the form of a central processing unit (CPU), a semiconductor-based microprocessor, a digital signal processor (DSP) such as a digital image processing unit, other hardware devices or processing elements suitable to retrieve and execute instructions stored in memory 134, or suitable combinations thereof. Processor 132 can, for example, include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or suitable combinations thereof. Processor 132 can be functional to fetch, decode, and execute instructions as described herein. As an alternative or in addition to retrieving and executing instructions, processor 132 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or suitable combination thereof that include a number of electronic components for performing the functionality of instructions stored on memory 134. Processor 132 may be implemented across multiple processing units and instructions may be implemented by different processing units In different areas of computing system 130.

[0020] Memory 134 of computing system 130 can, for example, be in the form of a non- transitory machine-readable storage medium, such as a suitable electronic, magnetic, optical, or other physical storage apparatus to contain or store

information such as executable instructions, data, and the like. Memory 134 can, for example, be housed within the same housing as processor 132 for computing system 130, such as within a computing tower case for computing system 130. In some implementations, memory 134 and processor 132 are housed in different housings. As used herein, the term "machine-readable storage medium" may include Random Access Memory (RAM), flash memory, a storage drive (e.g., a hard disk), any type of storage disc (e.g., a Compact Disc Read Only Memory (CD-ROM), any other type of compact disc, a DVD, etc.), and the like, or a combination thereof. In some implementations, memory 134 can include a main memory, such as a Random Access Memory (RAM), where software may reside during runtime, and a secondary memory. The secondary memory can, for example, include a nonvolatile memory where a copy of software is stored.

[0021] In the Implementation depicted in FIG. 2, memory 134 stores topological link data 140, discovery Instructions 128, mapping instructions 142, and display instructions 144. As described above, memory 134 can for example store other instructions relating to the functionality of a software-defined network controller 102.

Topological link data 140 can, for example, indicate: (1) which controlled network devices In the network are linked together, (2) whether the links between controlled network devices are single-hop or multi-hop, and (3) whether the links between controlled network devices are bi-directional or uni-directional. Topological link data 140 can, for example, include information regarding which port of a controlled network device is used for communicating with an uncontrolled network device. Topological link data 140 can, for example, include discovery protocol data that provides link information relating to uncontrolled network devices that are directly connected to controlled network devices. It is appreciated that topological link data 140 can include other information to assist in mapping network 100.

[0022] For example, in some implementations, topological link data 140 can include media access control (MAC) address information for an uncontrolled network device linked to a controlled network device. In some implementations, the topological link data can include data in the form of another addressing scheme, such as Internet Protocol (IP) address or Address Resolution Protocol (ARP), for associating an address and a port used for that address.

[0023] Discovery instructions 128 can be executable by processor 132 such that computing system 130 is operative to perform link discovery of connected devices in a software- defined network. Various implementations of such discovery instructions 128 will be discussed below with respect to the flow charts of FIGs. 4-7.

[0024] Mapping instructions 142 can be executable by processor 132 such that computing system 130 is operative to logically map the links discovered during the discovery process or otherwise known to controller 102. For example, mapping instructions 142 can be used to turn information regarding the various links between network devices, which can, for example be stored In the form of one or more tables as topological link data 140, into a logical topology map for displaying to a network administrator or other user. For example, in some Implementations, mapping instructions 142 create a map to be displayed in the form of a graphical user interface (GUI) displayed on a screen of a computing device, such as a computer monitor. In some implementations, mapping instructions 142 create a map to be printed onto a sheet of paper or other physical media. It is appreciated that mapping instructions 142 can provide varying degrees of information regarding elements of a network, such as icons depicting the makes and models of controlled network devices, symbols representing the type of link between devices (e.g., wired, wireless, etc.), descriptions for various elements, and the like.

[0025] Display instructions 144 can be executable by processor 132 such that computing system 130 is operative to display topological information of network 100, such as a topology map created by mapping instructions 142. Display instructions 144 can be used to display network information in other forms, such as for example a table that includes information regarding connected devices. In some implementations, display instructions 144 can be executable by processor 132 such that computing system 130 (i.e., a first system) is operative to provide mapping instructions 142 or related information to a "second" system so as display topology information created by computing system 130 on the second system.

[0026] In some implementations, the logical topology map can be returned to a caller in a storage format without being converted into a GUI. For example, in some implementations, the logical topology map can be in the form of a logical representation that provides structure mappings in which certain structures correspond to switches or other network devices. Such an implementation can, for example, be used where a machine displaying a GUI for the map is a separate machine from the controller that maps the network.

[0027] Computing system 130 can also include one or more I/O devices 136 to allow

communication to and from computing system 130. Example of suitable I/O devices can include monitors, printers, keyboards, mouses, styluses, touchscreens, speakers, etc. I/O devices 136 can be connected to elements of computing system 130 via wired or wireless links.

[0028] Computing system 130 can also Include a communication Interface 138 to allow

computing system 130 to connect to network device 106 over network 100 via a communication link 156. Communication interface 138 can be implemented for use as a wired or wireless communication interface. In some implementations, communication interface 138 contains one or more physical data ports to connect to network 100. For example, in some implementations, communication interface 138 can be in the form of a network interface controller having an Ethernet port.

[0029] In the example of FIG. 2, network device 106 is implemented as a network switch containing multiple ports 146, 148, 150, and 152 and a switch chassis 154. The ports and switch chassis 154 work together to allow device 106 to forward network traffic to another network device connected to device 106. The ports can be used for receiving and sending data in network 100. It is appreciated that the ports can include wired connections to other network devices in network 100 and can, in some implementations, be in the form of virtual ports.

[0030] Switch chassis 154 of network device 106 can include a processor 158 and a memory 160 that operate together to allow device 106 to extract a set of fields from a received data packet execute flow routing instructions. Processor 158 and memory 160 of device 106 can include one or more aspects of processor 132 and memory 134 described above with respect to computing system 130.

[0031] FIG. 3 illustrates computing system 130 in the form of functional modules. In

particular, computing system 130 includes a data storage module 162, a discovery module 164, a mapping module 166, a display module 168, and a communication module 170. As used herein, the term "module" refers to a combination of hardware (e.g., a processor such as an integrated circuit or other circuitry) and software (e.g., machine- or processor-executable instructions, commands, or code such as firmware, programming, or object code). A combination of hardware and software can include hardware only (i.e., a hardware element with no software elements), software hosted at hardware (e.g., software that is stored at a memory and executed or interpreted at a processor), or at hardware and software hosted at hardware. Additionally, as used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, the term "module" is intended to mean one or more modules or a combination of modules.

[0032] Data storage module 162 is a functional module of computing system 130 that

includes a combination of hardware and software that allows computing system 130 to store data for use link discovery_/ mapping, display, etc. In some implementations, data storage module 162 includes hardware in the form of a hard drive, related firmware, and other software for allowing the hard drive to operatively

communicate with other hardware of computing system 130. Data storage module 162 can include information that is stored within data storage module 162, such as topological link data 140 described above with respect to FIG. 2.

[0033] Discovery module 164 is a functional module of computing system 130 that includes a combination of hardware and software that allows computing system 130 to perform link discovery of controlled devices in a network. In some implementations, discovery module 164 includes hardware in the form of a microprocessor on a single integrated circuit, related firmware, and other software for allowing the

microprocessor to operatively communicate with other hardware of computing system 130. Discovery module 164 can include Instructions used by computing system 130 to perform link discovery, such as discovery instructions 128 described above with respect to FIG. 1.

[0034] Mapping module 166 is a functional module of computing system 130 that includes a combination of hardware and software that allows computing system 130 to logically map the links discovered during the discovery process or otherwise known to controller 102. In some implementations, mapping module 166 includes hardware in the form of a microprocessor on a single integrated circuit, related firmware, and other software for allowing the microprocessor to operatively communicate with other hardware of computing system 130. Mapping module 166 can include instructions used by computing system 130 to map links, such as mapping instructions 142 described above with respect to FIG. 2. [0035] Display module 168 is a functional module of computing system 130 that Includes a combination of hardware and software that allows computing system 130 to display topological information of network 100, such as a topology map created by mapping instructions 142 in FIG. 2. In some implementations, display module 168 includes hardware in the form of a computer monitor, related firmware, and other software for allowing the computer monitor to operatively communicate with other hardware of computing system 130. It is appreciated that in some embodiments, display module 168 can include hardware In the form of a display port and/or video card. Display module 168 can include instructions used by computing system 130 to display topological information of network of a network. Such instructions can include, for example, display instructions 144 described above with respect to FIG. 2. In some implementations, display module 168 can additionally or alternatively include hardware in the form of a computer printer or printer port, related firmware, and other software for allowing a printer to operatively communicate with other hardware of computing system 130.

[0036] Communication module 170 is a functional module of computing system 130 that includes a combination of hardware and software to allow computing system 130 to communicate with network 100. In some implementations, communication module 170 includes hardware in the form of a network interface controller, related firmware, and other software for allowing the network interface controller to operatively communicate with other hardware of computing system 130 or devices on network 100.

[0037] FIGs. 4-7 illustrate examples of methods 172, 174, 176, and 178 that can, for

example, be implemented with a computing system to efficiently discover links in a software-defined network. The descriptions of these methods refer to elements of computing system 130 and network 100 for illustration, however, it is appreciated that these methods can be used for any suitable network. Moreover, although the flowcharts of FIGs. 4-7 show a specific order of performance of functionalities of their methods, this order may be rearranged into another suitable order, may be executed concurrently or with partial concurrence, or a combination thereof. Likewise, suitable additional and/or comparable steps may be added to the methods to achieve the same or comparable functionality.

[0038] FIG. 4 is directed to a first method 172 to efficiently perform link discovery In

network 100. Method 172 includes a step 180 of instructing a network device (e.g., network device 120) in a control domain of network controller 102 to send a multicast link discovery advertisement to a set of network devices that includes a client device (e.g., devices 116, 118, 124, 126). This advertisement includes information that causes the client devices to disregard the advertisement. In some implementations, this information can include forwarding criteria that excludes client devices as a class. For example, the link discovery can include an IP multicast address that excludes client devices, such as a multicast addresses assigned to switches, routers, or other network infrastructure devices. This can, for example, be implemented by leveraging behavior defined by the Ethernet specification (e.g., clients ignoring multicasts and/or a packet's ethertype). For example, a multicast packet sent to address 224.0.0.2 would be ignored by network devices that are not routers. The multicast address can, for example, operate at both Layer 2 and Layer 3 levels. For example, in some implementations, a multicast packet can include a special multicast MAC address per the Ethernet specification as the destination MAC address to allow client devices in network 100 to ignore the advertisement. Other suitable multicast addresses can be used in order to allow client devices in network 100 to ignore the advertisement.

[0039] Instructions 180 to send multicast link discovery advertisements can be provided by sending packets from controller 102 through datapaths of network 100. Controller 102 can send a packet out through a datapath using a suitable packet-out command for a given software-defined networking protocol. Packets can, for example, be in the form of an Ethernet frame including a header and payload. Such packets can, for example, include type-length-value (TLV) elements that identify the network device, the network controller that controls the network device, a port used to connect to the network device, and a time-to-live value. The Ethernet frame can, for example, include a datapath identification field that uniquely identifies a datapath. A lower 48 bits of the datapath identification field can be reserved for the device's MAC address, while a top 16 bits of the field can be In the form of a Virtual LAN (VLAN) identifier to distinguish multiple virtual switch instances on a single physical switch.

[0040] Method 172 further Includes a step 182 of receiving, from network devices in the control domain of controller 102, topological link data 140 for the network devices based on the advertisement. Step 182 can, for example, be in response to controller 102 querying network devices in the control domain of network 100 to send controller 102 topological link data 140. Topological link data 140 can be provided to controller 102 via a packet-in message event sent from a controlled network device.

[0041] Method 172 further includes a step 184 of determining a topology of network 100 based on the received topological link data 140. Step 184 can be Implemented via mapping instructions 142 described above with respect to FIG. 2.

[0042] In some implementations, method 172 can include an additional step of instructing network devices in the control domain of controller 102 to send neighbor link discovery advertisements. In some implementations, method 172 can include an additional step of receiving, from network devices in the control domain of the controller, topological link data 140 based on both the multicast link discovery advertisements and the neighbor link discovery advertisements. One example of a neighbor link discovery advertisement can be a Link Layer Discovery Protocol (LLDP) packet, which each controlled network device can be instructed to flood through all of its ports.

[0043] As described above, because method 172 allows the client devices to disregard the multicast link discovery advertisement from the network devices, method 172 can allow certain client devices with small processors, such as certain Wireless Fidelity (Wi-Fi) access points or Internet Protocol (IP) phones, to avoid being confused or overwhelmed by such requests.

[0044] FIG. 5 is directed to a second method 174 to efficiently perform link discovery in network 100. Method 174 includes a step 186 of instructing a first controlled network device (e.g., device 106) in a multi-hop link with a second controlled device (e.g., device 108) that contains an uncontrolled network devices (e.g., devices 110 and 112) to verify the connectivity of the multi-hop link. Although the identities of uncontrolled network device (I.e., devices 110 and 112) along the multi-hop link may not be visible to controller 102 along the control plane, controller 102 can assume that an uncontrolled network device exists if there are no other controlled network devices between the controlled network devices along the multi-hop link. In some implementations, the instructions to verify the connectivity of the multi-hop link can be provided by sending a packet from controller 102 through a datapath of the network, with the packet containing instructions to verify the link. The multi-hop link can, for example, be verified by instructing controlled network devices at both ends of the link to emit a broadcast (or multicast) discovery packet and to emit a link-local discovery packet.

[0045] Method 174 can further include a step 188 of instructing the first network device and the second network device to remove the multi-hop link when the connectivity of the multi-hop link is not verified within a predetermined amount of time. In some implementations, removing the multi-hop link can include removing flow entries associated with the multi-hop link. For example, controller 102 can send the first and second network devices instructions to remove flow entries from flow tables by sending a delete flow table modification message. In some implementations, controller 102 will remove the link from its own stored topological link data 140.

[0046] In some implementations, method 174 can include a step of instructing the second controlled network device to verify the connectivity of the multi-hop link and instructing the first network device and the second network device to remove the multi-hop link when the connectivity of the multi-hop link Is not verified by both the first and second controlled devices within the predetermined amount of time.

[0047] This technique can be advantageous compared to periodically polling all links as multi-hop links are often a small minority of links in a network. Moreover, in some situations controller 102 may be unaware of a break in a link between multiple unconnected devices (e.g., between device 110 and 112) in a multi-hop link. One example of code for discovery instructions 128 in accordance with method 174 is provided below:

[0048] FIG. 6 is directed to a third method 176 to efficiently perform link discovery in

network 100. Method 176 includes a step 190 of determining which ports of a network device (e.g., device 108) in a software-defined network are logically blocked by another network protocol. In some implementations, controller 102 can receive port status information from a network device through the use of a "port -status" message that informs controller 102 of a change on a port of the network device, such as the port being logically blocked.

[0049] Method 176 further includes a step 192 of instructing the network device to only perform link discovery on ports that are not logically blocked. The instructions to perform link discovery can, for example, include instructions for the network device to send neighbor link discovery advertisements through Its ports. In some implementations, the instructions to perform link discovery can, for example, include instructions for the network device to send neighbor link discovery advertisements, which can, for example be flooded through each port of the network device. In some implementations, the instructions to perform link discovery can, for example, include instructions for the network device to send multicast link discovery advertisements, which can, for example, be used for more complete link discovery of networks containing uncontrolled network devices.

[0050] This technique can, for example, make link discovery compatible with traditional networking protocols, such as spanning-tree. For example, the ports can be logically blocked by a spanning-tree protocol, but not physically down. With respect to network 100 of FIG. 1, the link between device 108 and device 118 can be logically blocked by a spanning-tree protocol as device 108 is otherwise able to communicate with device 118 via device 120. The technique can further prevent link discovery from introducing loopable packets (e.g., broadcast/multicast) into the controlled network.

[0051] Method 176 can further include a step of determining, before instructing the

network device to only perform link discovery on ports that are not logically blocked, whether controller 102 is operating in a mode of operation in which it selectively controls packet forwarding. If it is determined that controller 102 not operating in a mode of operation in which it selectively controls packet forwarding (e.g., controller 102 can be operating in a full control operation), controller 102 can be instructed to not proceed with determining whether any of its controlled network devices include logically blocked ports. One example of code for discovery instructions 128 in accordance with method 176 is provided below:

[0052] FIG. 7 is directed to a fourth method 178 to efficiently perform link discovery in

network 100. Method 178 includes a step 194 of receiving with controller 102 information indicating that a network device (e.g., device 108) has been connected to controller 102. In some implementations, controller 102 can receive port status information from a network device through the use of a "port-status" message that informs controller 102 of a change on a port of the network device, such as a new device being connected to controller 102. The status of a newly connected device can be provided to controller 102 in different ways, such as through a "Hello", "Features Reply", or "Packet in" message from the newly connected device or through other methods.

[0053] Method 178 further includes a step 196 of instructing network device 108 to

perform link discovery after a predetermined window of time so as to allow other network devices (e.g., devices 120 and 122) to be connected in series with network device 108 before network device 108 performs link discovery. For example, the predetermined window of time can be an actual amount of time (e.g., measured in seconds) that is expected to allow other network devices (e.g., devices 120 and 122) to be connected In series with network device 108. The predetermined window of time can, for example, be configurable by the administrator based on network topology, network conditions, or other factors. In some implementations, method 178 can also instruct other controlled network devices (e.g., network devices 106, 114, 120, and 122) to perform link discovery after the predetermined window of time.

[0054] The predetermined window of time can, for example, be determined by the

controller 102 based on an expected number of devices to be connected to the controller 102. For example, if three devices are expected to be connected in series, controller 102 can provide for an increased predetermined window of time than if only one two devices were expected to be connected in series. In some

implementations, if controller 102 expects a certain number of devices to be connected, controller 102 can instruct the network device to perform link discovery after the expected number of devices are connected rather than first waiting for the predetermined window of time to elapse.

[0055] In some implementations, controller 102 waits the predetermined window of time before instructing network device 108 to perform link discovery, whereas in other implementations, network device 108 is Instructed to wait the predetermined window of time before performing link discovery. In some implementations, the controller waits a predetermined window of time before providing instructions to network device 108 and the instructions to network device 108 also instruct network device 108 to wait a predetermined window of time before performing link discovery. In some implementations, the controller is programmed or otherwise configured to wait a predetermined window of time from the time the first discovered device is discovered before initiating link discovery. However, in some implementations, the controller can be programmed or otherwise configured to wait a predetermined window of time from the time a last device is discovered before initiating link discovery. For example, the predetermined window of time can be reset when a new device Is discovered.

[0056] One example of code for discovery instructions 128 in accordance with method 178 is provided below:

[0057] While certain implementations have been shown and described above, various

changes in form and details may be made. For example, some features that have been described in relation to one implementation and/or process can be related to other implementations. In other words, processes, features, components, and/or properties described in relation to one implementation can be useful in other implementations. As another example, functionalities discussed above in relation to specific modules or elements can be included at different modules, engines, or elements in other implementations. As but one example, data storage module 162 of computing system 130 can include aspects of discovery module 164 and vice versa.

[0058] As used herein, the term "provide" Includes push mechanisms (e.g., sending data independent of a request for that data), pull mechanisms (e.g., delivering data in response to a request for that data), and store mechanisms (e.g., storing data at an intermediary at which the data can be accessed). Furthermore, as used herein, the term "based on" means "based at least in part on." Thus, a feature that is described based on some cause, can be based only on the cause, or based on that cause and on one or more other causes.

[0059] Furthermore, it should be understood that the systems, apparatuses, and methods described herein can include various combinations and/or sub-combinations of the components and/or features of the different implementations described. Thus, features described with reference to one or more implementations can be combined with other implementations described herein.

Claims

CLAIMS What is claimed is:

1. A method comprising:

instructing a network device in a control domain of a network controller in a software-defined network to send a multicast link discovery advertisement to a set of network devices in the network that includes a client device, the advertisement including information that causes the client device to disregard the advertisement;

receiving, from network devices in the control domain of the controller, topological link data for the network devices based on the advertisement; and

determining a topology of the network based on the received topological link data.

2. The method of claim 1, further comprising:

instructing network devices in the control domain of the controller to send neighbor link discovery advertisements; and

receiving, from network devices in the control domain of the controller, topological link data based on both the multicast link discovery advertisements and the neighbor link discovery advertisements.

3. The method of claim 1, wherein the instructions to send multicast link discovery advertisements are provided by sending packets from the controller through datapaths of the network.

4. The method of claim 1, further comprising:

querying network devices in the control domain of the controller to send the controller the topological link data.

5. A software-defined network controller comprising:

a processor;

a memory containing instructions executable by the processor such that the controller is operative to perform limited link discovery by: instructing a first controlled network device in a multi-hop link with a second controlled device that contains an uncontrolled network device to verify the connectivity of the multi-hop link; and

instructing the first network device and the second network device to remove the multi-hop link when the connectivity of the multi-hop link is not verified within a predetermined amount of time.

6. The system of claim 5, the memory containing instructions executable by the processor such that the controller is operative to perform limited link discovery by further: removing the multi-hop link from topological link data stored on the controller when the connectivity of the multi-hop link is not verified within the predetermined amount of time.

7. The system of claim 5, the memory containing Instructions executable by the processor such that the controller is operative to perform limited link discovery by further: instructing the second controlled network device to verify the connectivity of the multi-hop link; and

instructing the first network device and the second network device to remove the multi-hop link when the connectivity of the multi-hop link is not verified by both the first and second controlled devices within the predetermined amount of time.

8. The system of claim 5, wherein the instructions to verify the connectivity of the multi-hop link are provided by sending a packet from the controller through a datapath of the network.

9. A non-transitory machine-readable storage medium encoded with instructions executable by a processor to:

determine which ports of a network device controlled by a software-defined networking protocol are logically blocked by another networking protocol; and instruct the controlled network device, via a network controller that controls the controlled network device, to only perform link discovery on ports that are not logically blocked by the other networking protocol.

10. The medium of claim 9, wherein the ports are logically blocked by a spanning-tree protocol.

11. The medium of claim 9, wherein the instructions are further executable by the processor to:

determine, before instructing the network device to only perform link discovery on ports that are not logically blocked, whether the controller is operating in a mode of operation in which it selectively controls packet forwarding.

12. The medium of claim 9, wherein the Instructions to perform link discovery include instructions for the network device to send neighbor link discovery advertisements.

13. A method comprising:

receiving, with a network controller for a software-defined network, information indicating that a controlled network device has been connected to the controller; and

in response to receiving the information, instructing the controlled network device to perform link discovery after a predetermined window of time so as to allow other network devices to be connected in series with the network device before the network device performs link discovery.

14. The method of claim 13, wherein the controller waits the predetermined window of time before instructing the network device to perform link discovery.

15. The method of claim 13, wherein the network device is instructed to wait the predetermined window of time before performing link discovery.