WO2015096409A1 - 软件定义网络中的链路发现方法、装置及系统 - Google Patents

软件定义网络中的链路发现方法、装置及系统 Download PDF

Info

Publication number
WO2015096409A1
WO2015096409A1 PCT/CN2014/079983 CN2014079983W WO2015096409A1 WO 2015096409 A1 WO2015096409 A1 WO 2015096409A1 CN 2014079983 W CN2014079983 W CN 2014079983W WO 2015096409 A1 WO2015096409 A1 WO 2015096409A1
Authority
WO
WIPO (PCT)
Prior art keywords
link discovery
controller
switch
packet
link
Prior art date
Application number
PCT/CN2014/079983
Other languages
English (en)
French (fr)
Inventor
张君辉
喻敬海
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2015096409A1 publication Critical patent/WO2015096409A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • 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

  • the present invention relates to the field of computer networks and communication technologies, and in particular to a software defined network.
  • LLDP Link Layer Discovery Protocol
  • the link discovery of the OpenFlow network is initiated by the controller, that is, the controller encapsulates the LLDP packet in the Pa C ket_Out message and sends it to the OF switch 1; the OpenFlow agent protocol of the switch 1 receives the Packet_Out message.
  • the OpenFlow protocol header is stripped, and the LLDP packet format is parsed and sent from the port 1.
  • the OF switch 2 receives the LLDP packet, it sends the LLDP packet to the local OpenFLow agent protocol according to the configured flow table matching information and action.
  • the local OpenFLow agent protocol encapsulates the LLDP packet into a Packetjn message and sends it to the controller for processing.
  • the controller analyzes the LLDP information in the packetjn message and determines that there is a physical connection between port 1 of switch 1 and port 2 of switch 2.
  • the purpose of link discovery Through the above process, the controller can discover other physical connections and discover the topology path of the entire OpenFlow network.
  • the above related technologies mainly have the following problems: Problem 1.
  • the OpenFlow network supports multi-instance deployment, and the openflow network topology discovered by each controller is based on a single instance.
  • the OpenFlow Switch (OFS) device supports multiple OpenFlow Instances (OFIs).
  • the receiver cannot distinguish which OFI the LLDP packet belongs to. Decide which controller to send the LLDP message to.
  • Question 2 if the OFS is a hybrid device, that is, the OFS supports both the openflow application and the legacy application. For example, the connection port between the two OFSs is shared by OpenFlow and the legacy application. In this case, the traditional application and openflow will send LLDP packets between the switches. The LLDP packets sent by the sender do not carry the identification information of the openflow and the traditional applications. Therefore, the receiver cannot decide to deliver the LLDP packets. Handle the traditional application, or send it to the controller for processing.
  • the chassis id TLV (type length value) of the LLDP packet sent by the source switch is the device identifier, which is used to carry the device information of the source switch, such as the MAC address; the port id TIN carries the outbound port information.
  • the destination switch After receiving the LLDP packet, the destination switch forwards the packet to the controller through packetjn. The controller cannot identify whether it is the LLDP sent by itself.
  • a link discovery method in a software defined network includes: the controller sends a first link discovery packet to the source switch, where the first link discovery packet carries a corresponding to the source switch Instance identification information; the controller receives a second link discovery message sent by the destination switch; and the controller determines the received second link discovery message and the sent first link discovery report Whether the instance identification information carried in the text is the same. If they are the same, it is determined that there is a link connection between the source switch and the destination switch.
  • the method further includes: the controller establishing a TCP/SSL connection with the source switch, and acquiring an instance identifier corresponding to the source switch. information.
  • the controller has learned the instance identification information corresponding to the destination switch
  • the first link discovery packet further carries instance identification information corresponding to the destination switch.
  • the first link discovery message and the second link discovery message are a link layer discovery protocol LLDP.
  • the instance identification information includes: a data path DP identifier.
  • the instance identification information is carried in an optional type length value TIN of the LLDP message.
  • the link discovery device in a software-defined network is located in the controller, and includes: a sending module, configured to send a first link discovery packet to the source switch, where the first link discovery packet is Carrying the instance identification information corresponding to the source switch; the receiving module is configured to receive the second link discovery packet sent by the destination switch; and the determining module is configured to determine the received second link discovery packet Whether the instance identification information carried in the first link discovery packet is the same as the sending; the determining module is configured to: when the determining module determines that the two instance identification information are the same, determine the source switch and the There is a link connection between the destination switches.
  • the method further includes: a connection module, configured to establish a transmission control layer protocol TCP/Secure Sockets Layer SSL connection with the source switch; and an acquisition module configured to obtain by using a TCP/SSL connection established with the source switch Instance identification information corresponding to the source switch.
  • the first link discovery packet further carries instance identification information corresponding to the destination switch.
  • the method for processing the link discovery packet includes: the destination switch receives the link discovery packet from the source switch; and the destination switch determines whether the received link discovery packet carries the information The first instance identification information corresponding to the source exchange is performed, and if yes, the link discovery message is sent to the controller.
  • the sending the link discovery message to the controller includes: determining, by the destination switch, whether the received link discovery packet carries the second instance identifier information corresponding to the destination switch, if yes, Sending a link discovery message to a controller that manages an instance corresponding to the second instance identification information; otherwise, sending a link discovery message to all controllers connected to the destination switch.
  • the method further includes: the destination switch is in the direction
  • the second instance identification information is added to the link discovery message sent by all controllers.
  • a device for processing a link discovery message is provided.
  • the processing device for the discovery message according to the present invention is located in the destination switch, and the device includes: a receiving module configured to receive a link discovery message from the source switch; and a first determining module configured to determine the received chain Whether the path discovery message carries the first instance identification information corresponding to the source exchange; and the sending module is configured to send a link discovery to the controller if the determination result of the first determining module is yes Message.
  • the device further includes: a second determining module, configured to determine whether the received link discovery message carries the second instance identification information corresponding to the destination switch, and if so, triggering The sending module sends the link discovery packet to the controller that manages the instance corresponding to the second instance identifier information, otherwise, the sending module is triggered to send the link discovery packet to the destination switch. All controllers connected.
  • the device further includes: a processing module, configured to: when the second determining module determines that the received link discovery packet does not carry the second instance identifier information corresponding to the destination switch, Adding the second instance identifier information to the link discovery packet sent by the sending module.
  • a link discovery system in a software-defined network including: a controller, including a link discovery device in the software-defined network; and a source switch configured to receive the controller to send The link discovery packet sends the link discovery packet to the destination switch; the destination switch includes the foregoing link discovery packet processing device.
  • the invention can not only distinguish the openflow service from the traditional application but also distinguish multiple openflow instances by using the instance identification information in the link discovery packet, so that the controller can identify whether the received link discovery packet is The link discovery packet sent by itself avoids the judgment of the connection relationship.
  • FIG. 1 is a schematic diagram of link discovery adopted in the prior art
  • 2 is a flowchart of a link discovery method in a software-defined network according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of a link discovery apparatus in a software-defined network according to an embodiment of the present invention
  • FIG. 1 is a schematic diagram of link discovery adopted in the prior art
  • 2 is a flowchart of a link discovery method in a software-defined network according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of a link discovery apparatus in a software-defined network according to an embodiment of the present invention
  • FIG. 1 is a schematic diagram of link discovery adopted in the prior art
  • 2 is a flowchart of a link discovery method in a software-defined network according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of a link discovery apparatus in a software-defined network according to an embodiment of the present invention
  • FIG. 1 is a schematic diagram of link discovery adopted in the
  • FIG. 5 is a schematic structural diagram of a device for processing a link discovery message according to an embodiment of the present invention
  • FIG. 6 is a schematic diagram of a device for processing a link discovery message according to an embodiment of the present invention
  • FIG. 7 is a schematic diagram of link discovery in the first embodiment
  • FIG. 8 is a schematic diagram of link discovery in the second embodiment
  • FIG. 9 is a second schematic diagram of link discovery in the second embodiment
  • FIG. 11 is a schematic diagram of link discovery of the fourth embodiment
  • FIG. 12 is a schematic diagram of module interaction of the source switch in the fifth embodiment
  • FIG. 13 is a schematic diagram of module interaction of the destination switch in the fifth embodiment. .
  • FIG. 2 is a flowchart of a link discovery method in a software-defined network according to an embodiment of the present invention. As shown in FIG. 2, the method mainly includes the following steps S202-S206. Step S202: The controller sends a first link discovery message to the source switch, where the first link discovery message carries instance identification information corresponding to the source switch.
  • the link discovery packet sent by the controller to the source switch carries the instance identification information corresponding to the source switch, where the link discovery packet sent by the controller to the source switch may be LLDP (chain The Layer 2 Discovery Protocol packet carries the information identifying the OpenFlow instance in the link layer discovery protocol.
  • the instance identification information can be used to distinguish not only OpenFlow and traditional applications, but also multiple OpenFlow instances.
  • the controller may be above example link discovery identification information encapsulated packet, then the link discovery packets encapsulated Packet_ 0U t send message.
  • the controller may obtain a Transmission Control Protocol (TCP)/Secure Sockets Layer (SSL) connection with the source switch, and obtain a corresponding source switch from the source switch.
  • TCP Transmission Control Protocol
  • SSL Secure Sockets Layer
  • the instance identification information (that is, the identification information of the instance managed by the controller in the source switch).
  • the controller may also be in the first link.
  • the discovery packet carries the instance identification information corresponding to the destination switch (that is, the identifier information corresponding to the instance managed by the controller in the destination switch).
  • the foregoing instance identification information includes but is not limited to: a data path DP identifier (datapath id).
  • the foregoing instance identification information may be carried in an optional TIN of the LLDP message.
  • the TIN type specified in the existing LLDP protocol specification "Station and Media Access Control Connectivity Discovery" Table 8.1 can be extended, and a TIN type is added to carry the Datapath ID information of the OpenFlow switch.
  • the expanded TIN type is shown in Table 1. Table 1.
  • Type value can be used
  • Step S204 The controller receives the second link discovery packet sent by the destination switch.
  • the first link discovery packet sent by the controller reaches the source switch, and the source switch sends the first link discovery packet to the egress port designated by the controller, and the egress port reaches the destination switch.
  • the destination switch parses the first link discovery packet, and if the link discovery protocol does not carry the instance identification information, the first link discovery packet is sent to the traditional application for processing, and if the instance identification information is carried, The ingress port of the destination switch is added to the first link discovery packet to obtain the second link discovery packet, and then the second link discovery packet is sent to the controller.
  • the destination switch may first determine whether the first link discovery packet carries the destination instance identifier (ie, the destination switch) before sending the second link discovery packet to the controller. Corresponding instance identification information, if yes, determining whether the instance identifier is consistent with the local instance identifier, and if yes, sending a second link discovery packet to the TCP/SSL connection corresponding to the instance identifier; otherwise, to all The controller sends a second link discovery message.
  • the destination switch may encapsulate the foregoing second link discovery packet and send the packet in the Packetjn message.
  • Step S206 The controller determines whether the received second link discovery packet is the same as the instance identifier information carried in the sent first link discovery packet, and if the same, determines the source switch and the source There is a link connection between the destination switches.
  • the method provided by the embodiment of the present invention carries the instance identification information corresponding to the source switch in the link discovery packet, so that the openflow service and the traditional application, and multiple openflow instances can be distinguished, and the link discovered by the controller is improved. The accuracy.
  • a link discovery device in a software-defined network is provided, and the device may be located in a controller for implementing the link discovery method in the software-defined network.
  • the apparatus mainly includes: a sending module 302, configured to send a first link discovery packet to a source switch.
  • the first link discovery packet carries the instance identifier information corresponding to the source switch;
  • the receiving module 304 is configured to receive the second link discovery packet sent by the destination switch;
  • the determining module 308 is configured to determine two instance identification information in the determining module. In the same case, it is determined that there is a link connection between the source switch and the destination switch.
  • connection relationship of each module shown in FIG. 3 is only an example, and those skilled in the art can fully adopt other connection relationships, as long as each module can implement the functions of the present invention under such a connection relationship.
  • the functions of the respective modules can be realized by using dedicated hardware or hardware capable of performing processing in combination with appropriate software.
  • Such hardware or special purpose hardware may include application specific integrated circuits (ASICs), various other circuits, various processors, and the like.
  • ASICs application specific integrated circuits
  • processors When implemented by a processor, this functionality may be provided by a single dedicated processor, a single shared processor, or multiple independent processors, some of which may be shared.
  • a processor should not be understood to refer to hardware capable of executing software, but may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random Access memory (RAM), and non-volatile storage devices.
  • DSP digital signal processor
  • ROM read-only memory
  • RAM random Access memory
  • the apparatus may further include: a connection module, configured to establish a TCP/SSL connection with the source switch; and an acquiring module, configured to establish a TCP between the source switch and the source switch /SSL connection, obtaining instance identification information corresponding to the source switch.
  • the first link discovery packet may further carry instance identification information corresponding to the destination switch.
  • the link discovery device in the software-defined network may adopt an optional implementation solution corresponding to the link discovery method in the software-defined network, and details are not described herein.
  • a method for processing a link discovery packet is further provided, and the method is configured to process a link discovery packet on the destination switch side corresponding to the link discovery in the software-defined network.
  • FIG. 4 is a flowchart of a method for processing a link discovery message according to an embodiment of the present invention. As shown in FIG. 4, the method mainly includes the following steps S402 to S404. Step S402, the destination switch receives the link discovery packet from the source switch.
  • Step S404 The destination switch determines whether the received link discovery packet carries the first instance identifier information corresponding to the source exchange, and if yes, sends a link discovery packet to the controller. In the actual application, the destination switch forwards the received link discovery packet to its OpenFlow proxy before sending the link discovery packet to the controller.
  • the OpenFlow proxy receives the received packet according to the processing method in the related technology.
  • the link discovery packet is processed. For example, the inbound port information is added to the received link discovery packet, and then the processed link discovery packet is sent to the controller.
  • the destination switch may determine whether the received link discovery packet carries the corresponding destination switch.
  • the second instance identifier information if yes, the destination switch sends a link packet to the controller that manages the instance corresponding to the second instance identifier information. Otherwise, the destination switch connects to the destination switch.
  • the controller sends a link packet.
  • the destination switch may also be in the link discovery packet sent to all controllers. Add second instance identification information.
  • FIG. 5 is a schematic structural diagram of a device for processing a link discovery packet according to an embodiment of the present invention. As shown in FIG.
  • the device may include: a receiving module 502, configured to receive a link discovery packet from a source switch;
  • the first determining module 504 is configured to determine whether the received link discovery packet carries the first instance identifier information corresponding to the source exchange, and the sending module 506 is configured to be processed by the processing module.
  • the link discovery message is sent to the controller.
  • Such hardware or special purpose hardware may include application specific integrated circuits (ASICs), various other circuits, various processors, and the like. When implemented by a processor, this functionality may be provided by a single dedicated processor, a single shared processor, or multiple independent processors, some of which may be shared.
  • a processor should not be understood to refer to hardware capable of executing software, but may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random Access memory (RAM), and non-volatile storage devices.
  • DSP digital signal processor
  • ROM read-only memory
  • RAM random Access memory
  • the foregoing apparatus may further include: a second determining module, configured to determine whether the received link discovery packet carries a second corresponding to the destination switch Instance identification information, if yes, triggering the sending module to send the link discovery packet to a controller that manages an instance corresponding to the second instance identifier information, otherwise, triggering the sending module to trigger the link
  • the discovery message is sent to all controllers connected to the destination switch.
  • the device may further include: a processing module, configured to send, by the sending module 506, when the second determining module determines that the received link discovery packet does not carry the second instance identifier information corresponding to the destination switch. The second instance identification information is added to the link discovery packet.
  • the controller can learn the instance identification information corresponding to the destination switch, and the next time the link discovery packet is sent, the instance identification information can be carried in the link discovery packet to prevent the destination switch from broadcasting the link discovery packet.
  • the processing module can be implemented by the openflow proxy of the destination switch itself.
  • the processing module can also process the link discovery packet according to the existing manner. For example, the processing module can be in the first determining module. If the result of the determination is YES, the ingress port information of the link discovery message is added to the received link discovery message as the link message sent by the sending module 506.
  • a link discovery system in a software defined network is also provided. FIG.
  • FIG. 6 is a schematic structural diagram of a link discovery system in a software-defined network according to an embodiment of the present invention.
  • the system may include: a controller 62, which may include a link discovery device in the software-defined network;
  • the source switch 64 is configured to receive the link discovery message sent by the controller 62, and send the link discovery message to the destination switch 66.
  • the destination switch 66 may include the foregoing link discovery message processing device.
  • the encapsulation of the OpenFlow instance identification information may be performed in the controller.
  • the OpenFlow instance identifier includes a source switch instance identifier (0 or 1) and a destination switch instance identifier (0, 1 or more).
  • the source switch instance identifier is carried only.
  • the source switch instance identifier and the destination switch instance identifier are encapsulated according to the learned destination switch instance identifier. If the source device does not carry the source instance identification information, the protocol discovery packet is sent to the traditional application for processing. Otherwise, if the source instance identification information is carried, the destination instance identifier in the LLDP packet is checked. Same as the local instance ID.
  • the Packetjn message is sent to the TCP/SSL connection corresponding to the instance ID. Otherwise, the Packet_In message is sent to all controllers. Then, the controller parses the protocol packet. If the protocol packet carries the source instance identifier information and is consistent with the OpenFlow instance ID of the controller, the link between the two OpenFlow instances is considered to be connected; otherwise, There is no link connection between the two instances.
  • the instance identification information is datapathjd is taken as an example for description. However, it is not limited thereto, and it is obvious to those skilled in the art that other information may be used as long as the information can distinguish between an OpenFlow instance and a legacy application, and multiple OpenFlow instances.
  • Embodiment 1 This embodiment describes a link discovery between hybrid OF devices as an example.
  • the figure includes an SDN controller and two OpenFlow switches, wherein the OFS is a hybrid OF device, that is, supports the traditional L2/L3 application in addition to supporting the OpenFlow application.
  • the OFS is a hybrid OF device, that is, supports the traditional L2/L3 application in addition to supporting the OpenFlow application.
  • a TCP/SSL connection is established between the OFS and the OFC.
  • the switch After the controller senses that a switch is added, the switch sends a link layer discovery protocol packet to the switch and other switches to sense the physical connection status between the switches.
  • the existing L2 application when LLDP is enabled, sends LLDP packets to all physical port cycles to sense the physical connection status between devices.
  • the specific process of link discovery of the OpenFlow may include the following steps 1 - 7. Step 1, the controller and the switch establish a TCP/SSL connection, and the controller sends
  • the OFPT FEATURES REQUEST message obtains the datapathjd information of the switch instance.
  • the controller learns that two open-flow switches are connected, corresponding to dpidl (OFS1) and dpid2 (OFS2).
  • Step 2 When the switch port joins the openflow instance, the openflow port number and status are notified to the controller through the OFPT_PORT_STATUS message.
  • the controller learns that port 1 on OFS1 is added to dpidl, and port 2 on OFS2 is added to dpid2.
  • Step 3 The controller actively sends a PacketOut message (port 1 in FIG.
  • Step 4 The local OpenFlow Agent module of the OFS1 receives the PacketOut message, parses the LLDP packet, and sends it to the egress port specified by the controller.
  • the LLDP packet parsed is sent to port 1, and the internal information of the LLDP packet is unchanged.
  • the LLDP protocol is run on both switches to detect the connection relationship of the physical link.
  • port 1 of switch 1 can run the openflow service or the traditional service. Therefore, the traditional application module of switch 1 will also send LLDP packets to port 1.
  • Step 5 The OFS2 receives the LLDP packet sent by the traditional application (without the OF instance identifier) and the LLDP packet sent by the OpenFlow (with the OF instance identifier), and the LLDP packet is sent to the traditional Application processing, or OF application processing (the prior art is by judging the extended ethertype or destination multicast mac address).
  • the OF instance identifier is not carried (the TIN type is determined), it is handed over to the traditional application processing; otherwise, it is handed over to the OpenFlow Agent for processing, and the OpenFlow Agent encapsulates the LLDP carrying the OF instance identification information and sends it to the controller through the Packetln message.
  • the inbound port number of the LLDP packet is carried in the Packet_In message.
  • the controller receives the Packet_In message, and determines the TCP/SSL connection and the datapathjd (equal to dpid2) corresponding to the message.
  • the controller analyzes the ingress port number and the internal LLDP information in the Packetln message, and the There is a physical connection between port 1 of dpidl of OFS1 and port 2 of dpid2 of OFS2.
  • Step 7 the controller will detect that there is a connection relationship in the direction from port 1 of OFS1 to port 2 of OFS2d.
  • the controller may send a Packet_Out message in the opposite direction (ie, to the port 2 of the OFS2 switch dpid2) to detect whether there is a connection relationship from the port 2 of the OFS2 to the port 1 of the OFS1.
  • the processing is the same. , the details will not be described again.
  • the second embodiment of the present invention is a schematic diagram of the link discovery process in the multi-OFI scenario in the embodiment.
  • the second embodiment of the present invention is a schematic diagram of the link discovery process in the multi-OFI scenario in the embodiment.
  • Each switch is configured with two instances.
  • Each switch is configured with two datapath_ids, which are OFSl (dpidl, dpid2) OFS2 (dpid3 dpid4).
  • the link discovery in this embodiment may specifically include the following steps 1 - 7.
  • Step 1 The controller 1 establishes a TCP/SSL connection with the switches OFS1 and OFS2, and the controller 1 sends an OFPT FEATURES REQUEST message to obtain the datapathjd information of the switch instance.
  • controller 1 learns that two open-flow switches are connected, corresponding to dpidl (OFS1) and dpid3 (OFS2).
  • Controller 2 establishes a TCP/SSL connection with switches OFS1 and OFS2, and controller 2 sends an OFPT FEATURES REQUEST message to obtain the datapathjd information of the switch instance.
  • controller 2 learns that two open-flow switches are connected, corresponding to dpid2 (OFS1) and dpid4 (OFS2).
  • Step 2 When the switch port joins the openflow instance, the openflow port number and status are notified to the controller through the OFPT_PORT_STATUS message.
  • controller 1 and controller 2 learn that port 1 of OFS1 has joined dpidl and dpid2, and port 2 of OFS2 has added dpid3 and dpid4.
  • Step 3 The controller 1 sends a PacketOut message (port 1 in FIG. 8) to all the openflow ports of the switch OFS1, and the message carries the LLDP protocol packet of the OpenFlow instance identification information, that is, the dpid1 corresponding to the OFS1 instance 1.
  • the identifier information is carried in the optional TIN of the LLDP packet, and the corresponding TIN type is 9 or other specified value.
  • the controller 2 sends a PacketOut message (port 1 in FIG. 8) to all the openflow ports of the switch OFS1, and the message carries the LLDP protocol packet of the OpenFlow instance identification information (dpid2 corresponding to the OFS1 instance 2).
  • the optional TIN of the LLDP packet is carried in, and the corresponding TIN type is 9 or other specified value.
  • the Pa C ket_Out message sent by the controller carries only the source switch instance identifier.
  • Pa C ket_Out packet carries the source switch and destination switch identified Examples instance ID, as shown in FIG.
  • Step 4 The local OpenFlow Agent module of the OFS1 receives the PacketOut message, parses the LLDP packet, and sends it to the egress port specified by the controller.
  • the LLDP packets are sent to the port 1 and the internal information of the LLDP packets is unchanged.
  • the instance IDs of different instances are different.
  • Step 5 The OFS2 receives the LLDP packet sent by the controller 1 (with the OF instance identifier being dpid1) and the LLDP packet sent by the controller 2 (with the OF instance identifier being dpid2).
  • the LLDP packet is sent to each controller, that is, to the controller 1 and the controller 2. If the LLDP packet carries the instance identifier on the destination switch OFS2, the OFS2 checks the consistency of the instance ID and sends a Packetjn message to the controller to which the corresponding instance is connected. Step 6, the controller 1 receives the Packet_In message, and determines the TCP/SSL connection and the datapath id (equal to dpidl) corresponding to the message. If the dpid carried in the LLDP message and the dpid corresponding to the connection are received, the processing continues.
  • the controller 1 continues to analyze the ingress port number and the internal LLDP information in the Packetln message, and the port 1 of the dpid1 of the OFS1 and the port 2 of the dpid2 of the OFS2 are physically connected. Step 7. Through the above steps, the controller will detect that there is a connection relationship in the direction from port 1 of OFS1 to port 2 of OFS2d.
  • the link discovery between multiple controller multi-instance devices is taken as an example for description.
  • Figure 10 shows an SDN network consisting of three controllers and three switches.
  • Controller 1 manages instance 1, connects to 3 Datapath_ids (DPIDll, DPID2K DPID31); controller 2 manages instance 2, connects to 2 datapathjd (DPID22, DPID32); controller 3 manages instance 3, connects to 2 datapathjd (DPID13, DPID23) 0 in this embodiment, between the network device link topology discovery procedure includes the following steps 1 to step 4.
  • Step 1 In each switch configuration instance, divide forwarding resources; each instance establishes a TCP/SSL connection with the corresponding controller.
  • Step 2 The controller sends an OFPT_FEATURES_REQUEST to obtain instance identification information of the connected switch.
  • Step 3 The switch port joins the OpenFlow instance, and the corresponding controller is notified by the OFPT_PORT_STATUS message.
  • the controller 1 learns that three datapaths are connected, which are DPID11, DPID21, and DPID31, respectively.
  • the port associated with DPID11 is port 1
  • the port associated with DPID21 is port 2 and port 3
  • the port associated with DPID31 is port 4.
  • Step 4 The controller discovers the connection relationship between the datapath ports by sending LLDP (encapsulated by the Packet_out message) to all ports associated with each datapath. Taking the processing flow of the controller 1 as an example, the specific steps include the following 1) -6).
  • the controller 1 sends a packet_out message (carrying LLDP information) to all ports associated with each datapath. As shown in FIG. 10, the controller 1 sends a packet_out message to port 1 of DPID11, port 2 of port DPID21, port 3, and port 4 of DPID31.
  • the TIN in the LLDP packet carries the connected DPID information (source DPID).
  • the LLDP in the packet_out message sent by the controller 1 to the switch 1 carries the DPID 11 information; the OFS1 receives the packetjn message, parses the LLDP packet, and sends it to the port 1.
  • OFS2 receives the LLDP packet from port 2, parses the LLDP packet, and finds that it carries the datapathjd information. The judgment needs to be handed over to the controller for processing, instead of being handed over to the traditional application module.
  • OFS2 is configured with three datapaths, which are respectively connected. With 3 controllers, OFS2 itself does not know which controller this LLDP should be sent to. Therefore, OFS2 will broadcast to the port (port 2) information and LLDP information through the packetjn message and send it to all connected controllers. The LLDP message itself remains unchanged.
  • the controller 1 receives the packetjn message, parses the LLDP packet and the ingress port number, and finds that the LLDP information is received from the TCP/SSL connection corresponding to the DPID21, and the source DPID carried by the LLDP TLV is the DPID1 connected to the controller. According to this, it is judged that there is a connection relationship from the port 1 of the DPID 11 to the port 2 of the DPID 21.
  • the controller 2 and the controller 3 also receive the packetjn message, but find that the source DPID carried by the LLDP is inconsistent with the DPID to which it is connected, and the packetjn message is discarded.
  • controller 1 In order to detect whether there is a connection relationship from port 2 of DPID21 to port 1 of DPID1, controller 1 needs to send LLDP packets to port 2 of DPID21 of OFS2. The processing flow is similar to the above steps.
  • the LLDP packet is sent periodically to detect the link connectivity. To improve the packet transmission efficiency, reduce the controller load, and then send LLDP packets.
  • the LLDP TIN needs to carry the destination DPID.
  • the controller 1 learns that the port 1 of the DPID1 and the port 2 of the DPID 21 have a connection relationship
  • the LLDP packet sent to the DPID1 will carry the source DPID1 and the destination DPID21;
  • the LLDP TLV is obtained and parsed, and the source DPID11 and the destination DPID21 are found. According to the source DPID1, the determination needs to be sent to the controller for processing.
  • Embodiment 4 This embodiment describes a link discovery by point-to-multipoint as an example. As shown in FIG. 11, on the switch OFS2, there are three datapaths, wherein DPID21 and PDPID22 are connected to the controller 1, and the DPID23 is connected to the controller 3. Specifically, the following steps 1 - 8 are included. In step 1, the controller 1 establishes a connection with the four datapaths to obtain the DPID. Step 2: The controller 1 sends a packet_out message (carrying LLDP information) to all ports associated with each datapath.
  • a packet_out message carrier LLDP information
  • the controller 1 sends a packet_out message to the port 1, the port 2 and the port 3 of the DPID 11, the port 2 and the port 3 of the DPID 22, and the port 4 of the DPID 31; the TIN carries the connected DPID information in the LLDP message (source) DPID).
  • Step 4 The OFS2 receives the LLDP packet from the port 2, parses the LLDP packet, and finds that the datapathjd information is carried, and the judgment needs to be handed over to the controller for processing, instead of being handed over to the traditional application module.
  • OFS2 is configured with three datapaths, of which DPID21 and PDPID22 are connected to controller 1, and DPID23 is connected to controller 3.
  • OFS2 itself does not know which controller this LLDP should be sent to. Therefore, OFS2 will broadcast to the port (port 2) information and LLDP information through the packetjn message and send it to all connected controllers. The LLDP message itself remains unchanged.
  • Step 5 The controller 1 receives the packetjn message, parses the LLDP packet and the ingress port number, and finds that the LLDP information is received from the TCP/SSL connection corresponding to the DPID21 and the DPID22, and the source DPID carried by the LLDP TLV is connected by the controller. According to this, the DPID 11 determines that there is a P2MP connection relationship from the port 1 of the DPID 11 to the port 2 of the DPID 21 and the DP ID 22 in this direction. The controller 3 also receives the packetjn message, but finds that the source DPID carried by the LLDP is inconsistent with the DPID connected to itself, and the packetjn message is discarded.
  • Step 6 In order to detect whether there is a connection relationship from the port 2 of the DPID 21 and the DPID 22 to the port 1 of the DPID 11, the controller 1 needs to send an LLDP packet to the port 2 of the DPID 21 of the OFS2; the processing flow is similar to the above steps.
  • Step 7 After the controller 1 learns the port connection relationship between the datapaths, the controller 1 periodically sends LLDP packets to detect the connectivity of the link. In order to improve the packet transmission efficiency and reduce the burden on the controller, the LLDP TIN needs to carry the destination DPID in addition to the source DPID.
  • the LLDP packet needs to carry two destination DPIDs, namely DPID21 and DPID22.
  • Step 8 When OFS2 receives the LLDP packet from port 2, it checks the source and destination DPIDs and sends them to the corresponding controller according to the DPID.
  • Embodiment 5 This embodiment describes a processing flow of an OpenFlow switch device side. 12 and FIG. 13 are block diagrams of the OpenFlow switch in the embodiment, FIG. 12 is a schematic diagram of module interaction of the source switch, and FIG. 13 is a schematic diagram of module interaction of the destination switch. In this embodiment:
  • transceiver module for receiving and transmitting openflow and legacy protocol messages
  • the OpenFlow Agent module is configured to communicate with the controller, establish a connection, report Datapath information, and configure a flow table;
  • the LLDP module is configured to process the traditional LLDP protocol;
  • the flow table configuration module configures the forwarding channel according to the flow table sent by the controller;
  • the forwarding module performs packet forwarding processing according to the configured flow table.
  • the switch performs the following steps 1 - 5 in the link discovery process.
  • Step 1 After the switch is powered on, establish a TCP/SSL connection with the controller; the openflow protocol packet communicates with the openflow agent module through the transceiver module, and establishes a connection.
  • Step 2 The controller sends an OFPT_FEATURES_REQUEST to obtain the datapathjd information of the switch.
  • Step 3 DPID information, as shown, the controller issued packet_ 0U t message to the source switch 11, LLDP package information, and carries the source switch DPID information (a) and destination switch (0, 1, or more ).
  • the openflow agent module sent to the source switch through the TCP/SSL connection; the openflow agent module parses the packet_out message and sends the LLDP packet to the specified egress port.
  • Step 4 The LLDP packet arrives at the destination switch, and is sent to the LLDP protocol module for processing by the transceiver module.
  • the LLDP protocol module parses the packet and finds that the packet carries the DPID TLV information, and then sends it to the OpenFlow Agent module for processing.
  • the example solves the problem that the Openflow service and the traditional service cannot be distinguished under multiple instances, and expands the application field of openflow.
  • modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.

