WO2016122570A1

WO2016122570A1 - Sending information in a network controlled by a controller

Info

Publication number: WO2016122570A1
Application number: PCT/US2015/013703
Authority: WO
Inventors: Shaun Wackerly; Marjorie Krueger
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-01-30
Filing date: 2015-01-30
Publication date: 2016-08-04

Abstract

A data plane switch in a controlled network that is controlled by a controller receives a message including an indicator indicating replication of a packet to a plurality of virtual networks. Responsive to the indicator, the data plane switch sends replicated copies of the packet to the plurality of virtual networks.

Description

SENDING INFORMATION IN A NETWORK CONTROLLED BY A CONTROLLER Background

[0001 ] A communications network can include switches to pass data from a source endpoint device to one or multiple destination endpoint devices. In some networks, the control plane and the data plane can be separated, where the control plane is provided in one or multiple controllers, and the data plane is provided by switches that are controlled by the controller(s). This type of network can be referred to as a Software-Defined Network (SDN). The control plane, including the controller(s), can make decisions about how traffic data is to be forwarded through the network. The controller(s) can send flow control information to the switches, which use the flow control information to control forwarding of traffic data packets by the switches, as well as to control access, policies, and quality of service associated with the network.

Brief Description Of The Drawings

[0002] Some implementations of the present disclosure are described with respect to the following figures.

[0003] Fig. 1 is a block diagram of an example network arrangement according to some implementations.

[0004] Fig. 2A is a flow diagram of a process of an OpenFlow switch according to some implementations.

[0005] Fig. 2B is a flow diagram of a process of a controller according to some implementations.

[0006] Fig. 3 is a block diagram of another example network arrangement according to some implementations.

[0007] Fig. 4 is a block diagram of a further example network arrangement according to further implementations. [0008] Fig. 5A is a flow diagram of a process of an OpenFlow switch according to further implementations.

[0009] Fig. 5B is a flow diagram of a process of a controller according to further implementations.

[0010] Fig. 6A is a block diagram of a switch according to some implementations. [001 1 ] Fig. 6B is a block diagram of a controller according to some implementations. Detailed Description

[0012] A communications network can include one or multiple controllers (part of a control plane) and switches (part of a data plane) that are controlled by the controller(s). Such a communications network can be referred to as a Software- Defined Network (SDN). The controller(s) of the SDN can be referred to as SDN controller(s). In some cases, operations of the controller(s) and the switches of an SDN can be according to an OpenFlow protocol, as described in the OpenFlow Switch Specification, provided by the Open Networking Foundation.

[0013] The switches have a connection to both the control plane and data plane. The switches receive instructions from the controller(s) over their connection to the control plane. The switches then enforce those received instructions on traffic which traverses the data plane connections between switches.

[0014] Although reference is made to SDN and the OpenFlow protocol in the present disclosure, it is noted that techniques or mechanisms according to some

implementations can also be applied to other types of communications networks in which the data plane is separated from the control plane, which can use other types of protocols.

[0015] A switch that operates according to OpenFlow can be referred to as an OpenFlow switch or an OpenFlow instance. Note that an OpenFlow switch or OpenFlow instance can be a logical switching entity that is implemented as machine- executable instructions on a physical switch. One or multiple OpenFlow switches can be implemented on a physical switch.

[0016] More generally, a switch for forwarding packets in a data plane can be referred to as a "data plane switch." A data plane switch can refer to logical switch, which can be implemented as a combination of machine-executable instructions and processing hardware. An OpenFlow switch or OpenFlow instance is an example of a data plane switch. Multiple data plane switches can be provided in a network, where the data plane switches are controlled by one or multiple remote controllers. The network including the multiple data plane switches can be referred to as a "controlled network," since the network is controlled by the controller(s).

[0017] An OpenFlow switch includes various tables that can be used for forwarding packets by the OpenFlow switch. A packet can refer generally to any unit of data that can be passed through a network between endpoint devices. A packet can carry traffic data (e.g. user data, data of applications, etc.) or can carry control information used for controlling aspects of a network. Tables used for forwarding packets can include a flow table (or multiple flow tables).

