[go: up one dir, main page]

WO2016122570A1 - Envoi d'informations dans un réseau contrôlé par un contrôleur - Google Patents

Envoi d'informations dans un réseau contrôlé par un contrôleur Download PDF

Info

Publication number
WO2016122570A1
WO2016122570A1 PCT/US2015/013703 US2015013703W WO2016122570A1 WO 2016122570 A1 WO2016122570 A1 WO 2016122570A1 US 2015013703 W US2015013703 W US 2015013703W WO 2016122570 A1 WO2016122570 A1 WO 2016122570A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
data plane
controller
switch
plane switch
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2015/013703
Other languages
English (en)
Inventor
Shaun Wackerly
Marjorie Krueger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Priority to PCT/US2015/013703 priority Critical patent/WO2016122570A1/fr
Publication of WO2016122570A1 publication Critical patent/WO2016122570A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks

Definitions

  • a communications network can include switches to pass data from a source endpoint device to one or multiple destination endpoint devices.
  • 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).
  • SDN Software-Defined Network
  • 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.
  • Fig. 1 is a block diagram of an example network arrangement according to some implementations.
  • FIG. 2A is a flow diagram of a process of an OpenFlow switch according to some implementations.
  • Fig. 2B is a flow diagram of a process of a controller according to some implementations.
  • FIG. 3 is a block diagram of another example network arrangement according to some implementations.
  • Fig. 4 is a block diagram of a further example network arrangement according to further implementations.
  • Fig. 5A is a flow diagram of a process of an OpenFlow switch according to further implementations.
  • Fig. 5B is a flow diagram of a process of a controller according to further implementations.
  • Fig. 6A is a block diagram of a switch according to some implementations.
  • Fig. 6B is a block diagram of a controller according to some implementations. Detailed Description
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • a switch that operates according to OpenFlow can be referred to as an OpenFlow switch or an OpenFlow instance.
  • 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.
  • 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).
  • 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.
  • Traffic data e.g. user data, data of applications, etc.
  • Tables used for forwarding packets can include a flow table (or multiple flow tables).
  • 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
  • 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.
  • 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.
  • VLANs Virtual Local Area Networks
  • 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.
  • 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
  • a data packet injected by the SDN controller may not include a header related to VLAN.
  • 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.
  • IEEE 802.1 Q standard defines a technique of tagging a packet (and more specifically, an Ethernet frame) to identify a respective VLAN.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • OpenFlow switch is configured to communicate over a respective set of one or multiple VLANs.
  • OpenFlow switch A is configured to communicate over VLANs 1 and 2
  • OpenFlow switch B is configured to communicate over VLANs 2, 3, and 4.
  • 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.
  • 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.
  • 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.
  • ASIC application-specific integrated circuit
  • 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.
  • 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.
  • 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.
  • 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).
  • a packet e.g. a discovery packet or other type of packet
  • 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.
  • the added tag is a tag according to IEEE 802.1 Q.
  • 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.
  • 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.
  • 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.
  • 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.
  • experimenter can refer to any entity that desires to perform an action in the controlled network 106.
  • the controller 102 can instruct an OpenFlow switch 104 to perform either of the following:
  • 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.
  • 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.
  • a buffer ID refers to a packet stored in a buffer in an OpenFlow switch.
  • the packet 1 16 is stored in a buffer of OpenFlow switch A, and is associated with a respective buffer ID.
  • 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.
  • IP Internet Protocol
  • IPv4 IP version 4
  • IPv6 IP version 6
  • ARP Address Resolution Protocol
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the replication indicator can be included in the same message that also contains the packet to be replicated.
  • 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
  • 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).
  • a packet e.g. a discovery packet
  • the packet can be sent by the controller 102 in a PACKET_OUT message according to OpenFlow, for example.
  • the replication indicator can be included in the message that carries the packet.
  • 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.
  • 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.
  • Each physical switch has respective ports.
  • physical switch A has ports 1 and 2 (labelled as 302 and 304, respectively, in Fig. 3).
  • physical switch B has ports 1 and 2
  • physical switch C has ports 1 and 2.
  • 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 a switch that is not controlled by the controller 102 (or controllers 102).
  • uncontrolled switch 306 is able to route packets from the controlled network that includes the OpenFlow switches to a non-OpenFlow network 308.
  • 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
  • OpenFlow switch Cy is configured to communicate over VLAN 2.
  • 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.
  • 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.
  • the controller 102 is able to discover both the direct links and the multi- hop link.
  • the controller 102 does not have to be VLAN-aware to perform link discovery (or other operations) in a controlled network that includes VLANs.
  • 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.
  • OpenFlow switches A, B, and C each includes a Link Layer Discovery Protocol (LLDP) engine 404 and an OpenFlow engine 406.
  • LLDP Link Layer Discovery Protocol
  • 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.
  • 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).
  • T represents type
  • L represents length
  • V represents value (L indicates the length of the value V).
  • the type (T) indicates what information is encoded in the V content.
  • LLDPDU contains actual information that is being communicated.
  • 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
  • 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.
  • OpenFiow protocol e.g. forward a packet according to one or multiple flow tables
  • each LLDP engine 404 is able to send an LLDPDU that advertises the respective OpenFiow switch and the VLANs of the OpenFiow switch.
  • 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.
  • the LLDPDU can include information of the OpenFiow switch along with VLAN-related information (e.g. an identifier of a VLAN)
  • 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.
  • 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.
  • 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.
  • a different protocol can be used to perform neighbor discovery of OpenFlow switches.
  • the OpenFlow protocol can be extended to support neighbor discovery.
  • other protocols can be used.
  • 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.
  • the virtual network information can include identifier(s) of VLAN(s) of the second OpenFlow switch.
  • the information can be received in an
  • the LLDPDU can also include an identifier of the second OpenFlow switch.
  • the first OpenFlow switch sends (at 504) the received virtual network information to the controller 402.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the OpenFlow instructions 606 can include instructions of the packet replication engine 1 14, LLDP engine 404, and OpenFlow engine 406 discussed above.
  • 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.
  • 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.
  • 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
  • semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and
  • EEPROMs programmable read-only memories
  • 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.
  • EEPROMs programmable read-only memories
  • 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.
  • CDs compact disks
  • DVDs digital video disks
  • 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
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un commutateur de plan de données dans un réseau contrôlé, qui est contrôlé par un contrôleur, reçoit un message contenant un indicateur indiquant la duplication d'un paquet dans une pluralité de réseaux virtuels. En réponse à l'indicateur, le commutateur de plan de données envoie des copies dupliquées du paquet à la pluralité de réseaux virtuels.
PCT/US2015/013703 2015-01-30 2015-01-30 Envoi d'informations dans un réseau contrôlé par un contrôleur Ceased WO2016122570A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2015/013703 WO2016122570A1 (fr) 2015-01-30 2015-01-30 Envoi d'informations dans un réseau contrôlé par un contrôleur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/013703 WO2016122570A1 (fr) 2015-01-30 2015-01-30 Envoi d'informations dans un réseau contrôlé par un contrôleur