Landscapes

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

Abstract

提供了一种软件定义网络中的链路发现方法、装置及系统。其中，该方法包括：控制器向源交换机发送第一链路发现报文，其中，第一链路发现报文中了携带与源交换机对应的实例标识信息；控制器接收目的交换机发送的第二链路发现报文；控制器判断接收到的第二链路发现报文与发送的第一链路发现报文中携带的实例标识信息是否相同，如果相同，则确定源交换机与目的交换机之间存在链路连接。通过该方法，可以区分openflow业务和传统应用以及多个openflow实例。

Description

软件定义网络中的链路发现方法、 装置及系统 技术领域 本发明涉及计算机网络及通信技术领域， 具体而言， 涉及一种软件定义网络
( Software-Defined Network, SDN) 中的链路发现方法、 装置及系统。 背景技术 目前， 由于路由器的体系结构中增加了很多复杂功能， 例如 OSPF、 BGP、 组播、 区分服务、 流量工程、 NAT、 防火墙以及 MPLS等， 从而使得路由器等交换设备越来 越臃肿且性能提升的空间越来越小。 针对该问题， 目前出现了软件定义网络这种新型网络创新架构。在该网络架构中， 使用 OpenFlow (开放流）协议将网络设备控制面与数据面分离开来， 从而实现了网络 流量的灵活控制， 为核心网络及应用的创新提供了良好的平台。 在相关技术中，普遍采用 LLDP (Link Layer Discovery Protocol,链路层发现协议） 来发现 OpenFlow网络中的物理拓扑。 如图 1所示， OpenFlow网络的链路发现是由控 制器发起的， 即控制器在 PaCket_Out消息中封装 LLDP报文， 发送给 OF交换机 1 ; 交换机 1的 OpenFlow agent协议收到 Packet_Out消息， 剥离 OpenFlow协议报头， 解 析出 LLDP报文格式， 并从端口 1发出； 当 OF交换机 2收到 LLDP报文， 根据配置 的流表匹配信息和动作， 上送 LLDP 报文给本地 OpenFLow agent协议处理， 本地 OpenFLow agent协议把 LLDP报文封装为 Packetjn消息， 并上送给控制器处理； 控 制器分析 packetjn消息内的 LLDP信息，判断出交换机 1的端口 1和交换机 2的端口 2 存在物理连接， 从而达到了链路发现的目的。 通过上述流程， 控制器可以发现其它 物理连接， 进而发现整个 OpenFlow网络的拓扑路径。 上述相关技术中， 主要存在以下问题： 问题 1， OpenFlow网络支持多实例部署，每个控制器发现的 openflow网络拓扑是 基于单实例的。 而 OpenFlow 交换机 （OpenFlow Switch, OFS) 设备之间支持多个 OpenFlow实例 （OpenFlow Instance, OFI), 但由于发送端发出的 LLDP报文都相同， 接收端无法区分 LLDP报文是属于哪个 OFI， 从而无法决定把 LLDP报文上送给哪个 控制器处理。 问题 2， 如果 OFS是混合设备， 即 OFS既支持 openflow应用， 也支持传统应用， 例如两个 OFS之间的连接端口由 OpenFlow和传统应用共享。 在这种情况下， 传统应 用和 openflow都会在交换机之间发送 LLDP报文， 由于发送端发出的 LLDP报文没有 携带区分 openflow和传统应用的标识信息， 因此， 接收端无法决定把 LLDP报文交给 传统应用处理， 还是上送给控制器处理。 问题 3， 如果 LLDP报文不区分 Openflow多实例和传统应用， 即交换设备收到的 LLDP报文，都上送给多实例和传统应用，则影响 LLDP报文的正常运行。现有的 LLDP 标准规范中， 源交换机发出的 LLDP报文中 chassis id TLV (类型长度值） 为设备标 识， 用于携带源交换机的设备信息， 比如 MAC地址等； port id TIN携带出端口信息。 目的交换机收到 LLDP报文后， 通过 packetjn转发给控制器， 控制器无法识别是否为 自身发出的 LLDP, 从而可能错误认为存在连接关系。 在相关技术中， 针对 SDN网络提出了两种扩展 LLDP的方案， 一是采用特殊的 EtherType，二是采用非标准的 LLDP目的地址。上述两种方案主要解决了单个 Openflow 实例和传统业务的 LLDP不能区分的问题， 但无法解决多实例下控制器无法识别收到 的链路发现报文是否是自身发送的链路发现报文，从而导致连接关系判断失误的问题。 发明内容 针对相关技术中无法解决多实例下控制器无法识别收到的链路发现报文是否是自 身发送的链路发现报文， 从而导致连接关系判断失误的问题， 本发明提供了一种软件 定义网络中的链路发现方法、 装置及系统， 以至少解决上述问题。 根据本发明的一个方面， 提供了一种软件定义网络中的链路发现方法。 根据本发明的软件定义网络中的链路发现方法包括： 控制器向源交换机发送第一 链路发现报文， 其中， 所述第一链路发现报文中了携带与所述源交换机对应的实例标 识信息； 所述控制器接收目的交换机发送的第二链路发现报文； 以及所述控制器判断 接收到的所述第二链路发现报文与发送的所述第一链路发现报文中携带的实例标识信 息是否相同， 如果相同， 则确定所述源交换机与所述目的交换机之间存在链路连接。 优选地， 在控制器向源交换机发送第一链路发现报文之前， 所述方法还包括： 所 述控制器与所述源交换机建立 TCP/SSL连接，获取与所述源交换机对应的实例标识信 息。 优选地， 如果所述控制器已学习到与所述目的交换机对应的实例标识信息， 则所 述第一链路发现报文中还携带有与所述目的交换机对应的实例标识信息。 优选地， 所述第一链路发现报文和所述第二链路发现报文为链路层发现协议 LLDP ί艮文。 优选地， 所述实例标识信息包括： 数据路径 DP标识。 优选地， 所述实例标识信息通过在 LLDP报文的可选类型长度值 TIN中携带。 根据本发明的另一个方面， 提供了一种软件定义网络中的链路发现装置。 根据本发明的一种软件定义网络中的链路发现装置位于控制器，包括： 发送模块， 设置为向源交换机发送第一链路发现报文， 其中， 所述第一链路发现报文中了携带与 所述源交换机对应的实例标识信息； 接收模块， 设置为接收目的交换机发送的第二链 路发现报文； 以及判断模块， 设置为判断接收到的所述第二链路发现报文与发送的所 述第一链路发现报文中携带的实例标识信息是否相同； 确定模块， 设置为在所述判断 模块判断两个实例标识信息相同的情况下， 确定所述源交换机与所述目的交换机之间 存在链路连接。 优选地， 还包括： 连接模块， 设置为与所述源交换机建立传输控制层协议 TCP/ 安全套接层 SSL 连接； 获取模块， 设置为通过与所述源交换机之间建立的 TCP/SSL 连接， 获取与所述源交换机对应的实例标识信息。 优选地， 所述第一链路发现报文中还携带有与所述目的交换机对应的实例标识信 息。 根据本发明的又一个方面， 提供了一种链路发现报文的处理方法。 根据本发明的链路发现报文的处理方法， 包括： 目的交换机接收到来自源交换机 的链路发现报文； 所述目的交换机判断接收到的所述链路发现报文中是否携带有与所 述源交换对应的第一实例标识信息， 如果有， 则向控制器发送链路发现报文。 优选地， 向控制器发送链路发现报文包括： 所述目的交换机判断接收到的所述链 路发现报文中是否携带有与所述目的交换机对应的第二实例标识信息， 如果有， 则向 管理所述第二实例标识信息对应的实例的控制器发送链路发现报文， 否则， 向与所述 目的交换机连接的所有控制器发送链路发现报文。 优选地， 在所述目的交换机判断接收到的所述链路发现报文没有携带有与所述目 的交换机对应的第二实例标识信息的情况下， 所述方法还包括： 所述目的交换机在向 所有控制器发送的所述链路发现报文中添加所述第二实例标识信息。 根据本发明的再一个方面， 提供了一种链路发现报文的处理装置。 根据本发明的发现报文的处理装置位于目的交换机， 所述装置包括： 接收模块， 设置为接收到来自源交换机的链路发现报文； 第一判断模块， 设置为判断接收到的所 述链路发现报文中是否携带有与所述源交换对应的第一实例标识信息；以及发送模块， 设置为在所述第一判断模块的判断结果为是的情况下， 向控制器发送链路发现报文。 优选地， 所述装置还包括： 第二判断模块， 设置为判断接收到的所述链路发现报 文中是否携带有与所述目的交换机对应的第二实例标识信息， 如果有， 则触发所述发 送模块将所述链路发现报文发送给管理所述第二实例标识信息对应的实例的控制器， 否则， 触发所述发送模块将所述链路发现报文发送给与所述目的交换机连接的所有控 制器。 优选地， 所述装置还包括： 处理模块， 设置为在所述第二判断模块判断接收到的 所述链路发现报文中没有携带有与所述目的交换机对应的第二实例标识信息时， 在所 述发送模块发送的所述链路发现报文中添加所述第二实例标识信息。 根据本发明的又一个方面， 提供了一种软件定义网络中的链路发现系统， 包括： 控制器， 包括上述软件定义网络中的链路发现装置； 源交换机， 设置为接收所述控制 器发送的链路发现报文， 并将所述链路发现报文发送给目的交换机；所述目的交换机， 包括上述的链路发现报文的处理装置。 通过本发明， 通过在链路发现报文中携带实例标识信息， 不仅能够区分 openflow 业务和传统应用， 还能区分多个 openflow实例， 从而使得控制器能够识别收到的链路 发现报文是否是自身发送的链路发现报文， 避免了连接关系的判断失误。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部分， 本发 明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在附图 中： 图 1是现有技术采用的链路发现的示意图; 图 2为根据本发明实施例的软件定义网络中的链路发现方法的流程图； 图 3为根据本发明实施例的软件定义网络中的链路发现装置的结构示意图； 图 4为根据本发明实施例的链路发现报文的处理方法的流程图； 图 5为根据本发明实施例的链路发现报文的处理装置的结构示意图； 图 6为根据本发明实施例的软件定义网络中的链路发现系统的结构示意图； 图 7为实施例一的链路发现示意图； 图 8为实施例二的链路发现示意图之一； 图 9为实施例二的链路发现示意图之二； 图 10为实施例三的链路发现示意图； 图 11为实施例四的链路发现示意图； 图 12为实施例五中源交换机的模块交互示意图； 以及 图 13为实施例五中目的交换机的模块交互示意图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在不冲突的 情况下， 本申请中的实施例及实施例中的特征可以相互组合。 根据本发明实施例， 提供了一种软件定义网络中的链路发现方法。 图 2为根据本发明实施例的软件定义网络中的链路发现方法的流程图， 如图 2所 示， 该方法主要包括以下步骤 S202-步骤 S206。 步骤 S202， 控制器向源交换机发送第一链路发现报文， 其中， 所述第一链路发现 报文中了携带与所述源交换机对应的实例标识信息。 在本发明实施例中， 在控制器向源交换机发送的链路发现报文中携带与源交换机 对应的实例标识信息，其中，控制器向源交换机发送的链路发现报文可以为 LLDP (链 路层发现协议） 报文， 在链路层发现协议中携带可以为 OpenFlow实例标识信息， 通 过该实例标识信息， 可以不仅可以区分 OpenFlow 和传统应用， 也可以区分多个 OpenFlow实例。 在具体实施过程中， 控制器可以将上述实例标识信息封装到链路发现报文中， 再 将链路发现报文封装到 Packet_0Ut消息中发送。 在本发明实施例的一个可选实施方案中， 控制器可以在与源交换机建立传输控制 协议（TCP) /安全套接层 （Secure Sockets Layer, SSL)连接后， 从源交换机处获取与 源交换机对应的实例标识信息 （即源交换机中控制器管理的实例的标识信息）。 在本发明实施例的一个可选实施方案中， 在发送上述第一链路发现报文之前， 如 果控制器已学习到与目的交换机对应的实例标识信息， 则控制器还可以在第一链路发 现报文中携带有与目的交换机对应的实例标识信息 （即目的交换机中控制器所管理的 实例对应的标识信息）。 在本发明实施例的一个可选实施方案中， 上述实例标识信息包括但不限于： 数据 路径 DP标识 （ datapath id )。 在本发明实施例的一个可选实施方案中， 上述实例标识信息可以通过在 LLDP报 文的可选 TIN中携带。例如，在本发明实施例中，可以对现有的 LLDP协议规范《 Station and Media Access Control Connectivity Discovery》 Table 8.1规定的 TIN类型进行扩展， 增加一种 TIN类型， 用于携带 OpenFlow交换机的 Datapath ID信息， 扩展后的 TIN 类型如表 1所示。 表 1.
TLV type TLV name Usage in LLDPDU
0 End OfLLDPDU Mandatory
1 Chassis ID Mandatory
2 Port ID Mandatory
3 Time To Live Mandatory
4 Port Description Optional
5 System Name Optional
6 System Description Optional
7 System Capabilities Optional
Management
8 Optional
Address
9或其它值 源 Datapath ID Optional
10或其它值 目的 Datapath ID Optional
Reserved for future
11-126
standardization
127 Organizationally Optional Specific TLVs
说明：源 DPID和
目的 DPID的类
型值可以采用
9-127的任意值，
只要不冲突即可。 步骤 S204， 控制器接收目的交换机发送的第二链路发现报文。 在具体实施过程中， 控制器发送的第一链路发现报文到达源交换机， 源交换机将 第一链路发现报文发送到控制器指定的出端口， 通过该出端口到达目的交换机。 目的 交换机解析出第一链路发现报文， 如果链路发现协议中没有携带上述实例标识信息， 则把第一链路发现报文上送给传统应用处理， 如果携带了上述实例标识信息， 则在第 一链路发现报文中添加目的交换机的入端口， 得到第二链路发现报文， 然后将第二链 路发现报文发送给控制器。 在本发明实施例的可选实施方案中， 目的交换机在向控制器发送第二链路发现报 文前， 可以先判断第一链路发现报文中是否携带有目的实例标识 （即与目的交换机对 应的实例标识信息），如果有，则判断该实例标识是否和本地实例标识一致，如果一致， 则向实例标识对应的 TCP/SSL连接上送第二链路发现报文； 否则， 向所有的控制器发 送第二链路发现报文。 可选地， 目的交换机可以将上述第二链路发现报文封装在 Packetjn消息中发送。 步骤 S206,控制器判断接收到的所述第二链路发现报文与发送的所述第一链路发 现报文中携带的实例标识信息是否相同， 如果相同， 则确定所述源交换机与所述目的 交换机之间存在链路连接。 通过本发明实施例提供的上述方法， 在链路发现报文中携带与源交换机对应的实 例标识信息， 从而可以区分 openflow业务和传统应用， 以及多个 openflow实例， 提高 了控制器发现的链路的准确性。 根据本发明实施例， 还提供了一种软件定义网络中的链路发现装置， 该装置可以 位于控制器中， 用于实现上述的软件定义网络中的链路发现方法。 图 3为根据本发明实施例的软件定义网络中的链路发现装置的结构示意图， 如图 3所示， 该装置主要包括： 发送模块 302， 设置为向源交换机发送第一链路发现报文， 其中， 所述第一链路发现报文中了携带与所述源交换机对应的实例标识信息； 接收模 块 304， 设置为接收目的交换机发送的第二链路发现报文； 判断模块 306， 设置为判断 接收到的所述第二链路发现报文与发送的所述第一链路发现报文中携带的实例标识信 息是否相同； 确定模块 308， 设置为在所述判断模块判断两个实例标识信息相同的情 况下， 确定所述源交换机与所述目的交换机之间存在链路连接。 应当理解， 图 3中所表示的各个模块的连接关系仅为示例， 本领域技术人员完全 可以采用其它的连接关系， 只要在这样的连接关系下各个模块也能够实现本发明的功 能即可。 在本说明书中， 各个模块的功能可以通过使用专用硬件、 或者能够与适当的软件 相结合来执行处理的硬件来实现。 这样的硬件或专用硬件可以包括专用集成电路 (ASIC)、 各种其它电路、 各种处理器等。 当由处理器实现时， 该功能可以由单个专 用处理器、 单个共享处理器、 或者多个独立的处理器（其中某些可能被共享）来提供。 另外， 处理器不应该被理解为专指能够执行软件的硬件， 而是可以隐含地包括、 而不 限于数字信号处理器 （DSP) 硬件、 用来存储软件的只读存储器 （ROM)、 随机存取 存储器 （RAM)、 以及非易失存储设备。 在本发明实施例的可选实施方案中， 该装置还可以包括： 连接模块， 用于与所述 源交换机建立 TCP/SSL连接；获取模块，用于通过与所述源交换机之间建立的 TCP/SSL 连接， 获取与所述源交换机对应的实例标识信息。 在本发明实施例的另一个可选实施方案中， 第一链路发现报文中还可以携带有与 所述目的交换机对应的实例标识信息。 在具体实施过程中， 根据本发明实施例的软件定义网络中的链路发现装置可以采 取与上述软件定义网络中的链路发现方法对应的可选实施方案， 具体不再赘述。 根据本发明实施例， 还提供了一种链路发现报文的处理方法， 该方法与上述软件 定义网络中的链路发现对应， 用于在目的交换机侧对链路发现报文进行处理。 图 4为根据本发明实施例的链路发现报文的处理方法的流程图， 如图 4所示， 该 方法主要包括以下步骤 S402-步骤 S404。 步骤 S402, 目的交换机接收到来自源交换机的链路发现报文。 源交换机在接收控制器发送的携带与源交换机对应的实例标识信息的链路发现报 文之后， 将该链路发现报文通过控制器指定的出端口发送到目的交换机。 步骤 S404， 目的交换机判断接收到的链路发现报文中是否携带有与所述源交换对 应的第一实例标识信息， 如果有， 则向控制器发送链路发现报文。 在实际应用中， 目的交换机在向控制器发送链路发现报文前， 将接收到的链路发 现报文交由自身的 OpenFlow代理处理， OpenFlow代理按照相关技术中的处理方式， 对接收到的链路发现报文进行处理， 例如， 在接收到的链路发现报文中添加入端口信 息， 然后向控制器发送处理后的链路发现报文。 在本发明实施例的一个可选实施方案中， 在向控制器发送链路发现报文前， 目的 交换机可以判断接收到的所述链路发现报文中是否携带有与所述目的交换机对应的第 二实例标识信息， 如果有， 则所述目的交换机向管理所述第二实例标识信息对应的实 例的控制器发送链路报文， 否则， 所述目的交换机向与所述目的交换机连接的所有控 制器发送链路报文。 可选的， 在目的交换机判断接收到的链路发现报文没有携带有与目的交换机对应 的第二实例标识信息的情况下， 目的交换机还可以在向所有控制器发送的链路发现报 文中添加第二实例标识信息。 从而使得控制器可以学习到与目的交换机对应的实例标 识信息，在下一次发送链路发现报文时，可以在链路发现报文中携带该实例标识信息， 避免目的交换机将链路发现报文广播给所有的控制器。 在本发明实施例中的链路发现报文的处理方法可以采取与上述软件定义网络中的 链路发现方法对应可选实施方案， 具体在此不再赘述。 根据本发明实施例， 还提供了一种链路发现报文的处理装置， 该装置可以位于目 的交换机， 用于实现上述的链路发现报文的处理方法。 图 5为根据本发明实施例的链路发现报文的处理装置的结构示意图，如图 5所示， 该装置可以包括： 接收模块 502， 设置为接收到来自源交换机的链路发现报文； 第一 判断模块 504， 设置为判断接收到的所述链路发现报文中是否携带有与所述源交换对 应的第一实例标识信息； 发送模块 506， 设置为将经所述处理模块处理后的所述链路 发现报文发送给控制器。 应当理解， 图 5中所表示的各个模块的连接关系仅为示例， 本领域技术人员完全 可以采用其它的连接关系， 只要在这样的连接关系下各个模块也能够实现本发明的功 能即可。 在本说明书中， 各个模块的功能可以通过使用专用硬件、 或者能够与适当的软件 相结合来执行处理的硬件来实现。 这样的硬件或专用硬件可以包括专用集成电路 (ASIC)、 各种其它电路、 各种处理器等。 当由处理器实现时， 该功能可以由单个专 用处理器、 单个共享处理器、 或者多个独立的处理器（其中某些可能被共享）来提供。 另外， 处理器不应该被理解为专指能够执行软件的硬件， 而是可以隐含地包括、 而不 限于数字信号处理器 （DSP) 硬件、 用来存储软件的只读存储器 （ROM)、 随机存取 存储器 （RAM)、 以及非易失存储设备。 在本发明实施例的一个可选实施方案中， 上述装置还可以包括： 第二判断模块， 设置为判断接收到的所述链路发现报文中是否携带有与所述目的交换机对应的第二实 例标识信息， 如果有， 则触发所述发送模块将所述链路发现报文发送给管理所述第二 实例标识信息对应的实例的控制器， 否则， 触发所述发送模块将所述链路发现报文发 送给与所述目的交换机连接的所有控制器。 可选地， 该装置还可以包括： 处理模块， 设置为在第二判断模块判断接收到的链 路发现报文中没有携带有与目的交换机对应的第二实例标识信息时， 在发送模块 506 发送的链路发现报文中添加第二实例标识信息。 从而使得控制器可以学习到与目的交 换机对应的实例标识信息， 在下一次发送链路发现报文时， 可以在链路发现报文中携 带该实例标识信息， 避免目的交换机将链路发现报文广播给所有的控制器。 在具体实施过程中， 处理模块可以由目的交换机自身的 openflow代理实现， 除了 上述功能以外， 处理模块还可以按照现有方式对链路发现报文进行处理， 例如， 处理 模块可以在第一判断模块的判断结果为是的情况下， 在接收到的链路发现报文中添加 所述链路发现报文的入端口信息， 作为发送模块 506发送的链路报文。 根据本发明实施例， 还提供了一种软件定义网络中的链路发现系统。 图 6为根据本发明实施例的软件定义网络中的链路发现系统的结构示意图， 如图 6所示， 该系统可以包括： 控制器 62， 可以包括上述软件定义网络中的链路发现装置； 源交换机 64， 设置为接收控制器 62发送的链路发现报文， 并将链路发现报文发送给 目的交换机 66; 目的交换机 66， 可以包括上述的链路发现报文的处理装置。 下面通过具体实施例对本发明实施例提供的技术方案进行说明。 在下面的实施例中，以 LLDP报文为例进行说明，但本发明实施例并不限于 LLDP 报文。 以下实施例中， 在发送端， 可以在控制器中进行 OpenFlow实例标识信息的封装。 其中， OpenFlow实例标识包括源交换机实例标识 （0个或 1个）和目的交换机实例标 识 （0个、 1个或多个）。 在第一次发送 LLDP报文时， 只携带源交换机实例标识； 后 面， 则根据学习到的目的交换机实例标识， 封装源交换机实例标识和目的交换机实例 标识。 在接收端， 链路发现协议中如果没有携带源实例标识信息， 则把协议报文上送给 传统应用处理； 否则， 如果携带了源实例标识信息， 则检查 LLDP报文中的目的实例 标识是否和本地实例标识一致， 如果一致， 则向实例标识对应的 TCP/SSL 连接上送 Packetjn消息； 否则， 向所有的控制器发送 Packet_In消息。 然后， 控制器解析协议报文， 如果协议报文中携带了源实例标识信息， 并且和本 控制器连接的 OpenFlow实例标识一致，则认为两个 OpenFlow实例之间的链路是相连 的； 否则， 则两实例间不存在链路连接。 在以下实施例中， 以实例标识信息为 datapathjd信息为例进行描述。 但并不限于 此， 对于本领域技术人员来说， 显然也可以采用其他信息， 只要该信息可以区分出 OpenFlow实例和传统应用， 以及多个 OpenFlow实例即可。 实施例一 本实施例以混合 OF设备间的链路发现为例进行说明。 如图 7所示， 图中包括 SDN控制器和两个 OpenFlow交换机， 其中 OFS为混合 OF设备， 即除了支持 OpenFlow应用， 也支持传统的 L2/L3应用。 设备启动后， OFS 和 OFC之间先建立 TCP/SSL连接； 当 Controller感知一个交换机加入后， 向所述交换 机及其它交换机周期发送链路层发现协议报文消息来感知交换机之间的物理连接状 态。 另外， 现有的传统 L2应用， 当启用 LLDP后， 将向所有物理端口周期发送 LLDP 报文， 来感知设备间的物理连接状态。 在本实施例中， OpenFlow的链路发现的具体流程可以包括以下步骤 1-步骤 7。 步骤 1 ， 控制器和 交换机建立 TCP/SSL 连接 ， 控制器发送
OFPT FEATURES REQUEST消息， 获得交换机实例的 datapathjd信息。 在图 7中， 控制器获悉连接到了两台 openflow换机， 分别对应 dpidl (OFS1 ) 和 dpid2(OFS2)。 步骤 2， 当交换机端口加入 openflow实例时， 通过 OFPT_PORT_STATUS消息告 知 openflow端口号及状态给控制器。在图 7中，控制器获悉 OFS1上端口 1加入了 dpidl， OFS2上端口 2加入了 dpid2。 步骤 3，控制器主动向交换机 OFS 1的所有 openflow端口发送 PacketOut消息（在 图 7中为端口 1 )，消息中携带了 OpenFlow实例标识信息（即 OFS1实例对应的 dpidl ) 的 LLDP协议报文， 实例标识信息在 LLDP报文的可选 TIN中携带， 对应的 TIN类 型为 9或其它规定值。 步骤 4， OFS1的本地 OpenFlow Agent模块收到 PacketOut消息， 解析出 LLDP 报文， 并发送到控制器指定的出端口。 在图 7中， 解析出的 LLDP报文发送到端口 1， LLDP报文内部信息不变。 同时，两个交换机本地都运行了 LLDP协议，通过发送 LLDP报文检测物理链路 的连接关系。 在图 7中， 交换机 1的端口 1即可以运行 openflow业务， 也可以运行传 统业务， 因此交换机 1的传统应用模块也将向端口 1发送 LLDP协议报文。 步骤 5， OFS2 收到传统应用发送的 LLDP 报文 （没有携带 OF 实例标识） 和 OpenFlow发送的 LLDP报文 （携带了 OF实例标识）， 将根据是否携带 OF实例标识， 决定 LLDP报文交给传统应用处理， 还是 OF应用处理 （现有技术是通过判断扩展的 ethertype或目的组播 mac地址）。 即， 如果没有携带 OF实例标识 （判断 TIN类型）， 则交给传统应用处理； 否则 交给 OpenFlow Agent处理， OpenFlow Agent再通过 Packetln消息， 封装携带了 OF实 例标识信息的 LLDP, 上送给控制器处理， 并在 Packet_In消息中携带 LLDP报文的入 端口号。 步骤 6， 控制器接收到 Packet_In 消息， 判断出此消息对应的 TCP/SSL 连接及 datapathjd (等于 dpid2);另夕卜，控制器分析 Packetln消息中的入端口号和内部的 LLDP 信息， 将感知到 OFS1的 dpidl的端口 1和 OFS2的 dpid2的端口 2存在物理连接。 步骤 7， 通过上述步骤， 控制器将检测到 从 OFS1的端口 1到 OFS2d的端口 2这 个方向上存在连接关系。 在本实施例中， 控制器可以在相反方向上 （即向 OFS2 交换机 dpid2的端口 2) 发送 Packet_Out报文， 来检测从 OFS2的端口 2到 OFS1的端口 1这个方向是否存在 连接关系， 处理过程相同， 具体不再赘述。 通过上述步骤，在传统应用及 OF应用混合组网情况下，传统应用和 OF应用能区 别 LLDP报文， 并发现各自的物理连接和拓扑信息。 实施例二 本实施例以多实例设备间的链路发现为例进行说明 图 8为本实施例中多 OFI场景的链路发现流程示意图。 在图 8中， 包括 2个交换 机 OFS1和 OFS2,每个交换机上配置了 2个实例，每个交换机配置了 2个 datapath_id， 分别为 OFSl(dpidl、 dpid2) OFS2 (dpid3 dpid4)。 本实施例中的链路发现具体可以包括以下步骤 1-步骤 7。 步骤 1， 控制器 1 和交换机 OFSl、 OFS2 建立 TCP/SSL连接， 控制器 1 发送 OFPT FEATURES REQUEST消息， 获得交换机实例的 datapathjd信息。 在图 8中， 控制器 1获悉连接到了两台 openflow换机， 分别对应 dpidl (OFS1 ) 和 dpid3(OFS2)。 控制器 2 和交换机 OFSl、 OFS2 建立 TCP/SSL 连接， 控制器 2 发送 OFPT FEATURES REQUEST消息， 获得交换机实例的 datapathjd信息。 在图 8中， 控制器 2获悉连接到了两台 openflow换机， 分别对应 dpid2 (OFS1 ) 和 dpid4(OFS2)。 步骤 2， 当交换机端口加入 openflow实例时， 通过 OFPT_PORT_STATUS消息告 知 openflow端口号及状态给控制器。 在图 8中， 控制器 1和控制器 2获悉 OFS1上端 口 1加入了 dpidl和 dpid2， OFS2上端口 2加入了 dpid3和 dpid4。 步骤 3，控制器 1向交换机 OFS1的所有 openflow端口发送 PacketOut消息（在图 8中为端口 1 )，消息中携带了 OpenFlow实例标识信息（即 OFS1实例 1对应的 dpidl ) 的 LLDP协议报文， 实例标识信息在 LLDP报文的可选 TIN中携带， 对应的 TIN类 型为 9或其它规定值。 控制器 2向交换机 OFS1的所有 openflow端口发送 PacketOut消息 （在图 8中为 端口 1 )， 消息中携带了 OpenFlow实例标识信息 （即 OFS1实例 2对应的 dpid2) 的 LLDP协议报文， 实例标识信息在 LLDP报文的可选 TIN中携带，对应的 TIN类型为 9或其它规定值。 在本实施例中， 第一次， 控制器发送的 PaCket_Out报文中只携带了源交换机实例 标识。 当控制器学习到目的交换机实例标识后， PaCket_Out报文中携带源交换机实例 标识和目的交换机实例标识， 如图 9所示。 步骤 4， OFS1的本地 OpenFlow Agent模块收到 PacketOut消息， 解析出 LLDP 报文， 并发送到控制器指定的出端口。 在图 8中， 解析出的 LLDP报文发送到端口 1， LLDP报文内部信息不变， 不同的实例对应的实例标识不同。 步骤 5， OFS2收到控制器 1发送的 LLDP报文 （携带 OF实例标识为 dpidl ) 和 控制器 2发送的 LLDP报文 （携带 OF实例标识为 dpid2)。 如果 LLDP报文没有携带 目的交换机 OFS2的实例标识， OFS2不知道 LLDP对应哪个控制器， 则 LLDP报文将 发送到每个控制器， 即发送到控制器 1和控制器 2。 如果 LLDP报文携带了目的交换机 OFS2上的实例标识， 则 OFS2将检查实例标 识的一致性， 并向对应的实例所连接的控制器发送 Packetjn消息。 步骤 6， 控制器 1接收到 Packet_In消息， 判断出此消息对应的 TCP/SSL连接及 datapath id (等于 dpidl )。 如果收到的 LLDP消息中携带的 dpid和连接对应的 dpid— 致， 则继续处理， 否则， 丢弃 LLDP报文。 另外， 如果 dpid—致， 控制器 1继续分析 Packetln消息中的入端口号和内部的 LLDP信息，将感知到 OFS1的 dpidl的端口 1和 OFS2的 dpid2的端口 2存在物理连接。 步骤 7， 通过上述步骤， 控制器将检测到 从 OFS1的端口 1到 OFS2d的端口 2这 个方向上存在连接关系。 实施例三 本实施例中以多控制器多实例设备间的链路发现为例进行描述。 图 10为包含 3个控制器和 3个交换机组成的 SDN网络。 其中控制器 1管理实例 1， 连接到 3个 Datapath_id(DPIDll、 DPID2K DPID31); 控制器 2管理实例 2， 连接 到 2个 datapathjd (DPID22, DPID32); 控制器 3管理实例 3， 连接到 2个 datapathjd (DPID13 , DPID23 )0 本实施例中， 网络设备间链路拓扑的发现流程主要包括以下步骤 1-步骤 4。 步骤 1， 在各个交换机配置实例， 划分转发资源； 各个实例分别和对应的控制器 建立 TCP/SSL连接。 步骤 2， 控制器发送 OFPT_FEATURES_REQUEST获得所连接交换机的实例标识 信息。 步骤 3， 交换机端口加入 OpenFlow实例，通过 OFPT_PORT_STATUS消息通告对 应的控制器。例如在图 10中，控制器 1获悉连接了 3个 datapath，分别是 DPID11,DPID21 禾口 DPID31。其中 DPID11关联的端口为端口 1，DPID21关联的端口为端口 2和端口 3， DPID31关联的端口为端口 4。 步骤 4， 控制器通过向每个 datapath关联的所有端口发送 LLDP (通过 Packet_out 消息封装）， 来发现 datapath端口之间的连接关系。 以控制器 1的处理流程为例， 具体 步骤包括以下 1 ) -6)。
1 )控制器 1向每个 datapath关联的所有端口发送 packet_out消息（携带 LLDP信 息）， 如图 10， 控制器 1向 DPID11的端口 1、 DPID21的端口 2和端口 3、 DPID31的 端口 4发送 packet_out消息； LLDP报文中 TIN携带了连接的 DPID信息（源 DPID )。
2 )在图 10中，控制器 1向交换机 1发送的 packet_out消息内的 LLDP携带了 DPID 11 信息； OFS1收到 packetjn消息， 解析出 LLDP报文， 并发送到端口 1。
3 ) OFS2从端口 2收到 LLDP报文， 解析 LLDP报文， 发现携带了 datapathjd信 息，判断需要交给控制器处理，而不是交给传统应用模块;但 OFS2配置了 3个 datapath, 分别连接了 3台控制器， OFS2自身不知道这个 LLDP该送到哪个控制器。因此， OFS2 将采用广播方式， 通过 packetjn消息携带入端口 （端口 2) 信息和 LLDP信息， 发送 给所连接的所有控制器。 LLDP消息自身保持不变。
4)控制器 1收到 packetjn消息， 解析出 LLDP报文和入端口号， 发现从 DPID21 对应的 TCP/SSL连接收到 LLDP信息， 并且 LLDP TLV携带的源 DPID是本控制器所 连接的 DPIDl l , 据此判断从 DPID 11的端口 1到 DPID21的端口 2这个方向上 存在 连接关系。 控制器 2和控制器 3也收到这个 packetjn消息， 但发现 LLDP携带的源 DPID和 自身所连接的 DPID不一致， 则丢弃此 packetjn消息。
5 ) 为了检测从 DPID21的端口 2到 DPIDl l的端口 1这个方向上是否存在连接关 系， 控制器 1需要向 OFS2的 DPID21的端口 2发送 LLDP报文。 处理流程和上述步 骤类似。
6)当控制器 1学习到各个 datapath之间端口连接关系后， 仍会周期发送 LLDP报 文来检测链路的连接性； 为了提高报文发送效率， 降低控制器负担，在后续发送 LLDP 报文时， LLDP TIN除了携带源 DPID夕卜， 还需要携带目的 DPID。 如图 10所示， 控制器 1学习到 DPIDl l的端口 1和 DPID21的端口 2存在连接关 系后， 后续发往 DPIDl l的 LLDP报文中将携带源 DPIDl l和目的 DPID21 ; OFS2的 端口 2收到并解析此 LLDP报文， 发现 LLDP TLV包含源 DPID11和目的 DPID21； 根 据源 DPIDl l ,判定需要发送到控制器处理，根据目的 DPID21，判定需要发送 DPID21 对应的控制器 1， 从而避免了广播发送， 降低了控制器的处理负担。 实施例四 本实施例以点到多点的链路发现为例进行描述。 如图 11所示， 在交换机 OFS2上， 存在 3个 datapath, 其中 DPID21禾 P DPID22 连接到控制器 1， DPID23连接到控制器 3。 具体包括以下步骤 1-步骤 8。 步骤 1， 控制器 1分别和 4个 datapath建立连接， 获取 DPID。 步骤 2， 控制器 1向每个 datapath关联的所有端口发送 packet_out消息（携带 LLDP 信息）。 如图 11， 控制器 1向 DPIDll的端口 1、 DPID21的端口 2和端口 3、 DPID22 的端口 2和端口 3、 DPID31的端口 4发送 packet_out消息； LLDP报文中 TIN携带了 连接的 DPID信息 （源 DPID)。 步骤 3， 在图 11中， 控制器 1向交换机 1发送的 paCket_out消息内的 LLDP携带 了 DPIDl l信息； OFS1收到 packetjn消息， 解析出 LLDP报文， 并发送到端口 1。 步骤 4， OFS2从端口 2收到 LLDP报文，解析 LLDP报文，发现携带了 datapathjd 信息， 判断需要交给控制器处理， 而不是交给传统应用模块。 但 OFS2 配置了 3 个 datapath, 其中 DPID21禾 P DPID22连接到控制器 1， DPID23连接到控制器 3。 OFS2 自身不知道这个 LLDP该送到哪个控制器。因此， OFS2将采用广播方式，通过 packetjn 消息携带入端口 （端口 2) 信息和 LLDP 信息， 发送给所连接的所有控制器。 LLDP 消息自身保持不变。 步骤 5， 控制器 1 收到 packetjn消息， 解析出 LLDP报文和入端口号， 发现从 DPID21和 DPID22对应的 TCP/SSL连接收到 LLDP信息， 并且 LLDP TLV携带的源 DPID是本控制器所连接的 DPID11，据此判断从 DPID11的端口 1到 DPID21、 DPID22 的端口 2这个方向上 存在 P2MP的连接关系。 控制器 3也收到这个 packetjn消息， 但发现 LLDP携带的源 DPID和自身所连接 的 DPID不一致， 则丢弃此 packetjn消息。 步骤 6， 为了检测从 DPID21、 DPID22的端口 2到 DPID11的端口 1这个方向上 是否存在连接关系， 控制器 1需要向 OFS2的 DPID21的端口 2发送 LLDP报文； 处 理流程和上述步骤类似。 步骤 7，当控制器 1学习到各个 datapath之间端口连接关系后，仍会周期发送 LLDP 报文来检测链路的连接性。 为了提高报文发送效率， 降低控制器负担， 在后续发送 LLDP报文时， LLDP TIN除了携带源 DPID夕卜， 还需要携带目的 DPID。 对 P2MP连 接 （如上述步骤 5学习到的 P2MP连接）； LLDP报文需要携带两个目的 DPID, 分别 是 DPID21禾口 DPID22。 步骤 8， 当 OFS2从端口 2收到 LLDP报文， 检查源和目的 DPID, 并根据 DPID 发送到相应的控制器。 实施例五 本实施例对 OpenFlow交换机装置侧的处理流程进行说明。 图 12和图 13为本实施例中的 OpenFlow交换机的模块装置图， 图 12为源交换机 的模块交互示意图， 图 13为目的交换机的模块交互示意图。 在本实施例中：
( 1 ) 收发包模块， 用于接收发送 openflow和传统协议报文；
(2) OpenFlow Agent模块， 用于和控制器通信， 建立连接， 上报 Datapath信息， 进行流表配置等；
( 3 ) LLDP模块， 用于处理传统的 LLDP协议； (4) 流表配置模块， 根据控制器下发的流表， 配置转发通道；
( 5 ) 转发模块， 根据配置好的流表进行报文的转发处理。 在本实施例中， 交换机在链路发现过程中主要执行以下步骤 1-步骤 5。 步骤 1， 交换机上电后， 和控制器建立 TCP/SSL连接； openflow协议报文经过 收发包模块， 和 openflow agent模块进行通信， 并建立连接。 步骤 2，控制器发送 OFPT_FEATURES_REQUEST获取交换机的 datapathjd信息。 步骤 3， 如图 11所示， 控制器下发 packet_0Ut消息到源交换机， 封装 LLDP信息， 并携带源交换机的 DPID信息（一个）和目的交换机的 DPID信息（0个、 1个或多个）。 通过 TCP/SSL连接发送给源交换机的 openflow agent模块； openflow agent模块 解析 packet_out消息， 并发送 LLDP报文到指定的出端口。 步骤 4， LLDP报文到达目的交换机， 经收发包模块交给 LLDP协议模块处理，
LLDP协议模块进行报文解析， 发现报文携带了 DPID TLV信息， 则交给 OpenFlow Agent模块处理。 步骤 5， openflow agent分析 LLDP报文中的目的 DPID信息，如果没有目的 DPID， 则向连接的所有控制器发送 packetji！消息， 并封装 LLDP; 否则， 则根据携带的目的 DPID, 发送到对应的 openflow实例及连接的控制器。 从以上的描述中， 可以看出， 通过上述实施例之一提供的技术方案， 在链路层发 现协议报文中携带 OpenFlow实例标识信息， 用于区分 openflow和传统应用， 并用于 区分多个 openflow实例； 解决了多实例下 Openflow业务和传统业务不能区分的问题， 并扩大了 openflow的应用领域。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所 组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现， 从而， 可以 将它们存储在存储装置中由计算装置来执行， 并且在某些情况下， 可以以不同于此处 的顺序执行所示出或描述的步骤， 或者将它们分别制作成各个集成电路模块， 或者将 它们中的多个模块或步骤制作成单个集成电路模块来实现。 这样， 本发明不限制于任 何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技 术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的 任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。 工业实用性 在本发明实施例中， 通过在链路发现报文中携带实例标识信息， 不仅能够区分 openflow业务和传统应用， 还能区分多个 openflow实例， 从而使得控制器能够识别收 到的链路发现报文是否是自身发送的链路发现报文， 避免了连接关系的判断失误。 具 有工业实用性。