[0018] A packet received by an OpenFlow switch is matched to flow entries of one or multiple flow tables of the OpenFlow switch to decide how the packet is to be forwarded. A controller can add, update, and delete flow entries in the flow table(s) of an OpenFlow switch. Each flow entry of a flow table includes match fields

(containing fields to match to respective fields of a packet), counters, and

instructions to apply to a packet that matches the respective flow entry. The instructions of each flow entry can specify one or multiple actions, including packet forwarding, packet modification, and so forth. A flow entry can cause a packet to be forwarded to a port of the OpenFlow switch.

[0019] A port of an OpenFlow switch refers generally to a network interface for passing data packets between an OpenFlow switch and the rest of the network. OpenFlow switches connect to each other by their OpenFlow ports. A packet is received on an ingress port of an OpenFlow switch, and after processing by the OpenFlow switch, the packet is forwarded to an output port, or can be dropped.

[0020] Generally, the OpenFlow Specification does not address the provision of information about Virtual Local Area Networks (VLANs) . A physical network can be partitioned into multiple domains, where such domains can be referred to as VLANs. Endpoint devices can be members of a specific VLAN. Multiple VLANs (or more generally, virtual networks) share the bandwidth and other resources of the underlying physical network.

[0021 ] To discover links between OpenFlow switches, an SDN controller can inject discovery packets into a network and observe discovery packets received from the network. Links can be discovered by the SDN controller based on received discovery packets. However, if the SDN controller is unaware of the VLAN

configuration in the controlled network, then a data packet injected by the SDN controller may not include a header related to VLAN. More specifically, a discovery packet generated by the SDN controller for injection into the controlled network for performing discovery may not include a header according to the Institute of Electrical and Electronics Engineers (IEEE) 802.1 Q standard, which supports VLANs on an Ethernet network. The IEEE 802.1 Q standard defines a technique of tagging a packet (and more specifically, an Ethernet frame) to identify a respective VLAN.

[0022] An untagged packet (which is a packet that is not tagged with VLAN-related information, such as the IEEE 802.1 Q tag) may be dropped by an OpenFlow switch if the untagged packet is received on a tagged-only port of the OpenFlow switch. A tagged port is a port that is configured to be tagged for one or multiple VLANs (i.e. information identifying the one or multiple VLANs is associated with the port), such that packets can be communicated to the VLAN(s) to which the port is assigned (tagged). Stated differently, a tagged port can be a member of one or multiple VLANs. An untagged port is not associated with information identifying any VLAN; an untagged port can be a member of just one VLAN. A tagged-only port can refer to a port that has the following characteristic: for every VLAN the port is associated with, the port is tagged for that VLAN. Stated differently, for a tagged-only port, there exists no VLAN where the port is an untagged member.

[0023] As another issue, an untagged packet received on a port of an OpenFlow switch may be associated with a VLAN that may not be what the sender of the untagged packet intended. For example, the controller may intend to communicate an untagged packet in a first VLAN, but the OpenFlow switch associates the untagged packet with a different VLAN. This will cause the untagged packet to be forwarded incorrectly by the OpenFlow switch.

[0024] In either case (an untagged packet dropped by the OpenFlow switch or associated with an incorrect VLAN), an injected discovery packet from the controller may not be received by the controller, in which case link discovery may not produce accurate results.

[0025] Although reference is made to discovery of network links by a controller in some examples, it is noted that in other examples, techniques or mechanisms according to some implementations of the present disclosure can be applied in other scenarios.

[0026] Fig. 1 depicts an example network arrangement that includes a controller 102 that controls various OpenFlow switches 104 of a controlled network 106. The OpenFlow switches 104 are depicted as OpenFlow switch A and OpenFlow switch B in the example of Fig. 1 . Although just one controller is shown in Fig. 1 , it is noted that in other examples, multiple controllers 102 can be used to control the network 106. Also, in other examples, there can be more than two OpenFlow switches 104, and more than one controlled network 106.

[0027] Fig. 1 also shows endpoint devices 108 that can communicate data through each other through the controlled network 106. More than two endpoint devices 108 can be connected to the controlled network 106 in other examples. Examples of endpoint devices include computers (e.g. desktop computers, notebook computers, tablet computers, etc.), smartphones, wearable devices (that can be worn on a person, such as on a wrist, face, etc.), game appliances, system controllers, and so forth.