Publications (1)

Publication Number Publication Date
WO2016122570A1 true WO2016122570A1 (fr) 2016-08-04

Family

ID=56543992

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/013703 Ceased WO2016122570A1 (fr) 2015-01-30 2015-01-30 Envoi d'informations dans un réseau contrôlé par un contrôleur

Country Status (1)

Country Link
WO (1) WO2016122570A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019240602A1 (fr) * 2018-06-12 2019-12-19 Intel Corporation Technologies de partage de ressources de duplication de paquets dans un système de commutation

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090138577A1 (en) * 2007-09-26 2009-05-28 Nicira Networks Network operating system for managing and securing networks
JP2009177281A (ja) * 2008-01-22 2009-08-06 Keio Gijuku ネットワークシステム
JP2009177282A (ja) * 2008-01-22 2009-08-06 Keio Gijuku ネットワークシステム
US20130010799A1 (en) * 2011-05-13 2013-01-10 International Business Machines Corporation Efficient Software-Based Private VLAN Solution for Distributed Virtual Switches
US20140016647A1 (en) * 2011-03-29 2014-01-16 Hirokazu Yoshida Network system and vlan tag data acquiring method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090138577A1 (en) * 2007-09-26 2009-05-28 Nicira Networks Network operating system for managing and securing networks
JP2009177281A (ja) * 2008-01-22 2009-08-06 Keio Gijuku ネットワークシステム
JP2009177282A (ja) * 2008-01-22 2009-08-06 Keio Gijuku ネットワークシステム
US20140016647A1 (en) * 2011-03-29 2014-01-16 Hirokazu Yoshida Network system and vlan tag data acquiring method
US20130010799A1 (en) * 2011-05-13 2013-01-10 International Business Machines Corporation Efficient Software-Based Private VLAN Solution for Distributed Virtual Switches

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019240602A1 (fr) * 2018-06-12 2019-12-19 Intel Corporation Technologies de partage de ressources de duplication de paquets dans un système de commutation
US11469915B2 (en) 2018-06-12 2022-10-11 Intel Corporation Technologies for sharing packet replication resources in a switching system

Similar Documents

Publication Publication Date Title
EP3677000B1 (fr) Procédé et système de traçage de paquets dans des réseaux définis par logiciel
EP3808040B1 (fr) Appareil et procédé de pistage de paquets dans un pipeline de traitement de paquets d'un commutateur de mise en réseau définie par logiciel
EP3879759B1 (fr) Dépannage de chemin de données optimisé à l'aide d'un moteur de politique de trace
US10291555B2 (en) Service based intelligent packet-in buffering mechanism for openflow switches by having variable buffer timeouts
EP3391588B1 (fr) Noeuds sdn hybrides divisés horizontalement et configurés par openflow
US10263808B2 (en) Deployment of virtual extensible local area network
EP3834365B1 (fr) Versionnage d'arbres de distribution multidiffusion pour minimiser les perturbations du trafic des groupes de multidiffusion
US11283711B2 (en) Efficient VPN route refresh mechanism for BGP based VPN technologies
US20160212048A1 (en) Openflow service chain data packet routing using tables
US20180375755A1 (en) Mechanism to detect control plane loops in a software defined networking (sdn) network
US20160006646A1 (en) Multicasting a data message in a multi-site network
US20160315866A1 (en) Service based intelligent packet-in mechanism for openflow switches
CN110380959B (zh) 转发报文方法和装置
EP3528441B1 (fr) Transfert de message
EP4046351B1 (fr) Découverte de rtps dans kubernetes
WO2020212998A1 (fr) Attribution d'adresse de réseau dans un domaine de couche 2 virtuel s'étendant sur de multiples grappes de conteneurs
JP6629681B2 (ja) スイッチ装置および中継システム
US20190215191A1 (en) Deployment Of Virtual Extensible Local Area Network
US20200236132A1 (en) Threat response in a multi-router environment
WO2016122570A1 (fr) Envoi d'informations dans un réseau contrôlé par un contrôleur
CN115668883B (zh) 以太网虚拟私用网络出口快速重路由中的瞬变环路防止
US11876881B2 (en) Mechanism to enable third party services and applications discovery in distributed edge computing environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15880465

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15880465

Country of ref document: EP

Kind code of ref document: A1