Claims

权 利 要 求 书
1. 一种软件定义网络中的链路发现方法， 包括： 控制器向源交换机发送第一链路发现报文， 其中， 所述第一链路发现报文 中了携带与所述源交换机对应的实例标识信息；
所述控制器接收目的交换机发送的第二链路发现报文； 以及 所述控制器判断接收到的所述第二链路发现报文与发送的所述第一链路发 现报文中携带的实例标识信息是否相同， 如果相同， 则确定所述源交换机与所 述目的交换机之间存在链路连接。
2. 根据权利要求 1所述的方法， 其中， 在控制器向源交换机发送第一链路发现报 文之前， 所述方法还包括：
所述控制器与所述源交换机建立 TCP/SSL连接，获取与所述源交换机对应 的实例标识信息。
3. 根据权利要求 1所述的方法， 其中， 如果所述控制器已学习到与所述目的交换 机对应的实例标识信息， 则所述第一链路发现报文中还携带有与所述目的交换 机对应的实例标识信息。
4. 根据权利要求 1至 3中任一项所述的方法， 其中， 所述第一链路发现报文和所 述第二链路发现报文为链路层发现协议 LLDP报文。
5. 根据权利要求 4所述的方法， 其中， 所述实例标识信息包括： 数据路径 DP标 识。
6. 根据权利要求 4所述的方法， 其中， 所述实例标识信息通过在 LLDP报文的可 选类型长度值 TIN中携带。
7. 一种软件定义网络中的链路发现装置， 位于控制器， 包括：
发送模块， 设置为向源交换机发送第一链路发现报文， 其中， 所述第一链 路发现报文中了携带与所述源交换机对应的实例标识信息；
接收模块， 设置为接收目的交换机发送的第二链路发现报文； 以及 判断模块， 设置为判断接收到的所述第二链路发现报文与发送的所述第一 链路发现报文中携带的实例标识信息是否相同； 确定模块， 设置为在所述判断模块判断两个实例标识信息相同的情况下， 确定所述源交换机与所述目的交换机之间存在链路连接。
8. 根据权利要求 7所述的装置， 其中， 还包括： 连接模块， 设置为与所述源交换机建立传输控制层协议 TCP/安全套接层 SSL连接； 获取模块， 设置为通过与所述源交换机之间建立的 TCP/SSL连接， 获取与 所述源交换机对应的实例标识信息。
9. 根据权利要求 7或 8所述的装置， 其中， 所述第一链路发现报文中还携带有与 所述目的交换机对应的实例标识信息。
10. 一种链路发现报文的处理方法， 包括： 目的交换机接收到来自源交换机的链路发现报文；
所述目的交换机判断接收到的所述链路发现报文中是否携带有与所述源交 换对应的第一实例标识信息， 如果有， 则向控制器发送链路发现报文。
11. 根据权利要求 10所述的方法， 其中， 向控制器发送链路发现报文包括： 所述目的交换机判断接收到的所述链路发现报文中是否携带有与所述目的 交换机对应的第二实例标识信息， 如果有， 则向管理所述第二实例标识信息对 应的实例的控制器发送链路发现报文， 否则， 向与所述目的交换机连接的所有 控制器发送链路发现报文。
12. 根据权利要求 11所述的方法，其中，在所述目的交换机判断接收到的所述链路 发现报文没有携带有与所述目的交换机对应的第二实例标识信息的情况下， 所 述方法还包括： 所述目的交换机在向所有控制器发送的所述链路发现报文中添 加所述第二实例标识信息。
13. 一种链路发现报文的处理装置， 位于目的交换机， 所述装置包括： 接收模块， 设置为接收到来自源交换机的链路发现报文； 第一判断模块， 设置为判断接收到的所述链路发现报文中是否携带有与所 述源交换对应的第一实例标识信息； 以及
发送模块， 设置为在所述第一判断模块的判断结果为是的情况下， 向控制 器发送链路发现报文。
14. 根据权利要求 13所述的装置， 其中， 所述装置还包括： 第二判断模块， 设置为判断接收到的所述链路发现报文中是否携带有与所 述目的交换机对应的第二实例标识信息， 如果有， 则触发所述发送模块将所述 链路发现报文发送给管理所述第二实例标识信息对应的实例的控制器， 否则， 触发所述发送模块将所述链路发现报文发送给与所述目的交换机连接的所有控 制器。
15. 根据权利要求 14所述的装置， 其中， 所述装置还包括： 处理模块， 设置为在所 述第二判断模块判断接收到的所述链路发现报文中没有携带有与所述目的交换 机对应的第二实例标识信息时， 在所述发送模块发送的所述链路发现报文中添 加所述第二实例标识信息。
16. 一种软件定义网络中的链路发现系统， 包括：
控制器， 包括权利要求 7至 9中任一项所述装置； 源交换机， 设置为接收所述控制器发送的链路发现报文， 并将所述链路发 现报文发送给目的交换机；
所述目的交换机， 包括权利要求 13至 15中任一项所述的装置。
PCT/CN2014/079983 2013-12-24 2014-06-16 软件定义网络中的链路发现方法、装置及系统 WO2015096409A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310722936.0 2013-12-24
CN201310722936.0A CN104735001B (zh) 2013-12-24 2013-12-24 软件定义网络中的链路发现方法、装置及系统