[0028] In some implementations, the controller 102 includes a replication control engine 1 10, which is able to send a replication indicator 1 12 to control replication of a packet 1 16 by OpenFlow switch A to VLANs of OpenFlow switch A. Each

OpenFlow switch is configured to communicate over a respective set of one or multiple VLANs. For example, OpenFlow switch A is configured to communicate over VLANs 1 and 2, while OpenFlow switch B is configured to communicate over VLANs 2, 3, and 4.

[0029] Replication of the packet 1 16 in response to the replication indicator 1 12 is performed by a packet replication engine 1 14 in OpenFlow switch A. Note that OpenFlow switch B also includes a packet replication engine 1 14 to perform replication of a packet from OpenFlow switch B in response to a replication indicator from the controller 102.

[0030] In the present disclosure, an "engine" can refer to processing hardware, or a combination of processing hardware and machine-executable instructions for execution on the processing hardware. The processing hardware can include a physical processor, a microprocessor, a core of a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC) device, a programmable gate array, or other processing hardware.

[0031 ] By replicating the packet 1 16 to VLANs of OpenFlow switch A {e.g. VLANs 1 and 2), multiple replicated copies of the packet 1 16 are sent to respective different OpenFlow switches. At least one of the receiving OpenFlow switches may be configured with a flow rule (represented as one or multiple flow entries in one or multiple respective flow tables of the OpenFlow switch) to cause forwarding of the received replicated copy of the packet 1 16 to the controller 102. The flow rule is configured at the receiving OpenFlow switch by the controller 102. [0032] In the context of link discovery, the packet 1 16 is a discovery packet, which can be according to a specific Ethernet type, and can include content that identifies an OpenFlow switch and port where the discovery packet originated. The controller 102 is able to discover a respective link between OpenFlow switches using information in the received replicated copy of the discovery packet 1 16. The controller 102 is able to derive the source OpenFlow switch and destination

OpenFlow switch of the link that the discovery packet traversed, and can record the link between the OpenFlow switches.

[0033] In other examples, the replication of a packet for the purpose of forwarding a packet back to the controller 102 after the packet has traversed the controlled network 106 can be performed for other purposes different from link discovery.

[0034] By using techniques or mechanisms to control replication of a packet to VLANs of an OpenFlow switch according to the present disclosure, the controller 102 does not have to be VLAN-aware. In other words, the controller 102 does not have to be provided with or gather information regarding the VLAN configuration of the controlled network 106. The VLAN configuration can include a configuration relating to which VLANs are implemented on which OpenFlow switches, which switch ports are members of respective VLANs, and whether the ports are tagged or untagged with respect to VLANs.

[0035] According to some implementations of the present disclosure, the controller 102 is able to inject a packet (e.g. a discovery packet or other type of packet) into the controlled network 106, where the injected packet is untagged (is not provided with any VLAN information, such as an identifier of a VLAN). However, by using the replication indicator 1 12 according to some implementations, an OpenFlow switch 104 is controlled to perform replication of copies of the injected packet, and to add a tag to each replicated copy of the packet to cause proper forwarding through respective ports of corresponding VLANs. The added tag can include VLAN-related information, such as information identifying a VLAN. In some examples, the added tag is a tag according to IEEE 802.1 Q. [0036] In some examples, the replication indicator 1 12 can be included in one of several specific types of messages that can be sent from the controller 102 to an OpenFlow switch 104. As an example, the replication indicator 1 12 can be included in an OFPT_VENDOR message according to the OpenFlow protocol, which supports vendor extensions. The OFPT_VENDOR message includes a vendor field that uniquely identifies a vendor, and a portion that can include vendor-defined arbitrary additional data. A "vendor" can refer to an entity (e.g. manufacturer, developer, service provider, etc.) that has implemented or provided the controller 102.

[0037] The vendor-defined arbitrary additional data can include the replication indicator 1 12 for indicating replication of a packet (having a specified characteristic) to VLANs of the OpenFlow switch 104 that received the replication indicator 1 12.

[0038] As another example, the controller 102 can include the replication indicator 1 12 in an OFPT_EXPERIMENTER message, which can include an experimenter field that identifies an experimenter, and an experimenter data portion in which arbitrary data can be included, including the replication indicator 1 12. An