Publications (1)

Publication Number Publication Date
WO2015096409A1 true WO2015096409A1 (zh) 2015-07-02

Family

ID=53458445

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/079983 WO2015096409A1 (zh) 2013-12-24 2014-06-16 软件定义网络中的链路发现方法、装置及系统

Country Status (2)

Country Link
CN (1) CN104735001B (zh)
WO (1) WO2015096409A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112152862A (zh) * 2020-10-16 2020-12-29 中国联合网络通信集团有限公司 一种混合网络的拓扑获取方法、sdn控制器及sdn交换机
CN113411254A (zh) * 2021-05-13 2021-09-17 新华三大数据技术有限公司 一种链路处理方法及装置
CN113595931A (zh) * 2021-07-08 2021-11-02 杭州海康威视数字技术股份有限公司 一种报文处理方法、装置、设备及存储介质

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105763463B (zh) * 2016-01-27 2020-01-03 新华三技术有限公司 一种链路探测报文的传输方法和装置
CN107104811B (zh) * 2016-02-22 2021-08-17 中兴通讯股份有限公司 一种网络功能实现方法及控制装置
CN106789387B (zh) * 2016-03-16 2020-10-13 新华三技术有限公司 一种用于sdn的链路检测方法及装置
WO2018049545A1 (zh) * 2016-09-13 2018-03-22 深圳前海达闼云端智能科技有限公司 Sdn中数据处理方法、装置、系统、电子设备和计算机程序产品
CN108243047B (zh) * 2016-12-27 2023-01-10 中兴通讯股份有限公司 一种业务切换方法、装置及业务切换系统
CN110235417B (zh) 2017-03-14 2021-02-05 华为技术有限公司 一种sdn及其报文转发的方法和装置
CN107707390A (zh) * 2017-09-21 2018-02-16 烽火通信科技股份有限公司 Otn网络集中式链路自动发现的系统及方法
CN108600097B (zh) * 2018-04-20 2020-09-22 闫晓峰 可多路径传输数据的通讯设备、数据通讯网络系统及数据通讯方法
CN111163003A (zh) * 2019-12-24 2020-05-15 中国电子科技集团公司第三十研究所 一种无线多控制域sdn网络的拓扑发现方法
CN111130887B (zh) * 2019-12-26 2022-05-13 国家计算机网络与信息安全管理中心 一种设备间拓扑关系智能通告实现方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047618A (zh) * 2006-03-29 2007-10-03 华为技术有限公司 获取网络路径信息的方法和系统
CN103001887A (zh) * 2012-11-22 2013-03-27 中兴通讯股份有限公司 一种链路保活方法、控制器及交换机

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130223226A1 (en) * 2012-02-29 2013-08-29 Dell Products, Lp System and Method for Providing a Split Data Plane in a Flow-Based Switching Device
CN102857416B (zh) * 2012-09-18 2016-09-28 中兴通讯股份有限公司 一种实现虚拟网络的方法、控制器和虚拟网络
CN103259728B (zh) * 2013-05-24 2016-03-30 华为技术有限公司 一种ofs带内通信方法及ofs

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047618A (zh) * 2006-03-29 2007-10-03 华为技术有限公司 获取网络路径信息的方法和系统
CN103001887A (zh) * 2012-11-22 2013-03-27 中兴通讯股份有限公司 一种链路保活方法、控制器及交换机

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Discovery in Software-Defined Networks", 6 August 2013 (2013-08-06), Retrieved from the Internet <URL:http://vlkan.com/blog/post/2013/08/06/sdn-discovery> *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112152862A (zh) * 2020-10-16 2020-12-29 中国联合网络通信集团有限公司 一种混合网络的拓扑获取方法、sdn控制器及sdn交换机
CN112152862B (zh) * 2020-10-16 2023-04-07 中国联合网络通信集团有限公司 一种混合网络的拓扑获取方法、sdn控制器及sdn交换机
CN113411254A (zh) * 2021-05-13 2021-09-17 新华三大数据技术有限公司 一种链路处理方法及装置
CN113411254B (zh) * 2021-05-13 2023-03-31 新华三大数据技术有限公司 一种链路处理方法及装置
CN113595931A (zh) * 2021-07-08 2021-11-02 杭州海康威视数字技术股份有限公司 一种报文处理方法、装置、设备及存储介质
CN113595931B (zh) * 2021-07-08 2024-01-16 杭州海康威视数字技术股份有限公司 一种报文处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN104735001B (zh) 2019-11-05
CN104735001A (zh) 2015-06-24