experimenter can refer to any entity that desires to perform an action in the controlled network 106.

[0039] In some examples, using either of the foregoing messages, or any other message, the controller 102 can instruct an OpenFlow switch 104 to perform either of the following:

• replicate any PACKET_OUT message with a given buffer identifier (buffer ID) to all VLANs of the OpenFlow switch; or

• replicate any PACKET_OUT message with a given Ethernet type to all VLANs of the OpenFlow switch.

[0040] More generally, the OFPT VENDOR OR OFPT EXPERIMENTER message can instruct the OpenFlow switch to replicate a packet having a given characteristic to multiple VLANs of the OpenFlow switch, where examples of the given characteristic include a buffer ID and an Ethernet type. Other example characteristics can be specified in other examples.

[0041 ] A PACKET_OUT message according to OpenFlow contains packet data that is sent by the controller 102 to an OpenFlow switch, where the packet data in the PACKET_OUT message is to be forwarded by the OpenFlow switch as if the

OpenFlow switch received the packet data from another OpenFlow switch or from a terminal. The PACKET_OUT message also includes various other fields, including a buffer ID, which refers to a packet stored in a buffer in an OpenFlow switch. Thus, in examples according to Fig. 1 , the packet 1 16 is stored in a buffer of OpenFlow switch A, and is associated with a respective buffer ID.

[0042] A packet can also be associated with an Ethernet type, where example Ethernet types include the following: Internet Protocol (IP) version 4 (IPv4); IP version 6 (IPv6); Address Resolution Protocol (ARP); and so forth.

[0043] Each OpenFlow switch 104 is VLAN aware, and thus can insert a VLAN- related tag into the packet that is being replicated. More specifically, the OpenFlow switch 104 can add an IEEE 802.1 Q tag to a packet header. The replication performed by the OpenFlow switch 104 can result in multiple packets being generated from the same port by a single PACKET_OUT message.

[0044] More specifically, a physical switch on which an OpenFlow switch is implemented has configuration information regarding the OpenFlow switch(es) implemented on the physical switch, the ports of the physical switch, and the VLANs of the OpenFlow switch(es). This configuration information allows the correct tagging and replication of the packet to all VLANs in an OpenFlow switch.

[0045] Fig. 2A is a flow diagram of a process performed by an OpenFlow switch 104, and more specifically by the packet replication engine 1 14 according to some implementations. The packet replication engine 1 14 receives (at 202) a message including an indicator (e.g. the replication indicator 1 12 of Fig. 1 ) indicating replication of a packet to multiple virtual networks (e.g. VLANs). The received message can be received from the replication control engine 1 10 in the controller 102, and the received message can include the OFPT_VENDOR message or OFPT_EXPERIMENTER message discussed above, as examples.

[0046] Responsive to the indicator, the packet replication engine 1 14 sends (at 204) replicated copies of the packet to the multiple virtual networks (e.g. VLANs). The replicated copies can be tagged or untagged according to the port configuration associated with the VLAN upon which the packet is being replicated.

[0047] Note that in some examples, the replication indicator can be included in a message that is separate from the packet to be replicated. The replication header can be included in a message that is sent by the controller to the OpenFlow switch 104 prior to sending the packet (in a separate message) to the OpenFlow switch 104. In other examples, the replication indicator can be included in the same message that also contains the packet to be replicated.

[0048] Fig. 2B is a flow diagram of a process performed by the controller 102 according to some implementations. The replication control engine 1 10 of the controller 102 sends (at 210) a message including a replication indicator to a first data plane switch, the replication indicator indicating replication of the packet to virtual networks of the first data plane switch. The message can include the

OFPT VENDOR message or the OFPT EXPERIMENTER message discussed above, for example.

[0049] The controller 102 sends (at 212) a packet (e.g. a discovery packet) to the first data plane switch, where the packet is untagged with respect to virtual networks (e.g. VLANs). The packet can be sent by the controller 102 in a PACKET_OUT message according to OpenFlow, for example.

[0050] Although reference is made to the sending of the message and the packet as separate tasks, it is noted that in some examples, the replication indicator can be included in the message that carries the packet. [0051 ] The controller 102 receives (at 214) a replicated copy of the packet from a second data plane switch. Using the information in the replicated copy of the packet, the controller 102 can perform a respective action, such as discover a link between OpenFlow switches.

[0052] Fig. 3 is a block diagram of another example arrangement that includes the controller 102 and OpenFlow switches Ax, Bx, Cx, and Cy in respective physical switches A, B, and C. More specifically, OpenFlow switch Ax is deployed on physical switch A, OpenFlow switch Bx is deployed on physical switch B, and

OpenFlow switches Cx and Cy are deployed on physical switch C.

[0053] Each physical switch has respective ports. For example, physical switch A has ports 1 and 2 (labelled as 302 and 304, respectively, in Fig. 3). Similarly physical switch B has ports 1 and 2, and physical switch C has ports 1 and 2.

[0054] Fig. 3 also shows the presence of an uncontrolled switch 306, which is a switch that is not controlled by the controller 102 (or controllers 102). The

uncontrolled switch 306 is able to route packets from the controlled network that includes the OpenFlow switches to a non-OpenFlow network 308.

[0055] In the example of Fig. 3, OpenFlow switch Ax is configured to communicate over VLANs 1 and 2, OpenFlow switch B is configured to communicate over VLANs 1 and 2, OpenFlow switch Cx is configured to communicate over VLAN 1 , and OpenFlow switch Cy is configured to communicate over VLAN 2.

[0056] Port 1 of each of physical switches A and B is tagged with respect to VLAN 1 , port 2 of each of physical switches B and C is tagged with respect to VLANs 1 and 2. Port 2 of physical switch A is tagged with respect to VLAN 2, and untagged with respect to VLAN 3.

[0057] In the example arrangement of Fig. 3, the link between OpenFlow switches Ax and Bx and the link between OpenFlow switch Bx and each of OpenFlow switches Cx and Cy is a direct link. The link between OpenFlow switch Ax and each of OpenFlow switches Cx and Cy is a multi-hop link, since the link between OpenFlow switch Ax and OpenFlow switch Cx or Cy traverses through the uncontrolled switch 306.

[0058] Using packet replication techniques or mechanisms according to the present disclosure, the controller 102 is able to discover both the direct links and the multi- hop link.

[0059] As noted above, in the some implementations, the controller 102 does not have to be VLAN-aware to perform link discovery (or other operations) in a controlled network that includes VLANs. In alternative implementations, techniques or mechanisms according to the present disclosure can use the OpenFlow switches 104 to perform neighbor discovery, in which each given OpenFlow switch is able to gather information about OpenFlow switch(es) that is (are) directly connected to the given OpenFlow switch. A first OpenFlow switch is directly connected to a second OpenFlow switch if the first and second OpenFlow switches are connected without any intervening switches. The first and second OpenFlow switches are considered neighbors.

[0060] As shown in Fig. 4, OpenFlow switches A, B, and C each includes a Link Layer Discovery Protocol (LLDP) engine 404 and an OpenFlow engine 406. Each LLDP engine 404 is able to perform tasks according to LLDP, which allows network devices to advertise their identities and capabilities, and discover the identities and capabilities of their neigbhors.

[0061 ] LLDP specifies a data unit, referred to as LLDPDU. The payload of an LLDPDU contains data encoded as TLV, where T represents type, L represents length, and V represents value (L indicates the length of the value V). The type (T) indicates what information is encoded in the V content. The value (V) in the

LLDPDU contains actual information that is being communicated.

[0062] !n accordance with some implementations of the present disclosure, a specified type of LLDPDU can include encoded content to allow for discovery of neighbor OpenFiow switches and their associated VLANs (the VLANs each

OpenFiow switch is configured to communicate over),

[0063] Each OpenFiow engine 406 in an OpenFiow switch performs OpenFiow operations according to the OpenFiow protocol (e.g. forward a packet according to one or multiple flow tables), along with other tasks.