Similar Documents

Publication Publication Date Title
WO2015096409A1 (zh) 软件定义网络中的链路发现方法、装置及系统
CN105763359B (zh) 用于交织结构交换机集群的分布式双向转发检测协议(d-bfd)
CN113364610B (zh) 网络设备的管理方法、装置及系统
US8665886B2 (en) Redundant host connection in a routed network
US8446914B2 (en) Method and system for link aggregation across multiple switches
US9497107B1 (en) Seamless path monitoring and rapid fault isolation using bidirectional forwarding detection in a network environment
US20130003738A1 (en) Trill based router redundancy
CN112929274A (zh) 一种处理路由的方法、设备及系统
WO2016101646A1 (zh) 以太虚拟网络的接入方法及装置
EP3035592B1 (en) Enhanced protocol independent multicast source registration over a reliable transport
JP5519710B2 (ja) データリンク層のための最大送信単位（ｍｔｕ）サイズ検出メカニズムおよび方法
WO2017114153A1 (zh) 基于业务功能链sfc的通信方法和装置
WO2011110118A2 (zh) 检测故障的方法和系统
WO2013182059A1 (zh) 多协议标签交换流量工程隧道建立方法及设备
US20100020719A1 (en) Automatic maintenance of a distributed source tree (dst) network
WO2018214809A1 (zh) 消息发送方法及装置、存储介质
WO2013071801A1 (zh) 多协议标签交换环网的检测方法、装置及系统
WO2008028384A1 (fr) Procédé et système de mise en oeuvre de commande de transmission pour messages oam
EP4191966A1 (en) Method and device for processing data message, storage medium, and electronic device
WO2020173424A1 (zh) 报文处理的方法和网关设备
KR20220093155A (ko) 패킷 전달 방법, 제1 네트워크 디바이스 및 제1 디바이스 그룹
CN109873763B (zh) 一种通信方法及设备
CN106034078B (zh) 一种减少pim协议dr变化的方法及系统
WO2017119219A1 (ja) 通信方法
CN116915874A (zh) 一种数据传输的方法、装置、设备和存储介质

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: 14874478

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: 14874478

Country of ref document: EP

Kind code of ref document: A1