[0064] In some implementations, each LLDP engine 404 is able to send an LLDPDU that advertises the respective OpenFiow switch and the VLANs of the OpenFiow switch. For example, the LLDP engine 404 of OpenFiow switch A can send an LLDPDU to its neighbor OpenFiow switch B, where the LLDPDU includes an identifier of OpenFiow switch A, and identifier(s) of VLAN(s) of OpenFiow switch A. More generally, the LLDPDU can include information of the OpenFiow switch along with VLAN-related information (e.g. an identifier of a VLAN)

[0065] Similarly, the LLDP engine 404 of OpenFiow switch C can send an LLDPDU to its neighbor OpenFiow B, where the LLDPDU from OpenFiow switch C includes an identifier of OpenFiow switch C, and identifier(s) of VLAN(s) of OpenFiow switch C.

[0066] Similarly, the LLDP engine 404 of OpenFiow switch B can send an LLDPDU to each of OpenFiow A or C, where the LLDPDU from OpenFiow switch B includes an identifier of OpenFiow switch B and identifier(s) of VLAN(s) of OpenFiow switch B.

[0067] Upon receipt of an LLDPDU from a neighboring OpenFiow switch, the receiving OpenFiow switch can send information contained in the LLDPDU to a controller 402 that controls the controlled network including the OpenFiow switches A, B, and C. All OpenFiow switches in the controlled network are able to forwarded information in received LLDPDUs to the controller 402. A VLAN configuration determination engine 408 in the controller 402 is able to determine a VLAN configuration based on information extracted from LLDPDUs transmitted by

OpenFiow switches to their neighbors. From the VLAN configuration, connectivity of OpenFlow switches in the controlled network can be determined by the controller 402.

[0068] !n other examples, a different protocol can be used to perform neighbor discovery of OpenFlow switches. For example, the OpenFlow protocol can be extended to support neighbor discovery. In other examples, other protocols can be used.

[0069] Fig. 5A is a flow diagram of a process performed by a first OpenFlow switch (e.g. any of OpenFlow switches A, B, and C in Fig. 4), in accordance with some implementations. The OpenFlow switch receives (at 502) virtual network information about one or multiple virtual networks of a second OpenFlow switch. For example, the virtual network information can include identifier(s) of VLAN(s) of the second OpenFlow switch. In some examples, the information can be received in an

LLDPDU. The LLDPDU can also include an identifier of the second OpenFlow switch.

[0070] The first OpenFlow switch sends (at 504) the received virtual network information to the controller 402. Note that the first OpenFlow switch may receive information from multiple other OpenFlow switches. The first OpenFlow switch is able to forward such received information from multiple other OpenFlow switches to the controller 402.

[0071 ] In some implementations, not all of the information received in an LLDPDU from a neighbor OpenFlow switch is forwarded by the first OpenFlow switch to the controller 402. Since LLDP is a protocol that is at the link layer, LLDP can cause discovery of a neighbor OpenFlow switch that does not share any VLANs with the first OpenFlow switch. For example, the first OpenFlow switch can communicate over a first set of VLANs, while the neighbor OpenFlow switch can communicate over a second set of VLANs that does not share any VLAN in common with the first set. As a result, the first OpenFlow switch will not be able to communicate with the neighbor OpenFlow switch, since they do not have any VLAN in common. Although an LLDPDU from the neighbor OpenFlow switch can be received by the first OpenFlow switch, it is noted that such infornnation should be disregarded since the first OpenFlow switch and the neighbor OpenFlow switch cannot communicate with each other.

[0072] Thus, the OpenFlow engine 406 of the first OpenFlow switch can prune (remove) information received in an LLDPDU from a neighbor OpenFlow switch that has no overlapping VLANs with the first OpenFlow switch. The pruned information is not forwarded by the first OpenFlow switch to the controller 402.

[0073] Fig. 5B is a flow diagram of a process performed by the controller 402, according to some implementations. The VLAN configuration determination engine 408 of the controller 402 receives (at 510) VLAN-related information (along with information identifying OpenFlow switches) from OpenFlow switches in a controlled network. The VLAN configuration determination engine determines (at 512) a VLAN configuration of the controlled network based on the VLAN-related information received from the OpenFlow switches. From the VLAN configuration, the controller 402 can build a map of the links between the OpenFlow switches to derive the topology of the controlled network.

[0074] Once the VLAN configuration is known to the controller 402, the controller 402 is able to inject discovery packets, or other types of packets, into the controlled network with respective VLAN-related tags, so that proper forwarding of the injected packets over corresponding VLANs can be performed.

[0075] Fig. 6A is a block diagram of a switch 600 (which can be used to implement an OpenFlow switch 104) according to some implementations. The switch 600 includes processing hardware 602 and a non-transitory machine-readable or computer-readable storage medium (or storage media) 604. The storage medium (or storage media) 604 can include OpenFlow machine-readable instructions 606 that are executable on the processing hardware 602. The combination of the OpenFlow instructions 606 and the processing hardware 602 can implement an OpenFlow switch as discussed above. Note that the OpenFlow instructions 606 can include instructions of the packet replication engine 1 14, LLDP engine 404, and OpenFlow engine 406 discussed above.

[0076] Fig. 6B is a block diagram of the controller 102 or 402 according to some implementations. The controller 102 or 402 includes processing hardware 610 and a non-transitory machine-readable or computer-readable storage medium (or storage media) 612. The storage medium (or storage media) 612 can include replication control machine-readable instructions 614 and VLAN configuration determination machine-readable instructions 616 that are executable on the processing hardware 610.

[0077] The replication control instructions 614 include instructions of the replication control engine 1 10, and the VLAN configuration determination instructions 616 include instructions of the VLAN configuration determination engine 408.

[0078] The storage medium (or storage media) 604 or 612 can include one or multiple different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and

programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple

components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution. [0079] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

What is claimed is: 1 . A method comprising:

receiving, by a data plane switch in a controlled network that is controlled by a controller remote from the data plane switch, a message including an indicator indicating replication of a packet to a plurality of virtual networks; and

responsive to the indicator, sending, by the data plane switch, replicated copies of the packet to the plurality of virtual networks.

2. The method of claim 1 , further comprising tagging at least one of the replicated copies of the packet with virtual network information.

3. The method of claim 1 , wherein sending the replicated copies of the packet comprises sending the replicated copies of the packet used by the controller to discover links in a controlled network.

4. The method of claim 1 , wherein sending the replicated copies of the packet to the plurality of virtual networks comprises sending a particular replicated copy of the replicated copies of the packet to another data plane switch that forwards the particular replicated copy to the controller.

5. The method of claim 1 , wherein receiving the message comprises receiving a message according to an Open Flow protocol.

6. The method of claim 5, wherein receiving the message comprises receiving the message containing an instruction to replicate a packet associated with a given characteristic to all virtual networks of the data plane switch.

7. The method of claim 6, wherein with the given characteristic is selected from a given buffer identifier and a given Ethernet type .

8. The method of claim 1 , further comprising one of:

receiving the packet in the message including the indicator, or

receiving the packet in a message separate from the message including the indicator.

9. The method of claim 1 , wherein sending the replicated copies of the packet to the plurality of virtual networks comprises sending the replicated copies of the packet to a plurality of virtual local area networks (VLANs).

10. A first data plane switch comprising:

at least one processor to:

receive virtual network information about one or multiple virtual networks provided at a second data plane switch; and

send the received virtual network information to a controller of a controlled network that includes the first and second data plane switches.

1 1 . The first data plane switch of claim 10, wherein receiving the virtual network information comprises receiving the virtual network information in a Link Layer Discovery Protocol (LLDP) message.

12. The first data plane switch of claim 10, wherein the at least one processor is to further:

receive virtual network information about one or multiple virtual networks provided at a third data plane switch; and

send the received virtual network information about the one or multiple virtual networks provided at the second data plane switch to the controller.

13. The first data plane switch of claim 10, wherein the at least one processor is to further:

receive a packet injected by the controller, the packet including a tag containing information relating to at least one virtual network, the information in the tag based on the virtual network information sent by the first data plane switch to the controller.

14. A controller comprising:

at least one processor to:

send a message including a replication indicator to a first data plane switch, the replication indicator indicating replication of a packet to virtual networks of the first data plane switch;

send a given packet to a first data plane switch, the given packet untagged with respect to virtual networks; and

receive a replicated copy of the given packet from a second data plane switch.

15. The controller of claim 14, wherein sending the given packet comprises sending the given packet in one of the message including the replication indicator or another message separate from the message including the replication indicator.