WO2014187204A1 - 一种ofs带内通信方法及ofs - Google Patents

一种ofs带内通信方法及ofs Download PDF

Info

Publication number
WO2014187204A1
WO2014187204A1 PCT/CN2014/075602 CN2014075602W WO2014187204A1 WO 2014187204 A1 WO2014187204 A1 WO 2014187204A1 CN 2014075602 W CN2014075602 W CN 2014075602W WO 2014187204 A1 WO2014187204 A1 WO 2014187204A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
ofs
lldp
mac
message
Prior art date
Application number
PCT/CN2014/075602
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 WO2014187204A1 publication Critical patent/WO2014187204A1/zh
Priority to US14/949,506 priority Critical patent/US9832111B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/10—Routing in connection-oriented networks, e.g. X.25 or ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/26—Route discovery packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • 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 network communication technologies, and in particular, to an 0FS in-band communication method and 0FS. Background technique
  • the control plane is separated from the forwarding plane and is a basic feature of SDN (Software Defined Network) / OpenFlow (OpenFlow).
  • the control plane formulates a routing policy based on the full network view, and the forwarding plane processes the data packet according to the received routing decision.
  • Establishing a TCP connection between the OFS (OpenFlow Switch) and the OFC (OpenFlow Controller) is a basic prerequisite for the OpenFlow network to work properly.
  • FIG. 1 is a networking diagram of an existing out-of-band connection mode.
  • the control plane and the forwarding plane are respectively composed of two different physical networks.
  • the control plane is composed of switches Switch, 0FS1, OFS2, OFS3, OFS4, OFS5, OFS6 and controller OF_Controller;
  • the data plane is composed of switches 0FS1, OFS2, OFS3, OFS4, OFS5 and OFS6.
  • the switch firstly opens the control plane based on protocols such as LLDP and STP in the working mode of the traditional switch, that is, the MAC table generated by the protocol such as STP is used to implement forwarding of various OpenFlow control messages.
  • protocols such as LLDP and STP in the working mode of the traditional switch, that is, the MAC table generated by the protocol such as STP is used to implement forwarding of various OpenFlow control messages.
  • Various Controller-to-S witch messages, Asynchronous messages, and Symmetric messages defined by the OpenFlow specification.
  • the OFC can send the initial flow entry to the OFS.
  • the OFS adds the flow entry to the corresponding flow table, and then the data packet can be processed according to the flow table.
  • the technical problem to be solved by the present invention is how to provide an OFS in-band communication method and OFS to reduce the networking cost.
  • the present invention provides an OFS in-band communication method, which is performed by an OFS, the OFS includes a controller list, and the controller list is used to save one or more controller list entries, the controller The list entry includes a MAC address of the local OpenFlow controller OFC, and a port number when the OFS corresponding to the MAC and IP of the local OFC receives the link layer discovery protocol LLDP packet sent by the OFC, Methods include:
  • the LLDP data packet includes a sender's MAC, an IP, and a role subfield for identifying a sender type;
  • the controller list entry is newly created or updated, and the newly updated or updated controller list entry includes the LLDP data packet.
  • the method further includes:
  • the method further includes the steps of: broadcasting the LLDP data packet whose sender type is 0FC, so that other 0FSs are also executable, and receiving the LLDP data packet,
  • the LLDP data packet includes a sender's MAC, an IP, and a role subfield for identifying a sender type, and when judged by the role subfield
  • the controller list entry is newly created or updated, and the newly created or updated controller list entry includes the local OFC carried in the LLDP data packet.
  • the role subfield is located in a tag length value TLV field in the LLDP packet.
  • the 0FS includes a hardware module and a software module
  • Receiving the LLDP data packet specifically: the hardware module of the OFS receives the LLDP data packet, and queries the flow table according to the received LLDP data packet to generate an LLDP type packet_in message, and Sending a packet_in message of the LLDP type to the software module;
  • the software module of the OFS receives the packet_in message sent by the hardware module, parses the packet_in message, and determines whether the packet_in message is a packet_in message of the LLDP type;
  • the software module of the OFS parses the LLDP data packet from the packet_in message of the LLDP type, and from the LLDP
  • the role subfield is parsed in the TLV field of the data packet;
  • the newly creating or updating the controller list entry includes:
  • the software module of the OFS parses the MAC address and IP of the sender from the TLV field of the LLDP data packet, and parses out from the packet_in message of the LLDP type that the OFS receives the LLDP data packet.
  • Port in_ port
  • the software module of the OFS queries the controller list to determine whether there is a controller list entry that matches the obtained MAC and IP. If not, a new controller list entry is created to record the obtained MAC and IP. , in_port, and set the predetermined aging time, and then use the packet_out message to the LLDP packet FLOOD; if it exists,
  • the software module of the 0FS determines whether the in-port in the controller list entry matching the parsed MAC and IP is the same as the parsed in-port, and if they are the same, the controller The aging time corresponding to the list entry is reset to a predetermined aging time, and then the LLDP packet FLOOD is used using a packet_out message, if different,
  • the software module of the OFS further determines whether the aging time corresponding to the controller list entry arrives. If yes, the in_port in the controller list entry is modified to the in_port obtained by parsing, and then the packet_out is used. The message will be the LLDP packet FLOOD, if not arrived,
  • the software module of the 0FS discards the LLDP data packet.
  • the 0FS includes a hardware module and a software module
  • the hardware module of the 0FS receives the first TCP handshake packet for establishing a TCP connection, parses the first TCP handshake packet to obtain a destination MAC address and a destination IP address, and queries the flow table according to the parsed destination MAC address and destination IP address. Generating a packet-in message of a TCP type, and sending the packet-in message of the TCP type to the software module;
  • the software module of the 0FS receives the packet_in message sent from the hardware module, parses the packet_in message, and determines whether the packet_in message is a packet-in message of the TCP type;
  • the software module of the 0FS parses the first TCP handshake packet from the packet-in message of the TCP type, and Parsing the source MAC, the source IP, the destination MAC, and the destination IP in the first TCP handshake packet;
  • the software module of the OFS queries the controller list according to the parsed destination MAC address and the destination IP address, and determines whether there is a controller list entry that matches the parsed destination MAC address and the destination IP address. If yes, the first flow table is generated. And the second flow entry, and the first flow entry and the second flow entry are sent to the hardware module of the 0FS, where the record source MAC address is parsed in the first flow entry.
  • the source MAC address, the source IP address is the parsed source IP address
  • the destination MAC address is the parsed destination MAC address
  • the destination IP address is the parsed destination IP address
  • the forwarding port is the controller list matching the parsed destination MAC address and destination IP address.
  • the source MAC address is the parsed destination MAC address
  • the source IP address is the parsed destination IP address
  • the destination MAC address is the parsed source MAC address
  • the destination IP address is the parsed source.
  • IP the forwarding port is an in-port field in the packet-in message of the TCP type
  • the hardware module of the OFS receives the first flow entry and the second flow entry, and adds the first primary entry and the second flow entry to the flow table.
  • the method further includes the following steps:
  • the software module of the 0FS generates a packet-out message, and sends the packet-out message to the hardware module of the 0FS, where the action action action field of the packet-out message points to the flow table;
  • the hardware module of the 0FS parses the packet-out message, obtains the first TCP handshake packet, parses the first TCP handshake packet to obtain a destination MAC address and a destination IP, according to the parsed destination MAC address and destination.
  • the IP querying the flow table, and finding a flow entry that matches the destination MAC address and the destination IP address, and forwarding the first TCP handshake packet according to the forwarding port in the flow entry.
  • the method further includes the following steps:
  • the 0FS software module sends the TCP type packet_in message through the 0FS management port.
  • the 0FS adds a first initial flow entry to the flow table, where a destination address of the first initial flow entry is a multicast address of an LLDP protocol,
  • the protocol type is the type code of the LLDP protocol, the forwarding port points to the 0FC, the packet length is the full packet length, and the priority is the lowest.
  • the 0FS adds a second initial flow entry to the flow table, where the destination address of the second initial flow entry is a local address, and the protocol type is TCP. Type code of the protocol, the forwarding port points to the management port of the 0FS, and the packet length is the total length of the packet. Degree, the priority is the lowest.
  • the OFS further includes a neighbor list, where the neighbor list includes one or more neighbor list entries, where the neighbor list entry includes MAC, IP, and a port number when the OFS corresponding to the MAC and IP of the other OFS receives the LLDP data packet sent by the other OFS;
  • the method further includes the following steps:
  • the software module of the OFS parses the sender MAC, IP from the TLV field of the LLDP packet, and parses out the port from which the OFS receives the LLDP packet from the packet_in message of the LLDP type In_ port;
  • the software module of the OFS queries the neighbor list to determine whether there is a neighbor list entry that matches the obtained MAC and IP. If not, a new neighbor list entry is created in the neighbor list to record the parsed result. MAC, IP, and in port, then use the packet_out message to send the LLDP packet FLOOD; if present,
  • the packet-out message is used to send the LLDP packet FLOOD, if different,
  • the in_port corresponding to the neighbor list entry is modified into the parsed in_port, and then the LLDP packet is discarded.
  • the 0FS sends the neighbor list to the 0FC, where the 0FC establishes a network topology of the entire network according to the neighbor list.
  • the 0FS sends the changed neighbor list to the eleventh possible implementation manner of the first aspect, where the packet sent to the 0FC includes the third TCP handshake.
  • the package also includes other 0FS packets sent to the 0FC.
  • an 0FS including:
  • controller list storage unit configured to save one or more controller list entries, where the controller list entry includes a MAC, IP of the local OpenFlow controller 0FC, and the local 0FC a port number when the OFS corresponding to the MAC, IP receives the link layer discovery protocol LLDP packet sent by the OFC;
  • a data packet receiving unit configured to receive the LLDP data packet, where the LLDP data packet includes a sender MAC, an IP, and a role subfield for identifying a sender type;
  • a packet processing unit configured to: when it is determined by the role subfield, that the sender type of the received LLDP packet is OFC, create or update the controller list entry, and create or update a controller list table.
  • the entry includes the MAC, IP of the local OFC carried in the LLDP data packet, and a port in_port that receives the LLDP data packet;
  • a handshake packet unit configured to acquire a first TCP handshake packet for establishing a TCP connection, and search for a corresponding controller list entry in the controller list according to the destination MAC and the destination IP carried in the TCP handshake packet If yes, the flow entry is updated according to the MAC, IP, and in port in the corresponding controller list entry in the controller list, so that the OFS can forward the packet sent to the OFC to the OFC through the flow table.
  • the 0FS further includes:
  • a packet broadcast unit configured to broadcast the LLDP data packet whose sender type is 0FC, so that other 0FSs can also receive the LLDP data packet, where the LLDP data packet includes a sender's MAC, IP, and is used to identify the sender.
  • a role subfield of the type and, when it is determined by the role subfield that the sender type of the received LLDP packet is 0FC, newly or updated the controller list entry, a newly created or updated controller list
  • the entry includes the MAC address of the local 0FC carried in the LLDP data packet, and the port in port that receives the LLDP data packet.
  • the role subfield is located in a tag length value TLV field in the LLDP packet.
  • the data packet receiving unit is configured to receive the LLDP data packet, and query the flow table according to the received LLDP data packet to generate an LLDP type packet. — in message, and sending the packet_in message of the LLDP type to the data channel;
  • the packet processing unit is specifically configured to obtain a packet_in message from the data channel, parse the packet_in message, and determine whether the packet_in message is of the LLDP type. Packet—in message,
  • the packet_in message is the packet_in message of the LLDP type
  • controller list Querying the controller list to determine whether there is a controller list entry that matches the obtained MAC and IP. If not, create a new controller list entry to record the resolved MAC, IP, in_port, and Set a predetermined aging time, and then use the packet_out message to send the LLDP packet FLOOD; if it exists,
  • the handshake packet unit includes: a first handshake module and a second handshake module;
  • the first handshake packet module is configured to receive a first TCP handshake packet for establishing a TCP connection, parse the first TCP handshake packet to obtain a destination MAC address and a destination IP address, and query according to the parsed destination MAC address and destination IP address.
  • the flow table generates a packet-in message of a TCP type, and sends the packet-in message of the TCP type to the data channel;
  • the second handshake packet module is configured to obtain a packet_in message from the data channel, parse the packet_in message, and determine whether the packet_in message is a packet-in message of the TCP type.
  • the packet_in message is a packet-in message of the TCP type
  • parsing the first TCP handshake packet from the packet-in message of the TCP type, and from the first TCP handshake
  • the source MAC, source IP, destination MAC, and destination IP are parsed in the packet, and
  • the controller list Querying the controller list according to the parsed destination MAC address and the destination IP address, and determining whether there is a controller list entry that matches the parsed destination MAC address and the destination IP address. If yes, generating the first flow entry and the second flow table. And sending the first flow entry and the second flow entry to the first handshake packet, where the source MAC address of the first flow entry is a parsed source MAC, and the source IP is a parsed source. IP, the destination MAC address is the parsed destination MAC address, the destination IP address is the parsed destination IP address, and the forwarding port is the in-port in the controller list entry that matches the parsed destination MAC address and destination IP address.
  • the source MAC address is the destination MAC address
  • the source IP address is the resolved destination IP address
  • the destination MAC address is the source MAC address
  • the destination IP address is the source IP address
  • the forwarding port is the TCP type packet.
  • In_port field in the in message
  • the first handshake packet module is further configured to receive the first flow entry and the second flow entry, and add the first flow entry and the second flow entry to the flow table.
  • the second handshake packet module is further configured to: when the controller list has a controller list entry that matches the parsed destination MAC address and destination IP address, And generating a packet-out message, sending the packet-out message to the first handshake packet module, where an action action action field of the packet-out message points to the flow table;
  • the first handshake packet module is further configured to parse the packet-out message, obtain the first TCP handshake packet, parse the first TCP handshake packet to obtain a destination MAC address and a destination IP, according to the parsing
  • the destination MAC address and the destination IP address query the flow table, find a flow entry that matches the destination MAC address and the destination IP address, and forward the first TCP handshake packet according to the forwarding port in the flow entry.
  • the second handshake packet module is further configured to: when the controller list does not have an entry matching the parsed destination MAC address and destination IP address, The management port of the 0FS sends the packet_in message of the TCP type.
  • the 0FS further includes:
  • a first flow entry unit configured to add a first initial flow entry to the flow table, where the first initial
  • the destination address of the flow entry is the multicast address of the LLDP protocol.
  • the protocol type is the type code of the LLDP protocol.
  • the forwarding port points to the OFC.
  • the packet length is the total packet length and the priority is the lowest.
  • the OFS further includes:
  • a second flow entry unit configured to add a second initial flow entry to the flow table, where a destination address of the second initial flow entry is a local address, a protocol type is a TCP protocol type code, and a forwarding port points
  • the management port of the OFS the packet length is the total packet length, and the priority is the lowest.
  • the OFS further includes:
  • a neighbor list storage unit configured to include one or more neighbor list entries, where the neighbor list entry includes a MAC, an IP of another OFS, and the OFS corresponding to the MAC and IP of the other OFS receives the other OFS The port number when sending LLDP packets;
  • the data packet processing unit is further configured to: when determining, by using the role subfield, that the sender type of the received LLDP data packet is OFS, parsing the sender MAC from the TLV field of the LLDP data packet, IP, and parsing, from the packet_in message of the LLDP type, the port in_port that the OFS receives the LLDP packet, and,
  • the packet-out message is used to send the LLDP packet FLOOD, if different,
  • the in_port corresponding to the neighbor list entry is modified into the parsed in_port, and then the LLDP packet is discarded.
  • the 0FS further includes:
  • a neighbor list sending unit configured to send the neighbor list to the 0FC, where the 0FC establishes a network topology of the entire network according to the neighbor list, and
  • the packet sent to the OFC includes the third TCP handshake packet, and the data packet sent by the other OFS to the OFC.
  • the method includes: receiving an LLDP data packet, where the LLDP data packet includes a sender's MAC, an IP, and a role subfield for identifying a sender type;
  • the role subfield determines that the sender type of the received LLDP data packet is OFC
  • the controller list entry is newly created or updated, and the newly created or updated controller list entry includes the LLDP data packet.
  • the 0FS can forward the packet destined for the 0FC to the 0FC through the flow table.
  • the control plane signaling and the forwarding plane data are carried in the same OpenFlow network, and only one network management system needs to be maintained, thereby realizing network communication and reducing the networking cost.
  • Figure 1 is a network diagram of a prior art out-of-band connection mode
  • FIG. 2a is a flowchart of an 0FS in-band communication method according to Embodiment 1 of the present invention.
  • Figure 2b is a detailed flow chart of the step 220 of the 0FS in-band communication method according to Embodiment 1 of the present invention.
  • step 230 of the 0FS in-band communication method according to Embodiment 1 of the present invention is a detailed flow chart of step 230 of the 0FS in-band communication method according to Embodiment 1 of the present invention.
  • 2d is an in-band connection mode group for implementing the 0FS in-band communication method according to Embodiment 1 of the present invention
  • FIG. 3 is a schematic structural diagram of an internal module of an OFS according to Embodiment 3 of the present invention.
  • FIG. 4 is a schematic structural diagram of an internal module of a handshake packet unit according to Embodiment 3 of the present invention
  • FIG. 5 is a schematic structural diagram of an internal module of an OFS according to Embodiment 4 of the present invention.
  • FIG. 6 is a schematic diagram showing the hardware structure of the OFS according to the present invention.
  • the present invention aims to implement an OFS in-band communication method by using the existing OpenFlow (v1.2) specification and LLDP (Link Layer Discovery Protocol) protocol, in which each OFS is The content of the forwarded data packet (which is control information or data information) is not distinguished.
  • the control information of each OFS is forwarded in the network as the data information of other OFS. Only when the destination address of a certain data packet points to itself, the OFS The packet is parsed to obtain control information therein. Therefore, the above method is based on a physical network, and only one network management system needs to be maintained, that is, in-band communication can be realized, and the implementation cost is effectively reduced.
  • Embodiment 1 the OFS in-band communication method and OFS of the present invention will be described in detail with reference to specific embodiments.
  • Embodiment 1 the OFS in-band communication method and OFS of the present invention will be described in detail with reference to specific embodiments.
  • FIG. 2a is a flowchart of an OFS in-band communication method according to Embodiment 1 of the present invention. As shown in FIG. 2a, the method is performed by an OFS, and the method includes the following steps:
  • the LLDP data packet includes a sender's MAC, an IP, and a role subfield for identifying a sender type.
  • the LLDP data packet may be sent by the OFC or may be sent by another OFS.
  • the LLDP data packet includes a role subfield for identifying the sender type.
  • the role subfield is located in a tag length value TLV field in the LLDP data packet.
  • Table 3 is an example of a field of an LLDP packet including: an Eth_dst field, an Eth_src field, an Eth_type field, and a tag length value TLV (BER code type, ASN1) Standard, full name Tag, Length, Value) field; the TLV field includes: MAC (Media Access Control, hardware address) subfield, IP (Internet Protocol, protocol interconnected by network) subfield, role subfield, port sub Field.
  • the first row in Table 3 indicates the LLDP packet sent by the OFC.
  • the role subfield corresponds to the OFC, and the port subfield corresponds to the listening port of the OFC.
  • the second row in Table 3 indicates the LLDP packet sent by the OFS. Its role subfield corresponds to OFS, and its port subfield corresponds to the physical port number of the OFS.
  • the OFS includes a hardware module and a software module, and the hardware module (based on some dedicated hardware customization devices, such as an FPGA, an ASIC, etc.) is used to perform flow table matching after the OFS receives the packet, that is, the hardware module matches the flow after receiving the packet.
  • the table if it can match, is forwarded by the instruction in the match. If it does not match, the packet is sent to the software module (based on the CPU).
  • the receiving the LLDP data packet is specifically: the hardware module of the OFS receives the LLDP data packet, and queries the flow table according to the received LLDP data packet, and after the matching is unsuccessful, generates a packet_in message. , and send the packet_in message to the software module.
  • the controller list entry is newly created or updated, and the newly created or updated controller list entry includes the LLDP.
  • the OFS includes a controller list, where the controller list is used to save one or more controller list entries, where the controller list entry includes a MAC, IP, and a local open flow controller OFC.
  • the OFS corresponding to the MAC and IP of the local OFC receives the OFC The port number at which the transmitted link layer discovers the protocol LLDP packet.
  • the OFS creates or updates the controller list entry according to the received LLDP data packet, and then updates the flow entry according to the controller list entry to establish a connection between the OFS and the OFC.
  • FIG. 2b is a detailed flowchart of the step 220 of the OFS in-band communication method according to Embodiment 1 of the present invention, where the step 220 specifically includes:
  • the software module of the OFS refers to the packet_in message sent by the hardware module (the packet-in message is generated when the hardware module checks the flow table is unsuccessful), parses the packet_in message, and determines whether the packet_in message is an LLDP type packet. — in message.
  • the software module of the OFS parses the LLDP data packet from the packet_in message of the LLDP type, and parses the role from the TLV field of the LLDP data packet. Field.
  • the software module of the OFS parses the sender's MAC and IP from the TLV field of the LLDP packet, and from the LLDP type packet— The in message parses the port in_port that the OFS receives the LLDP packet.
  • the software module of the OFS queries the controller list to determine whether there is a controller list entry that matches the obtained MAC and IP. If not, a new controller list entry is created to record the obtained MAC, IP, and in. — port, and set the predetermined aging time, then use the packet_out message to forward the LLDP packet FLOOD (FOOD is forwarded from all available ports except the ingress port); if it exists, go to step 225.
  • the software module of the OFS determines whether the in-port in the controller list entry matching the parsed MAC and IP is the same as the in-port obtained by the parsing, and if they are the same, the controller list entry corresponds to The aging time is reset to a predetermined aging time, and then the LLDP packet FLOOD is used using the packet_out message. If different, step 226 is performed.
  • the software module of the OFS further determines whether the aging time corresponding to the controller list entry arrives. If yes, modify the in_port in the controller list entry to the parsed in_port, and then use the packet_out The message will LLDP packet FLOOD, if not reached, the OFS software module discards the LLDP packet.
  • the method also includes:
  • the OFS completes the TCP handshake communication with the OFC based on the flow table, and establishes a TCP connection with the OFC.
  • the packet sent to the OFC includes both the third TCP handshake packet and other packets sent by the OFS to the OFC.
  • the step 230 specifically includes:
  • the hardware module of the OFS receives the first TCP handshake packet used to establish a TCP connection, parses the first TCP handshake packet to obtain the destination MAC address and the destination IP address, and generates a TCP type according to the parsed destination MAC address and destination IP query flow table. Packet-in message, and send a packet-in message of TCP type to the software module;
  • the software module of the OFS receives the packet_in message in the sending hardware module, parses the packet_in message, and determines whether the packet_in message is a TCP-type packet_in message;
  • the OFS software module parses the first TCP handshake packet from the TCP type packet_in message, and parses from the first TCP handshake packet.
  • the software module of the OFS queries the controller list according to the parsed destination MAC address and the destination IP address, and determines whether there is a controller list entry that matches the parsed destination MAC address and the destination IP address. If yes, perform steps 235 and 237. Execute 239 when it does not exist.
  • the source MAC address of the first flow entry is the parsed source MAC
  • source IP For the source IP address to be parsed, the destination MAC address is the parsed destination MAC address, the destination IP address is the parsed destination IP address, and the forwarding port is the in-port in the controller list entry that matches the parsed destination MAC address and destination IP address.
  • the source MAC address is the destination MAC address
  • the source IP address is the resolved destination IP address
  • the destination MAC address is the source MAC address
  • the destination IP address is the source IP address.
  • the port is the in-port field in the packet-in message of TCP type.
  • the hardware module of the OFS receives the first flow entry and the second flow entry, and adds the first flow entry and the second flow entry to the flow table.
  • the method further includes the steps of:
  • the software module of 0FS generates a packet-out message, and sends a packet-out message to the hardware module of the 0 FS, and the action action field of the packet-out message points to the flow table.
  • the hardware module of 0FS parses the packet-out message, obtains the first TCP handshake packet, parses the first TCP handshake packet to obtain the destination MAC address and the destination IP address, and finds the flow table according to the parsed destination MAC address and destination IP address. A flow entry matching the destination MAC address and the destination IP address, and forwarding the first TCP handshake packet according to the forwarding port in the flow entry.
  • the method further includes the following steps:
  • the 0FS software module sends a TCP-type packet_in message through the 0FS management port.
  • FIG. 2d is a network diagram of an in-band connection mode for implementing the 0FS in-band communication method according to an embodiment of the present invention.
  • the content of the data packet forwarded by each 0FS is control information. Or data information) No distinction is made.
  • Each 0FS control information is forwarded in the network as other 0FS data information. Only when the destination address of a certain packet points to itself, the 0FS parses the data packet to obtain the control information therein. Therefore, the above method is based on a physical network, and only one network management system needs to be maintained, so that in-band communication can be realized, and the implementation cost is effectively reduced.
  • 0FS can realize self-discovery of 0FS to 0FC by parsing LLDP packets from 0FC, which reduces the configuration time of the switch.
  • the second embodiment is described based on the embodiment 1.
  • the method may further include: before step 210:
  • the 0FS adds a first initial flow entry to the flow table, where the destination address of the first initial flow entry is a multicast address of the LLDP protocol, and the protocol type is a type code of the LLDP protocol, and the forwarding is performed.
  • the port points to OFC, the packet length is the full packet length, and the priority is the lowest.
  • the OFS adds a second initial flow entry to the flow table, where the destination address of the second initial flow entry is a local address, the protocol type is a type code of the TCP protocol, and the forwarding port points to the management port of the OFS.
  • the packet length is the full packet length and the priority is the lowest.
  • Table 1 is an example of the first initial flow entry, where 01:80:c2:00:00:0e represents a multicast address of the LLDP protocol, which is a MAC address; 0x88CC represents a type coding of the LLDP protocol; Controller indicates the forwarding port to the OFC; OFPR_NO—BUFFER indicates that the packet length is the full packet length
  • Table 2 below is an example of a second initial flow entry, where the first Self represents a local MAC address; 0x0800 represents a TCP protocol type encoding; the second Self represents a local IP address; LOCAL represents a forwarding port pointing to The management port of the 0FS; OFPR_NO—BUFFER indicates that the packet length is the full packet length.
  • the hardware module of the OFS receives the LLDP data packet, and queries the flow table according to the received LLDP data packet to generate an LLDP type packet_in message, and The packet_in message of the LLDP type is sent to the software module, and the software module of the OFS is triggered to perform subsequent processing on the packet_in message of the LLDP type.
  • the hardware module of the OFS receives the first TCP handshake packet for establishing a TCP connection, and parses the first TCP handshake packet to obtain a destination MAC address and a destination IP, according to the parsing
  • the destination MAC address and the destination IP address query the flow table, generate a packet type-in message of the TCP type, and send the packet-in message of the TCP type to the software module, thereby triggering the software module of the OFS to the TCP type
  • the packet_in message is processed later.
  • the method when it is determined by the role sub-field that the sender type of the received LLDP data packet is OFC, the method further includes:
  • the LLDP data packet Broadcasting the LLDP data packet of the OFC type to the OFC, such that the other OFS can also perform, the receiving the LLDP data packet, where the LLDP data packet includes the sender's MAC, IP, and a role for identifying the sender type a subfield, and, when it is determined by the role subfield that the sender type of the received LLDP packet is OFC, newly or updated the controller list entry, and the newly created or updated controller list entry includes The MAC address of the local OFC carried in the LLDP data packet, and the step of receiving the port in port of the LLDP data packet.
  • the OFS further includes a neighbor list, where the neighbor list includes one or more neighbor list entries, where the neighbor list entry includes MAC, IP, and MAC and IP of the other OFS.
  • the method further includes the steps of:
  • the software module of the OFS parses the sender MAC and IP from the TLV field of the LLDP data packet, and The LLDP type packet_in message parses out the port in_ port that the OFS receives the LLDP data packet;
  • the software module of the OFS queries the neighbor list to determine whether there is a neighbor list entry that matches the obtained MAC and IP. If not, create a new neighbor in the neighbor list. List table entry to record the parsed MAC, IP, and in-port, and then use the packet_out message to the LLDP packet FLOOD; if present,
  • the packet-out message is used to send the LLDP packet FLOOD, if different,
  • the in_port corresponding to the neighbor list entry is modified into the parsed in_port, and then the LLDP packet is discarded.
  • the method may further include:
  • the OFS sends the neighbor list to the OFC, so that the OFC establishes a network topology of the entire network according to the neighbor list;
  • the 0FS When the neighbor list is changed, the 0FS sends the changed neighbor list to the end, that is, after the TCP connection between the 0FS and the 0FC is established, each 0FS actively sends the neighbor list it has mastered to the 0FC. After the OFC is aggregated, the network topology of the entire network can be obtained. In addition, when the neighbor list changes, the 0FS sends the changed neighbor list to the 0FC, and the OFC updates the network topology of the entire network according to the changed neighbor list.
  • the discovery of the network topology is completed by using 0FS instead of 0FC, which greatly reduces the time for network topology discovery.
  • the OFS 300 includes: a controller list storage unit 310, a data packet receiving unit 320, a data packet processing unit 330, and a handshake packet. Unit 340.
  • the controller list storage unit 310 is configured to save one or more controller list entries, where the controller list entry includes a MAC, an IP of the local OpenFlow controller 0FC, and a MAC and IP with the local 0FC.
  • the corresponding 0FS receives the port number of the link layer discovery protocol LLDP packet sent by the 0FC.
  • the data packet receiving unit 320 is configured to receive the LLDP data packet, where the LLDP data packet includes a sender's MAC, an IP, and a role subfield for identifying a sender type.
  • the role subfield is located in a label length value TLV field in the LLDP data packet.
  • the data packet receiving unit 320 is configured to receive the LLDP data packet, query the flow table according to the received LLDP data packet, generate an LLDP type packet_in message, and send the LLDP type packet— The in message is sent to the data channel.
  • the data packet processing unit 330 is configured to: when determining, by using the role subfield, that the sent sender type of the LLDP data packet is OFC, newly or update the controller list entry, new or updated control
  • the device list entry includes the MAC, IP of the local OFC carried in the LLDP data packet, and a port in port that receives the LLDP data packet.
  • the packet processing unit 330 is configured to obtain a packet_in message from the data channel, parse the packet_in message, and determine whether the packet_in message is a packet_in message of the LLDP type.
  • the packet_in message is a packet_in message of the LLDP type
  • controller list Querying the controller list to determine whether there is a controller list entry that matches the obtained MAC and IP. If not, create a new controller list entry to record the resolved MAC, IP, in_port, and Set a predetermined aging time, and then use the packet_out message to send the LLDP packet FLOOD; if it exists,
  • the handshake packet unit 340 is configured to acquire a first TCP handshake packet for establishing a TCP connection, and search for a corresponding controller in the controller list according to the destination MAC and the destination IP carried in the TCP handshake packet. a list entry, if yes, updating the flow entry according to the MAC, IP, and in-port in the corresponding controller list entry in the controller list, so that the OFS can send the packet to the OFC through the flow table. Forward to OFC.
  • the handshake packet unit 340 includes: a first handshake packet module 341 and a second handshake packet module 342.
  • the first handshake packet module 341 is configured to receive a first TCP handshake packet for establishing a TCP connection, and parse the first TCP handshake packet to obtain a destination MAC address and a destination IP, according to the resolved destination MAC address and destination IP address.
  • the flow table is queried, a packet-in message of a TCP type is generated, and the packet-in message of the TCP type is sent to the data channel.
  • the second handshake packet module 342 is configured to obtain a packet_in message from the data channel, parse the packet_in message, and determine whether the packet_in message is a packet-in message of the TCP type.
  • the packet_in message is a packet-in message of the TCP type
  • parsing the first TCP handshake packet from the packet-in message of the TCP type, and from the first TCP handshake The source MAC, source IP, destination MAC, and destination IP are parsed in the packet, and
  • the controller list Querying the controller list according to the parsed destination MAC address and the destination IP address, and determining whether there is a controller list entry that matches the parsed destination MAC address and the destination IP address. If yes, generating the first flow entry and the second flow table. And sending the first flow entry and the second flow entry to the first handshake packet, where the source MAC address of the first flow entry is a parsed source MAC, and the source IP is a parsed source. IP, the destination MAC address is the parsed destination MAC address, the destination IP address is the parsed destination IP address, and the forwarding port is the in-port in the controller list entry that matches the parsed destination MAC address and destination IP address.
  • the source MAC address is the destination MAC address
  • the source IP address is the resolved destination IP address
  • the destination MAC address is the source MAC address
  • the destination IP address is the source IP address
  • the forwarding port is the TCP type packet.
  • the first handshake packet module 341 is further configured to receive the first flow entry and the second flow entry. And adding the first flow entry and the second flow entry to the flow table.
  • the second handshake packet module 342 is further configured to: when the controller list has a controller list entry that matches the parsed destination MAC address and the destination IP address, generate a packet-out message, where the packet-out is sent The message is sent to the first handshake packet module, and the action action action field of the packet-out message points to the flow table.
  • the first handshake packet module 341 is further configured to parse the packet-out message, obtain the first TCP handshake packet, and parse the first TCP handshake packet to obtain a destination MAC address and a destination IP, according to the parsing
  • the destination MAC address and the destination IP address query the flow table, find a flow entry that matches the destination MAC address and the destination IP address, and forward the first TCP handshake packet according to the forwarding port in the flow entry.
  • the second handshake packet module 342 is further configured to: when the controller list does not have an entry matching the parsed destination MAC address and the destination IP address, send the TCP type packet by using the 0FS management port. — in message.
  • the 0FS 500 includes the following: a controller list storage unit 510, a data packet receiving unit 520, and a data packet processing unit.
  • the 530 and the handshake packet unit 540 further include: a packet broadcast unit 550, a first flow entry unit 560, a second flow entry unit 570, a neighbor list storage unit 580, and a neighbor list transmission unit 590.
  • the data packet broadcast unit 550 is configured to broadcast the LLDP data packet with a sender type of 0FC, so that other OFDM packets can also receive the LLDP data packet, where the LLDP data packet includes a sender's MAC, IP, and Identifying a role subfield of the sender type, and, when determining, by the role subfield, that the received sender type of the LLDP packet is 0FC, newly creating or updating the controller list entry, newly created or updated
  • the controller list entry includes the MAC, IP of the local 0FC carried in the LLDP data packet, and a port in port that receives the LLDP data packet.
  • the first flow entry unit 560 is configured to add a first initial flow entry to the flow table, where the destination address of the first initial flow entry is a multicast address of the LLDP protocol, and the protocol type is LLDP.
  • the second flow entry unit 570 is configured to add a second initial flow entry to the flow table, where a destination address of the second initial flow entry is a local address, and a protocol type is a type coding of a TCP protocol.
  • the forwarding port points to the management port of the OFS, and the data packet length is the total packet length, and the priority is the lowest.
  • the neighbor list storage unit 580 is configured to include one or more neighbor list entries, where the neighbor list entry includes a MAC, an IP of the other OFS, and the OFS receiving station corresponding to the MAC and IP of the other OFS.
  • the port number when the LLDP packets sent by other OFSs are described.
  • the data packet processing unit 530 is further configured to: when determining, by using the role subfield, that the sent sender type of the LLDP data packet is OFS, parsing the sender MAC address from the TLV field of the LLDP data packet And IP, and parsing, from the packet_in message of the LLDP type, the port in_port that the OFS receives the LLDP packet, and,
  • the packet-out message is used to send the LLDP packet FLOOD, if different,
  • the in_port corresponding to the neighbor list entry is modified into the parsed in_port, and then the LLDP packet is discarded.
  • the neighbor list sending unit 590 is configured to send the neighbor list to the 0FC, so that the 0FC establishes a network topology of the entire network according to the neighbor list, and
  • FIG. 6 illustrates an embodiment of an OFDM implemented based on a computer system.
  • the 0FS in this embodiment may include: a processor 601, Memory 602 and communication interface 603, wherein:
  • the communication interface 603 is configured to communicate with the OFC or other OFS. Specifically, the communication interface 603 is configured to receive an LLDP data packet and a first TCP handshake packet; the memory 602 is configured to store program instructions, a controller list, a flow table, and the like; and the processor 601 is configured to: after receiving the LLDP data packet, Calling the program instructions stored in the memory 602, performing the following operations: when it is determined by the role subfield that the sender type of the received LLDP data packet is OFC, newly or update the controller list entry, new or The updated controller list entry includes a MAC, an IP of the local OFC carried in the LLDP data packet, and a port in a port that receives the LLDP data packet; and receiving the first one for establishing a TCP connection.
  • the program instruction stored in the memory 602 is invoked, and the following operations are performed: searching for the corresponding controller list entry in the controller list according to the destination MAC and the destination IP carried in the TCP handshake packet. If yes, update the flow entry according to the MAC, IP, and in-port in the corresponding controller list entry in the controller list. That can be sent to the 0FS 0FC 0FC of packets to flow through the table.
  • the processor 601 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or the like.
  • the OFS in this embodiment may include a bus 604.
  • the processor 601, the memory 602, and the communication interface 603 can be connected and communicated via the bus 604.
  • the memory 602 may include: a random access memory (RAM), a read-only memory (ROM), a disk and the like having a storage function;
  • the processor 601 can also be used to perform the steps described in the second embodiment of the method, and the embodiments of the present invention are not described in detail herein.
  • the method includes: receiving an LLDP data packet, where the LLDP data packet includes a sender's MAC, an IP, and a role subfield for identifying a sender type;
  • the role subfield determines that the sender type of the received LLDP data packet is OFC
  • the controller list entry is newly created or updated, and the newly created or updated controller list entry includes the LLDP data packet.
  • the control plane signaling and the forwarding plane data are carried in the same OpenFlow network, and only one network management system needs to be maintained, thereby realizing network communication and reducing the networking cost.
  • aspects of the present invention, or possible implementations of various aspects can be embodied as a system, method, or computer program product.
  • aspects of the invention, or possible implementations of various aspects may be in the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, etc.), or a combination of software and hardware aspects, They are collectively referred to herein as "circuits," “modules,” or “systems.”
  • aspects of the invention, or possible implementations of various aspects may take the form of a computer program product, which is a computer readable program code stored in a computer readable medium.
  • the computer readable medium can be a computer readable signal medium or a computer readable storage medium.
  • the computer readable storage medium includes, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination of the foregoing, such as random access memory (RAM), read only memory (ROM), Erase programmable read-only memory (EPROM or flash memory), optical fiber, portable read-only memory (CD-ROM).
  • the processor in the computer reads the computer readable program code stored in the computer readable medium, such that the processor can perform the functional actions specified in each step or combination of steps in the flowchart; A device that functions as specified in each block, or combination of blocks.
  • the computer readable program code can be executed entirely on the user's computer, partly on the user's computer, as a separate software package, partly on the user's computer and partly on the remote computer, or entirely on the remote computer or server. .
  • the functions noted in the various steps of the flowcharts or in the blocks of the block diagrams may not occur in the order noted in the drawings.
  • two steps, or two blocks shown in succession may be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
  • the spirit and scope of the invention Thus, it is intended that the present invention cover the modifications and the modifications of the invention

Landscapes

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

Abstract

本发明公开了OFS带内通信方法及OFS，涉及通信领域。该方法包括：接收LLDP数据包；当通过所述角色子字段判断接收到的LLDP数据包的发送方类型为OFC时，新建或更新控制器列表表项；获取用于建立TCP连接的第一次TCP握手包，根据TCP握手包中携带的目的MAC以及目的IP查找所述控制器列表中是否有对应的控制器列表表项，如果有，则根据控制器列表中对应的控制器列表表项中的MAC、IP以及in_port更新流表项，使得OFS能够通过流表将发往OFC的包转发到OFC。所述方法及OFS，仅需维护一个网管系统，降低了组网成本。

Description

一种 OFS带内通信方法及 OFS 本申请要求于 2013 年 5 月 24 日提交中国专利局、 申请号为 201310198601.3, 发明名称为 "一种 OFS带内通信方法及 OFS " 的中国专利 申请的优先权， 上述专利申请的全部内容通过引用结合在本申请中。 技术领域
本发明涉及网络通信技术领域，特别涉及一种 0FS带内通信方法及 0FS。 背景技术
控制面与转发面相分离， 是 SDN ( Software Defined Network, 软件定义 网络） /OpenFlow (开放流） 的一个基本特征。 控制面基于全网视图制定路由 策略， 转发面根据收到的路由决策处理数据包。 OFS (OpenFlow Switch, 开放 流交换机)与 OFC (OpenFlow Controller, 开源控制器)之间建立 TCP连接是 OpenFlow网络能够正常工作的一个基本前提。
目前， OFS与 OFC之间一般釆用带外连接模式。 图 1是一种现有的带外 连接模式组网图， 控制面与转发面分别由两个不同的物理网组成。 其中， 控 制面由交换机 Switch, 0FS1、 OFS2、 OFS3、 OFS4、 OFS5、 OFS6及控制器 OF_Controller组成； 数据面则有交换机 0FS1、 OFS2、 OFS3、 OFS4、 OFS5 及 OFS6组成。
在图 1所示网络中， Switch首先在传统交换机的工作模式下，基于 LLDP 及 STP等协议打通控制面， 也即通过 STP等协议生成的 MAC表实现各种 OpenFlow 控消息的转发， 控制消息指 OpenFlow 规范定义的各种 Controller-to-S witch消息、 Asynchronous消息及 Symmetric消息。 控制面打通 后， OFC便可以向 OFS下发初始的流表项， OFS接收到流表项后， 将其添加 到相应的流表中， 进而便可以根据流表处理数据包。
该方案的缺点主要在于， 需要维护两个单独的物理网络和两个网络管理 系统（一个用于管理控制面的网络，另一个用于管理转发面的流交换的网络）， 成本比较高。
发明内容
(一）要解决的技术问题
本发明要解决的技术问题是：如何提供一种 OFS带内通信方法及 OFS，， 以降低组网成本。
(二）技术方案
第一方面， 本发明提供一种 OFS带内通信方法， 其由 OFS执行， 所述 OFS包括控制器列表，所述控制器列表用于保存一个或多个控制器列表表项， 所述控制器列表表项包括本地开放流控制器 OFC的 MAC、 IP以及与所述本 地 OFC的 MAC、 IP对应的所述 OFS接收所述 OFC发送的链路层发现协议 LLDP数据包时的端口号， 所述方法包括：
接收所述 LLDP数据包， 所述 LLDP数据包包含发送方的 MAC、 IP以及 用于标识发送方类型的角色子字段；
当通过所述角色子字段判断接收到的所述 LLDP数据包的发送方类型为 OFC时， 新建或更新所述控制器列表表项， 新建或更新的控制器列表表项包 括所述 LLDP数据包中携带的所述本地 OFC的 MAC、IP以及收到所述 LLDP 数据包的端口 in— port;
所述方法还包括：
获取用于建立 TCP连接的第一次 TCP握手包， 根据所述 TCP握手包中 携带的目的 MAC以及目的 IP查找所述控制器列表中是否有对应的控制器列 表表项，如果有，则根据所述控制器列表中对应的控制器列表表项中的 MAC、 IP以及 in— port更新流表项， 使得所述 0FS能够通过流表将发往 0FC的包 转发到 0FC。
在第一方面的第一种可能的实现方式中， 所述方法还包括步骤： 广播发送方类型为 0FC的所述 LLDP数据包， 使得其他 0FS也能够执 行， 所述接收所述 LLDP数据包， 所述 LLDP数据包包含发送方的 MAC、 IP 以及用于标识发送方类型的角色子字段， 和， 当通过所述角色子字段判断接 收到的所述 LLDP数据包的发送方类型为 OFC时，新建或更新所述控制器列 表表项， 新建或更新的控制器列表表项包括所述 LLDP数据包中携带的所述 本地 OFC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port的步骤。
在第一方面的第二种可能的实现方式中，所述角色子字段位于所述 LLDP 数据包中的标签长度值 TLV字段。
在第一方面的第三种可能的实现方式中， 所述 0FS包括硬件模块以及软 件模块；
所述接收所述 LLDP数据包， 具体为： 所述 OFS 的硬件模块接收所述 LLDP数据包，根据接收到的所述 LLDP数据包查询所述流表产生 LLDP类型 的 packet— in消息， 并将所述 LLDP类型的 packet— in消息发送到所述软件模 块；
所述角色子字段的获得过程如下：
所述 OFS的软件模块接收所述硬件模块发送的 packet— in消息， 解析所 述 packet— in 消息， 判断所述 packet— in 消息是否是所述 LLDP 类型的 packet— in消息；
当判断所述 packet— in消息是所述 LLDP类型的 packet— in消息时， 所述 OFS的软件模块从所述 LLDP类型的 packet— in消息中解析出所述 LLDP数 据包， 并从所述 LLDP数据包的 TLV字段中解析出所述角色子字段；
所述新建或更新所述控制器列表表项， 具体包括：
所述 OFS的软件模块从所述 LLDP数据包的 TLV字段中解析出发送方的 MAC, IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收到所 述 LLDP数据包的端口 in— port;
所述 OFS的软件模块查询所述控制器列表， 判断是否存在与解析得到的 MAC, IP相匹配的控制器列表表项， 如果不存在， 新建控制器列表表项以记 录解析得到的 MAC、 IP、 in— port,并设置预定的老化时间，然后使用 packet— out 消息将所述 LLDP数据包 FLOOD; 如果存在，
所述 0FS的软件模块判断与解析得到的 MAC、 IP相匹配的控制器列表 表项中的 in— port是否与解析得到的 in— port相同， 如果相同， 则将该控制器 列表表项对应的老化时间重置为预定的老化时间， 然后使用 packet— out消息 将所述 LLDP数据包 FLOOD, 如果不同，
所述 OFS的软件模块进一步判断该控制器列表表项对应的老化时间是否 到达，如果到达，将该控制器列表表项中的 in— port修改为解析得到的 in— port, 然后使用 packet— out消息将所述 LLDP数据包 FLOOD, 如果未到达，
所述 0FS的软件模块丟弃所述 LLDP数据包。
在第一方面的第四种可能的实现方式中， 所述 0FS包括硬件模块以及软 件模块；
获取用于建立 TCP连接的第一次 TCP握手包， 根据所述 TCP握手包中 携带的目的 MAC以及目的 IP查找所述控制器列表中是否有对应的控制器列 表表项，如果有，则根据所述控制器列表中对应的控制器列表表项中的 MAC、 IP以及 in— port更新流表项， 使得所述 0FS能够通过流表将发往 0FC的包 转发到 0FC， 具体包括：
所述 0FS的硬件模块接收用于建立 TCP连接的第一次 TCP握手包， 解 析所述第一次 TCP握手包得到目的 MAC和目的 IP，根据解析到的目的 MAC 和目的 IP查询所述流表， 产生 TCP类型的 packet— in消息， 并将所述 TCP 类型的 packet— in消息发送到所述软件模块；
所述 0FS的软件模块接收从所述硬件模块发送的 packet— in消息， 解析 所述 packet— in 消息， 判断所述 packet— in 消息是否是所述 TCP 类型的 packet— in消息；
当判断所述 packet— in消息是所述 TCP类型的 packet— in消息时， 所述 0FS的软件模块从所述 TCP类型的 packet— in消息中解析出所述第一次 TCP 握手包， 并从所述第一次 TCP握手包中解析出源 MAC、 源 IP、 目的 MAC和 目的 IP;
所述 OFS的软件模块根据解析出的目的 MAC和目的 IP查询所述控制器 列表， 判断是否存在与解析出的目的 MAC和目的 IP相匹配的控制器列表表 项， 如果存在， 生成第一流表项和第二流表项， 并将所述第一流表项和第二 流表项发送给所述 0FS的硬件模块， 所述第一流表项中记录源 MAC为解析 出的源 MAC， 源 IP为解析出的源 IP， 目的 MAC为解析出的目的 MAC， 目 的 IP为解析出的目的 IP，转发端口为与解析出的目的 MAC和目的 IP相匹配 的控制器列表表项中的 in— port, 所述第二表项中记录源 MAC为解析出的目 的 MAC， 源 IP为解析出的目的 IP， 目的 MAC为解析出的源 MAC， 目的 IP 为解析出的源 IP， 转发端口为所述 TCP类型的 packet— in消息中的 in— port 字段；
所述 OFS的硬件模块， 接收所述第一流表项和第二流表项， 并将所述第 一流表项和第二流表项添加至所述流表。
在第一方面的第五种可能的实现方式中， 当所述控制器列表存在与解析 出的目的 MAC和目的 IP相匹配的控制器列表表项时， 还包括步骤：
所述 0FS的软件模块产生 packet-out消息，将所述 packet-out消息发送 给所述 0FS的硬件模块，所述 packet-out消息的执行动作 action字段指向所 述流表；
所述 0FS的硬件模块解析所述 packet-out消息，得到其中的所述第一次 TCP握手包， 解析所述第一次 TCP握手包得到目的 MAC和目的 IP， 根据解 析到的目的 MAC和目的 IP查询所述流表，找到与解析到的目的 MAC和目的 I P相匹配的流表项，根据该流表项中的转发端口转发所述第一次 TCP握手包。
在第一方面的第六种可能的实现方式中， 当所述控制器列表不存在与解 析出的目的 MAC和目的 IP相匹配的表项时， 还包括步骤：
所述 0FS的软件模块通过所述 0FS的管理端口发送所述 TCP类型的 packet— in消息。
在第一方面的第七种可能的实现方式中， 所述 0FS向所述流表中添加第 一初始流表项， 所述第一初始流表项的目的地址为 LLDP协议的组播地址， 协议类型为 LLDP协议的类型编码， 转发端口指向 0FC， 数据包长度为全包 长度， 优先级为最低。
在第一方面的第八种可能的实现方式中， 所述 0FS向所述流表中添加第 二初始流表项，所述第二初始流表项的目的地址为本地地址，协议类型为 TCP 协议的类型编码， 转发端口指向所述 0FS的管理端口， 数据包长度为全包长 度， 优先级为最低。
在第一方面的第九种可能的实现方式中， 所述 OFS还包括邻居列表， 所 述邻居列表包括一个或多个邻居列表表项， 所述邻居列表表项包括其他 OFS 的 MAC、 IP以及与所述其他 OFS的 MAC、 IP对应的所述 OFS接收所述其 他 OFS发送的 LLDP数据包时的端口号；
当通过所述角色子字段判断接收到的所述 LLDP数据包的发送方类型为 OFS时， 所述方法还包括步骤：
所述 OFS的软件模块从所述 LLDP数据包的 TLV字段中解析出发送方 MAC, IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收到所 述 LLDP数据包的端口 in— port;
所述 OFS 的软件模块查询所述邻居列表， 判断是否存在与解析得到的 MAC, IP相匹配的邻居列表表项， 如果不存在， 在所述邻居列表中新建邻居 列表表项以记录解析得到的 MAC、 IP和 in— port, 然后使用 packet— out消息 将所述 LLDP数据包 FLOOD; 如果存在，
则判断与解析得到的 MAC、 IP相匹配的邻居列表表项对应的 in— port是 否与解析得到的 in— port相同， 如果相同， 使用 packet— out消息将所述 LLDP 数据包 FLOOD, 如果不同，
将该邻居列表表项对应的 in— port修改为解析得到的 in— port，然后丟弃所 述 LLDP数据包。
在第一方面的第十种可能的实现方式中， 所述 0FS将所述邻居列表发送 至 0FC， 以供所述 0FC根据邻居列表建立全网的网络拓朴；
当所述邻居列表改变时， 所述 0FS 将改变后的邻居列表发送给所述 在第一方面的第十一种可能的实现方式中， 所述发往 0FC的包既包括第 三次 TCP握手包， 也包括其他 0FS发往所述 0FC的数据包。
第二方面， 提供一种 0FS， 包括：
控制器列表存储单元， 用于保存一个或多个控制器列表表项， 所述控制 器列表表项包括本地开放流控制器 0FC的 MAC、 IP以及与所述本地 0FC的 MAC, IP对应的所述 OFS接收所述 OFC发送的链路层发现协议 LLDP数据 包时的端口号；
数据包接收单元， 用于接收所述 LLDP数据包， 所述 LLDP数据包包含 发送方的 MAC、 IP以及用于标识发送方类型的角色子字段；
数据包处理单元， 用于当通过所述角色子字段判断接收到的所述 LLDP 数据包的发送方类型为 OFC时， 新建或更新所述控制器列表表项， 新建或更 新的控制器列表表项包括所述 LLDP数据包中携带的所述本地 OFC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port;
握手包单元， 用于获取用于建立 TCP连接的第一次 TCP握手包， 根据 所述 TCP握手包中携带的目的 MAC以及目的 IP查找所述控制器列表中是否 有对应的控制器列表表项， 如果有， 则根据所述控制器列表中对应的控制器 列表表项中的 MAC、 IP以及 in— port更新流表项，使得所述 OFS能够通过流 表将发往 OFC的包转发到 OFC。
在第二方面的第一种可能的实现方式中， 所述 0FS还包括：
数据包广播单元， 用于广播发送方类型为 0FC的所述 LLDP数据包， 使 得其他 0FS也能够接收所述 LLDP数据包， 所述 LLDP数据包包含发送方的 MAC, IP以及用于标识发送方类型的角色子字段， 和， 当通过所述角色子字 段判断接收到的所述 LLDP数据包的发送方类型为 0FC时，新建或更新所述 控制器列表表项， 新建或更新的控制器列表表项包括所述 LLDP数据包中携 带的所述本地 0FC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port。
在第二方面的第二种可能的实现方式中，所述角色子字段位于所述 LLDP 数据包中的标签长度值 TLV字段。
在第二方面的第三种可能的实现方式中， 所述数据包接收单元， 具体用 于接收所述 LLDP数据包， 根据接收到的所述 LLDP数据包查询所述流表产 生 LLDP类型的 packet— in消息， 并将所述 LLDP类型的 packet— in消息发送 到数据通道；
所述数据包处理单元， 具体用于从所述数据通道中获取 packet— in消息， 解析所述 packet— in消息， 判断所述 packet— in消息是否是所述 LLDP类型的 packet— in消息，
当所述 packet— in消息的是所述 LLDP类型的 packet— in消息时， 从所述 LLDP类型的 packet— in消息中解析出所述 LLDP数据包， 并从所述 LLDP数 据包的 TLV字段中解析出所述角色子字段， 以及，
从所述 LLDP数据包的 TLV字段中解析出发送方的 MAC、 IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收到所述 LLDP数据包的端 口 in— port,
查询所述控制器列表， 判断是否存在与解析得到的 MAC、 IP相匹配的控 制器列表表项， 如果不存在， 新建控制器列表表项以记录解析得到的 MAC、 IP、 in— port,并设置预定的老化时间，然后使用 packet— out消息将所述 LLDP 数据包 FLOOD; 如果存在，
判断与解析得到的 MAC、 IP相匹配的控制器列表表项中的 in— port是否 与解析得到的 in— port相同， 如果相同， 则将该控制器列表表项对应的老化时 间重置为预定的老化时间， 然后使用 packet— out 消息将所述 LLDP数据包 FLOOD, 如果不同，
进一步判断该控制器列表表项对应的老化时间是否到达， 如果到达， 将 该控制器列表表项中的 in— port 修改为解析得到的 in— port , 然后使用 packet— out消息将所述 LLDP数据包 FLOOD, 如果未到达，
丟弃所述 LLDP数据包。
在第二方面的第四种可能的实现方式中， 所述握手包单元包括： 第一握 手包模块和第二握手包模块；
所述第一握手包模块， 用于接收用于建立 TCP连接的第一次 TCP握手 包， 解析所述第一次 TCP握手包得到目的 MAC和目的 IP， 根据解析到的目 的 MAC和目的 IP查询所述流表， 产生 TCP类型的 packet— in消息， 并将所 述 TCP类型的 packet— in消息发送到数据通道；
所述第二握手包模块用于从所述数据通道中获取 packet— in消息，解析所 述 packet— in消息，判断所述 packet— in消息是否是所述 TCP类型的 packet— in 消息， 当所述 packet— in消息是所述 TCP类型的 packet— in消息时，从所述 TCP 类型的 packet— in消息中解析出所述第一次 TCP握手包，并从所述第一次 TCP 握手包中解析出源 MAC、 源 IP、 目的 MAC和目的 IP， 以及，
根据解析出的目的 MAC和目的 IP查询所述控制器列表， 判断是否存在 与解析出的目的 MAC和目的 IP相匹配的控制器列表表项， 如果存在， 生成 第一流表项和第二流表项， 并将所述第一流表项和第二流表项发送给所述第 一握手包模块， 所述第一流表项中记录源 MAC为解析出的源 MAC, 源 IP为 解析出的源 IP，目的 MAC为解析出的目的 MAC,目的 IP为解析出的目的 IP， 转发端口为与解析出的目的 MAC 和目的 IP相匹配的控制器列表表项中的 in— port, 所述第二表项中记录源 MAC为解析出的目的 MAC, 源 IP为解析出 的目的 IP， 目的 MAC为解析出的源 MAC， 目的 IP为解析出的源 IP， 转发 端口为所述 TCP类型的 packet— in消息中的 in— port字段；
所述第一握手包模块， 还用于接收所述第一流表项和第二流表项， 并将 所述第一流表项和第二流表项添加至所述流表。
在第二方面的第五种可能的实现方式中， 所述第二握手包模块， 还用于 当所述控制器列表存在与解析出的目的 MAC和目的 IP相匹配的控制器列表 表项时， 产生 packet-out消息， 将所述 packet-out消息发送给所述第一握手 包模块， 所述 packet-out消息的执行动作 action字段指向所述流表；
所述第一握手包模块， 还用于解析所述 packet-out消息， 得到其中的所 述第一次 TCP握手包，解析所述第一次 TCP握手包得到目的 MAC和目的 IP， 根据解析到的目的 MAC和目的 IP查询所述流表，找到与解析到的目的 MAC 和目的 IP相匹配的流表项，根据该流表项中的转发端口转发所述第一次 TCP 握手包。
在第二方面的第六种可能的实现方式中， 所述第二握手包模块， 还用于 当所述控制器列表不存在与解析出的目的 MAC和目的 IP相匹配的表项时， 通过所述 0FS的管理端口发送所述 TCP类型的 packet— in消息。
在第二方面的第七种可能的实现方式中， 所述 0FS还包括：
第一流表项单元， 用于向所述流表中添加第一初始流表项， 所述第一初 始流表项的目的地址为 LLDP协议的组播地址， 协议类型为 LLDP协议的类 型编码， 转发端口指向 OFC， 数据包长度为全包长度， 优先级为最低。
在第二方面的第八种可能的实现方式中， 所述 OFS还包括：
第二流表项单元， 用于向所述流表中添加第二初始流表项， 所述第二初 始流表项的目的地址为本地地址， 协议类型为 TCP协议的类型编码， 转发端 口指向所述 OFS的管理端口， 数据包长度为全包长度， 优先级为最低。
在第二方面的第九种可能的实现方式中， 所述 OFS还包括：
邻居列表存储单元， 用于包括一个或多个邻居列表表项， 所述邻居列表 表项包括其他 OFS的 MAC、 IP以及与所述其他 OFS的 MAC、 IP对应的所 述 OFS接收所述其他 OFS发送的 LLDP数据包时的端口号；
所述数据包处理单元， 还用于当通过所述角色子字段判断接收到的所述 LLDP数据包的发送方类型为 OFS时，从所述 LLDP数据包的 TLV字段中解 析出发送方 MAC、 IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收到所述 LLDP数据包的端口 in— port, 以及，
查询所述邻居列表， 判断是否存在与解析得到的 MAC、 IP相匹配的邻居 列表表项， 如果不存在， 在所述邻居列表中新建邻居列表表项以记录解析得 到的 MAC、 IP和 in— port, 然后使用 packet— out消息将所述 LLDP数据包 FLOOD; 如果存在，
则判断与解析得到的 MAC、 IP相匹配的邻居列表表项对应的 in— port是 否与解析得到的 in— port相同， 如果相同， 使用 packet— out消息将所述 LLDP 数据包 FLOOD, 如果不同，
将该邻居列表表项对应的 in— port修改为解析得到的 in— port，然后丟弃所 述 LLDP数据包。
在第二方面的第十种可能的实现方式中， 所述 0FS还包括：
邻居列表发送单元， 用于将所述邻居列表发送至 0FC， 以供所述 0FC 根据邻居列表建立全网的网络拓朴， 以及，
当所述邻居列表改变时， 将改变后的邻居列表发送给所述 0FC， 以供所 在第二方面的第十一种可能的实现方式中， 所述发往 OFC的包既包括第 三次 TCP握手包， 也包括其他 OFS发往所述 OFC的数据包。
(三）有益效果
本发明所述 OFS带内通信方法及 OFS中， 所述方法包括： 接收 LLDP 数据包， 所述 LLDP数据包包含发送方的 MAC、 IP以及用于标识发送方类型 的角色子字段； 当通过所述角色子字段判断接收到的所述 LLDP数据包的发 送方类型为 OFC时， 新建或更新所述控制器列表表项， 新建或更新的控制器 列表表项包括所述 LLDP数据包中携带的所述本地 OFC的 MAC、 IP以及收 到所述 LLDP数据包的端口 in— port; 获取用于建立 TCP连接的第一次 TCP 握手包，根据所述 TCP握手包中携带的目的 MAC以及目的 IP查找所述控制 器列表中是否有对应的控制器列表表项， 如果有， 则根据所述控制器列表中 对应的控制器列表表项中的 MAC、 I P以及 in— port更新流表项，使得所述 0FS 能够通过流表将发往 0FC的包转发到 0FC。 通过釆用本发明的 0FS带内通 信方法及 0FS， 控制面信令和转发面数据承载于同一个 OpenFlow网络中， 仅需维护一个网管系统， 即可实现网络通信， 降低了组网成本。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面 描述中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1是一种现有的带外连接模式组网图；
图 2a是本发明实施例 1所述 0FS带内通信方法的流程图；
图 2b是本发明实施例 1所述 0FS带内通信方法的步骤 220的细化流程 图；
图 2c是本发明实施例 1所述 0FS带内通信方法的步骤 230的细化流程 图；
图 2d是实现本发明实施例 1所述 0FS带内通信方法的带内连接模式组 网图；
图 3是本发明实施例三所述 OFS的内部模块结构示意图；
图 4是本发明实施例三所述握手包单元的内部模块结构示意图； 图 5是本发明实施例四所述 OFS的内部模块结构示意图；
图 6是本发明所述 OFS的硬件结构示意图。
具体实施方式
下面结合附图和实施例， 对本发明的具体实施方式作进一步详细描述。 以下实施例用于说明本发明， 但不用来限制本发明的范围。
本发明旨在利用现有的 OpenFlow ( v1 .2 )规范及 LLDP ( Link Layer Discovery Protocol， 链路层发现协议）协议， 实现一种 OFS带内通信方法， 该方法中，每个 OFS对其所转发的数据包的内容（是控制信息或者数据信息） 不作区分，每个 OFS的控制信息均作为其他 OFS的数据信息在网络中转发， 只有当某个数据包的目的地址指向自身时， 该 OFS解析该数据包获得其中的 控制信息。 因此， 上述方法基于一个物理网络， 仅需维护一个网管系统， 即 可实现带内通信， 有效降低了实施成本。
接下来， 结合具体实施例详细说明本发明的 OFS带内通信方法及 OFS。 实施例一
图 2a是本发明实施例 1所述 OFS带内通信方法的流程图，如图 2a所示， 所述方法由 OFS执行， 所述方法包括步骤：
210: 接收所述 LLDP数据包， 所述 LLDP数据包包含发送方的 MAC、 IP以及用于标识发送方类型的角色子字段。
具体地， 所述 LLDP数据包可能由 OFC发送， 也可以由其他 OFS发送， 为了使接收方能够识别发送方的类型， 在所述 LLDP数据包中包含有用于标 识发送方类型的角色子字段。
优选地， 所述角色子字段位于所述 LLDP数据包中的标签长度值 TLV字 段。 下面表 3是 LLDP数据包的字段示例， 所述 LLDP数据包包括： Eth— dst 字段、 Eth— src字段、 Eth— type字段和标签长度值 TLV( BER编码一种， ASN1 标准，全称 Tag, Length , Value )字段；该 TLV字段包括： MAC( Media Access Control ， 硬件地址）子字段、 IP ( Internet Protocol, 网络之间互连的协议） 子字段、 角色子字段、 端口子字段。 其中， 表 3中第一行表示由 OFC发出的 LLDP数据包， 其角色子字段对应于 OFC， 其端口子字段对应 OFC的监听端 口； 表 3中第二行表示由 OFS发出的 LLDP数据包， 其角色子字段对应于 OFS, 其端口子字段对应 OFS的物理端口号。
LLDP数据包的字段示例
Figure imgf000015_0001
所述 OFS包括硬件模块以及软件模块， 硬件模块（基于一些专用的硬件 定制器件， 如 FPGA、 ASIC等）用于在 OFS收到包后进行流表匹配， 即收 到包后通过硬件模块匹配流表， 如果能匹配， 则按匹配项中的指令进行转发， 如果不匹配， 则将包送至软件模块（基于 CPU )。 其中， 所述接收所述 LLDP 数据包， 具体为： 所述 OFS的硬件模块接收所述 LLDP数据包， 根据接收到 的所述 LLDP数据包查询流表， 匹配不成功后， 产生 packet— in 消息， 并将 packet— in消息发送到软件模块。
220: 当通过所述角色子字段判断接收到的所述 LLDP数据包的发送方类 型为 OFC时， 新建或更新所述控制器列表表项， 新建或更新的控制器列表表 项包括所述 LLDP数据包中携带的所述本地 OFC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port。
具体地， 所述 OFS包括控制器列表， 所述控制器列表用于保存一个或多 个控制器列表表项， 所述控制器列表表项包括本地开放流控制器 OFC 的 MAC, IP以及与所述本地 OFC的 MAC、 IP对应的所述 OFS接收所述 OFC 发送的链路层发现协议 LLDP数据包时的端口号。 所述 OFS根据接收到的所 述 LLDP数据包新建或更新所述控制器列表表项， 进而根据控制器列表表项 更新流表项， 以建立所述 OFS与 OFC之间的连接。
图 2b是本发明实施例 1所述 OFS带内通信方法的步骤 220的细化流程 图， 所述步骤 220具体包括：
221 : OFS的软件模块接述硬件模块发送的 packet— in消息（硬件模块查 流表不成功时会生成 packet— in消息），解析 packet— in消息，判断 packet— in 消息是否是 LLDP类型的 packet— in消息。
222: 当 packet— in消息的是 LLDP类型的 packet— in消息时， OFS的软 件模块从 LLDP类型的 packet— in消息中解析出 LLDP数据包，并从 LLDP数 据包的 TLV字段中解析出角色子字段。
223:当根据角色子字段判断接收到的 LLDP数据包的发送方类型为 OFC 时， OFS的软件模块从 LLDP数据包的 TLV字段中解析出发送方的 MAC、 IP, 并从 LLDP类型的 packet— in消息中解析出 OFS收到 LLDP数据包的端口 in— port。
224： OFS 的软件模块查询控制器列表， 判断是否存在与解析得到的 MAC, IP相匹配的控制器列表表项， 如果不存在， 新建控制器列表表项以记 录解析得到的 MAC、 IP、 in— port,并设置预定的老化时间，然后使用 packet— out 消息将 LLDP数据包 FLOOD( FOOD即从入端口以外的所有可用端口转发）； 如果存在， 执行步骤 225。
225: OFS的软件模块判断与解析得到的 MAC、 IP相匹配的控制器列表 表项中的 in— port是否与解析得到的 in— port相同， 如果相同， 则将该控制器 列表表项对应的老化时间重置为预定的老化时间， 然后使用 packet— out消息 将 LLDP数据包 FLOOD, 如果不同， 执行步骤 226。
226: OFS 的软件模块进一步判断该控制器列表表项对应的老化时间是 否到达， 如果到达， 将该控制器列表表项中的 in— port 修改为解析得到的 in— port, 然后使用 packet— out消息将 LLDP数据包 FLOOD, 如果未到达， OFS的软件模块丟弃 LLDP数据包。 方法还包括：
230: 获取用于建立 TCP连接的第一次 TCP握手包， 根据 TCP握手包 中携带的目的 MAC以及目的 IP查找控制器列表中是否有对应的控制器列表 表项， 如果有， 则根据控制器列表中对应的控制器列表表项中的 MAC、 IP以 及 in— port更新流表项，使得 OFS能够通过流表将发往 OFC的包转发到 OFC。
其中， 流表建立后， OFS基于流表完成与 OFC之间的 TCP握手通信， 建立与 OFC之间的 TCP连接。 发往 OFC的包既包括第三次 TCP握手包， 也包括其他 OFS发往 OFC的数据包。
图 2c是本发明实施例 10FS带内通信方法的步骤 230的细化流程图，步 骤 230具体包括：
231 : OFS的硬件模块接收用于建立 TCP连接的第一次 TCP握手包， 解析第一次 TCP握手包得到目的 MAC和目的 IP， 根据解析到的目的 MAC 和目的 IP查询流表， 产生 TCP类型的 packet— in 消息， 并将 TCP类型的 packet— in消息发送到软件模块；
232: OFS 的软件模块接收硬件模块发送中获取 packet— in 消息， 解析 packet— in消息， 判断 packet— in消息是否是 TCP类型的 packet— in消息；
233： 当判断 packet— in消息是 TCP类型的 packet— in消息时， OFS的 软件模块从 TCP类型的 packet— in消息中解析出第一次 TCP握手包，并从第 一次 TCP握手包中解析出源 MAC、 源 IP、 目的 MAC和目的 IP;
234: OFS的软件模块根据解析出的目的 MAC和目的 IP查询控制器列 表，判断是否存在与解析出的目的 MAC和目的 IP相匹配的控制器列表表项， 如果存在， 执行步骤 235， 237， 不存在时执行 239。
235: 生成第一流表项和第二流表项， 并将第一流表项和第二流表项发送 给 OFS的硬件模块， 第一流表项中记录源 MAC为解析出的源 MAC， 源 IP 为解析出的源 IP， 目的 MAC为解析出的目的 MAC， 目的 IP为解析出的目的 IP, 转发端口为与解析出的目的 MAC和目的 IP相匹配的控制器列表表项中 的 in— port, 第二表项中记录源 MAC为解析出的目的 MAC， 源 IP为解析出 的目的 IP， 目的 MAC为解析出的源 MAC， 目的 IP为解析出的源 IP， 转发 端口为 TCP类型的 packet— in消息中的 in— port字段。
236: OFS 的硬件模块， 接收第一流表项和第二流表项， 并将第一流表 项和第二流表项添加至流表。
另外， 当控制器列表存在与解析出的目的 MAC和目的 IP相匹配的控制 器列表表项时， 还包括步骤：
237: 0FS的软件模块产生 packet-out消息， 将 packet-out消息发送给 0 FS的硬件模块， packet-out消息的执行动作 action字段指向流表。
238： 0FS的硬件模块解析 packet-out消息， 得到其中的第一次 TCP握 手包， 解析第一次 TCP握手包得到目的 MAC和目的 IP， 根据解析到的目的 MAC和目的 IP查询流表， 找到与解析到的目的 MAC和目的 IP相匹配的流 表项， 根据该流表项中的转发端口转发第一次 TCP握手包。
当控制器列表不存在与解析出的目的 MAC和目的 IP相匹配的表项时， 还包括步骤：
239： 0FS的软件模块通过 0FS的管理端口发送 TCP类型的 packet— in 消息。
图 2d是实现本发明实施例 0FS带内通信方法的带内连接模式组网图， 如图 2d所示， 本发明实施例中， 每个 0FS对其所转发的数据包的内容（是 控制信息或者数据信息） 不作区分， 每个 0FS 的控制信息均作为其他 0FS 的数据信息在网络中转发，只有当某个数据包的目的地址指向自身时，该 0FS 解析该数据包获得其中的控制信息。 因此， 上述方法基于一个物理网络， 仅 需维护一个网管系统， 即可实现带内通信， 有效降低了实施成本。 另外， 0FS 通过解析来自 0FC的 LLDP包， 可以实现 0FS对 0FC的自发现， 减少了交 换机配置时间。
实施例二
本实施例二基于实施例 1进行描述。
可选地， 所述方法在步骤 21 0之前还可以包括：
所述 0FS向所述流表中添加第一初始流表项， 所述第一初始流表项的目 的地址为 LLDP协议的组播地址， 协议类型为 LLDP协议的类型编码， 转发 端口指向 OFC， 数据包长度为全包长度， 优先级为最低。
所述 OFS向所述流表中添加第二初始流表项， 所述第二初始流表项的目 的地址为本地地址， 协议类型为 TCP 协议的类型编码， 转发端口指向所述 OFS的管理端口， 数据包长度为全包长度， 优先级为最低。
具体地， 下面表 1 是第一初始流表项示例， ， 其中， 01 :80:c2:00:00:0e 表示 LLDP协议的组播地址， 其为 MAC地址； 0x88CC表示 LLDP协议的类 型编码； Controller表示指向 OFC的转发端口； OFPR— NO— BUFFER表示数 据包长度为全包长度
表 1 第一初始流表项示例
Figure imgf000019_0001
下面表 2是第二初始流表项示例，其中，第一个 Self表示指向本地的 MAC 地址； 0x0800表示 TCP协议的类型编码； 第二个 Self表示指向本地的 IP地 址； LOCAL表示转发端口指向所述 0FS的管理端口； OFPR— NO— BUFFER 表示数据包长度为全包长度。
表 2 第二初始流表项示例
Figure imgf000019_0002
通过设置所述第一初始流表项后， 所述 OFS的硬件模块接收所述 LLDP 数据包， 根据接收到的所述 LLDP 数据包查询所述流表产生 LLDP 类型的 packet— in消息， 并将所述 LLDP类型的 packet— in消息发送到软件模块， 进 而触发所述 OFS的软件模块对 LLDP类型的 packet— in消息进行后续处理。
通过设置所述第二初始流表项后， 所述 OFS 的硬件模块接收用于建立 TCP连接的第一次 TCP握手包，解析所述第一次 TCP握手包得到目的 MAC 和目的 IP，根据解析到的目的 MAC和目的 IP查询所述流表，产生 TCP类型 的 packet— in消息， 并将所述 TCP类型的 packet— in消息发送到软件模块， 进而触发所述 OFS的软件模块对 TCP类型的 packet— in消息进行后续处理。
可选地， 所述方法中， 当通过所述角色子字段判断接收到的所述 LLDP 数据包的发送方类型为 OFC时， 还包括：
广播发送方类型为 OFC的所述 LLDP数据包， 使得其他 OFS也能够执 行， 所述接收所述 LLDP数据包， 所述 LLDP数据包包含发送方的 MAC、 IP 以及用于标识发送方类型的角色子字段， 和， 当通过所述角色子字段判断接 收到的所述 LLDP数据包的发送方类型为 OFC时，新建或更新所述控制器列 表表项， 新建或更新的控制器列表表项包括所述 LLDP数据包中携带的所述 本地 OFC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port的步骤。
可选地， 所述 OFS还包括邻居列表， 所述邻居列表包括一个或多个邻居 列表表项，所述邻居列表表项包括其他 OFS的 MAC、 IP以及与所述其他 OFS 的 MAC、 IP对应的所述 OFS接收所述其他 OFS发送的 LLDP数据包时的端 口号。
所述步骤 210之后， 还包括步骤：
当通过所述角色子字段判断接收到的所述 LLDP数据包的发送方类型为 OFS时， 所述 OFS的软件模块从所述 LLDP数据包的 TLV字段中解析出发 送方 MAC、 IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收 到所述 LLDP数据包的端口 in— port;
所述 OFS 的软件模块查询所述邻居列表， 判断是否存在与解析得到的 MAC, IP相匹配的邻居列表表项， 如果不存在， 在所述邻居列表中新建邻居 列表表项以记录解析得到的 MAC、 IP和 in— port, 然后使用 packet— out消息 将所述 LLDP数据包 FLOOD; 如果存在，
则判断与解析得到的 MAC、 IP相匹配的邻居列表表项对应的 in— port是 否与解析得到的 in— port相同， 如果相同， 使用 packet— out消息将所述 LLDP 数据包 FLOOD, 如果不同，
将该邻居列表表项对应的 in— port修改为解析得到的 in— port，然后丟弃所 述 LLDP数据包。
另外， 在所述步骤 230之后还可以包括：
所述 OFS将所述邻居列表发送至 OFC， 以供所述 OFC根据邻居列表建 立全网的网络拓朴；
当所述邻居列表改变时， 所述 0FS 将改变后的邻居列表发送给所述 也就是说， 0FS与 0FC之间的 TCP连接建立后， 各 0FS主动将其所 掌握的邻居列表发送给 0FC， OFC汇总后可以得到全网的网络拓朴。 另夕卜， 当邻居列表改变时， 0FS将改变后的邻居列表发送给 0FC， OFC根据改变 后的邻居列表更新全网的网络拓朴。
本实施例中， 由 0FS代替 0FC来完成网络拓朴的发现， 大大减小了网 络拓朴发现的时间。
实施例三
图 3是本发明实施例三所述 0FS的内部模块结构示意图， 如图 3所示， 所述 OFS 300包括： 控制器列表存储单元 310、 数据包接收单元 320、 数据 包处理单元 330和握手包单元 340。
所述控制器列表存储单元 310， 用于保存一个或多个控制器列表表项， 所述控制器列表表项包括本地开放流控制器 0FC的 MAC、 IP以及与所述本 地 0FC的 MAC、 IP对应的所述 0FS接收所述 0FC发送的链路层发现协议 LLDP数据包时的端口号。
所述数据包接收单元 320， 用于接收所述 LLDP数据包， 所述 LLDP数 据包包含发送方的 MAC、 IP以及用于标识发送方类型的角色子字段。 其中，所述角色子字段位于所述 LLDP数据包中的标签长度值 TLV字段。 所述数据包接收单元 320， 具体用于接收所述 LLDP数据包， 根据接收 到的所述 LLDP数据包查询所述流表产生 LLDP类型的 packet— in消息，并将 所述 LLDP类型的 packet— in消息发送到数据通道。
所述数据包处理单元 330， 用于当通过所述角色子字段判断接收到的所 述 LLDP数据包的发送方类型为 OFC时， 新建或更新所述控制器列表表项， 新建或更新的控制器列表表项包括所述 LLDP数据包中携带的所述本地 OFC 的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port。
所述数据包处理单元 330，具体用于从所述数据通道中获取 packet— in消 息， 解析所述 packet— in消息， 判断所述 packet— in消息是否是所述 LLDP类 型的 packet— in消息，
当判断所述 packet— in消息的是所述 LLDP类型的 packet— in消息时， 从 所述 LLDP类型的 packet— in消息中解析出所述 LLDP数据包，并从所述 LLDP 数据包的 TLV字段中解析出所述角色子字段， 以及，
从所述 LLDP数据包的 TLV字段中解析出发送方的 MAC、 IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收到所述 LLDP数据包的端 口 in— port,
查询所述控制器列表， 判断是否存在与解析得到的 MAC、 IP相匹配的控 制器列表表项， 如果不存在， 新建控制器列表表项以记录解析得到的 MAC、 IP、 in— port,并设置预定的老化时间，然后使用 packet— out消息将所述 LLDP 数据包 FLOOD; 如果存在，
判断与解析得到的 MAC、 IP相匹配的控制器列表表项中的 in— port是否 与解析得到的 in— port相同， 如果相同， 则将该控制器列表表项对应的老化时 间重置为预定的老化时间， 然后使用 packet— out 消息将所述 LLDP数据包 FLOOD, 如果不同，
进一步判断该控制器列表表项对应的老化时间是否到达， 如果到达， 将 该控制器列表表项中的 in— port 修改为解析得到的 in— port , 然后使用 packet— out消息将所述 LLDP数据包 FLOOD, 如果未到达， 丟弃所述 LLDP数据包。
所述握手包单元 340， 用于获取用于建立 TCP连接的第一次 TCP握手 包，根据所述 TCP握手包中携带的目的 MAC以及目的 IP查找所述控制器列 表中是否有对应的控制器列表表项， 如果有， 则根据所述控制器列表中对应 的控制器列表表项中的 MAC、 IP以及 in— port更新流表项，使得所述 OFS能 够通过流表将发往 OFC的包转发到 OFC。
参见图 4， 所述握手包单元 340包括： 第一握手包模块 341和第二握手 包模块 342。
所述第一握手包模块 341， 用于接收用于建立 TCP连接的第一次 TCP 握手包， 解析所述第一次 TCP握手包得到目的 MAC和目的 IP， 根据解析到 的目的 MAC和目的 IP查询所述流表， 产生 TCP类型的 packet— in消息， 并 将所述 TCP类型的 packet— in消息发送到数据通道。
所述第二握手包模块 342， 用于从所述数据通道中获取 packet— in消息， 解析所述 packet— in消息， 判断所述 packet— in消息是否是所述 TCP类型的 packet— in消息，
当所述 packet— in消息是所述 TCP类型的 packet— in消息时，从所述 TCP 类型的 packet— in消息中解析出所述第一次 TCP握手包，并从所述第一次 TCP 握手包中解析出源 MAC、 源 IP、 目的 MAC和目的 IP， 以及，
根据解析出的目的 MAC和目的 IP查询所述控制器列表， 判断是否存在 与解析出的目的 MAC和目的 IP相匹配的控制器列表表项， 如果存在， 生成 第一流表项和第二流表项， 并将所述第一流表项和第二流表项发送给所述第 一握手包模块， 所述第一流表项中记录源 MAC为解析出的源 MAC, 源 IP为 解析出的源 IP，目的 MAC为解析出的目的 MAC,目的 IP为解析出的目的 IP， 转发端口为与解析出的目的 MAC 和目的 IP相匹配的控制器列表表项中的 in— port, 所述第二表项中记录源 MAC为解析出的目的 MAC, 源 IP为解析出 的目的 IP， 目的 MAC为解析出的源 MAC， 目的 IP为解析出的源 IP， 转发 端口为所述 TCP类型的 packet— in消息中的 in— port字段。
所述第一握手包模块 341， 还用于接收所述第一流表项和第二流表项， 并将所述第一流表项和第二流表项添加至所述流表。
所述第二握手包模块 342， 还用于当所述控制器列表存在与解析出的目 的 MAC和目的 IP相匹配的控制器列表表项时， 产生 packet-out消息， 将所 述 packet-out消息发送给所述第一握手包模块， 所述 packet-out消息的执行 动作 action字段指向所述流表。
所述第一握手包模块 341， 还用于解析所述 packet-out消息， 得到其中 的所述第一次 TCP握手包，解析所述第一次 TCP握手包得到目的 MAC和目 的 IP， 根据解析到的目的 MAC和目的 IP查询所述流表， 找到与解析到的目 的 MAC和目的 IP相匹配的流表项， 根据该流表项中的转发端口转发所述第 一次 TCP握手包。
所述第二握手包模块 342， 还用于当所述控制器列表不存在与解析出的 目的 MAC和目的 IP相匹配的表项时， 通过所述 0FS的管理端口发送所述 TCP类型的 packet— in消息。
实施例四
本实施例基于实施例三进行描述。 图 5是本发明实施例四所述 0FS的内 部模块结构示意图， 如图 5所示， 本实施例所述 0FS 500除包括： 控制器列 表存储单元 510、 数据包接收单元 520、 数据包处理单元 530和握手包单元 540之外， 还包括： 数据包广播单元 550、 第一流表项单元 560、 第二流表项 单元 570、 邻居列表存储单元 580和邻居列表发送单元 590。
所述数据包广播单元 550， 用于广播发送方类型为 0FC的所述 LLDP数 据包， 使得其他 0FS也能够接收所述 LLDP数据包， 所述 LLDP数据包包含 发送方的 MAC、 IP以及用于标识发送方类型的角色子字段， 和， 当通过所述 角色子字段判断接收到的所述 LLDP数据包的发送方类型为 0FC时，新建或 更新所述控制器列表表项， 新建或更新的控制器列表表项包括所述 LLDP数 据包中携带的所述本地 0FC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port。
所述第一流表项单元 560， 用于向所述流表中添加第一初始流表项， 所 述第一初始流表项的目的地址为 LLDP协议的组播地址， 协议类型为 LLDP 协议的类型编码， 转发端口指向 OFC， 数据包长度为全包长度， 优先级为最 低。
所述第二流表项单元 570， 用于向所述流表中添加第二初始流表项， 所 述第二初始流表项的目的地址为本地地址，协议类型为 TCP协议的类型编码， 转发端口指向所述 OFS的管理端口，数据包长度为全包长度，优先级为最低。
所述邻居列表存储单元 580， 用于包括一个或多个邻居列表表项， 所述 邻居列表表项包括其他 OFS的 MAC、 IP以及与所述其他 OFS的 MAC、 IP 对应的所述 OFS接收所述其他 OFS发送的 LLDP数据包时的端口号。
所述数据包处理单元 530， 还用于当通过所述角色子字段判断接收到的 所述 LLDP数据包的发送方类型为 OFS时，从所述 LLDP数据包的 TLV字段 中解析出发送方 MAC、 IP, 并从所述 LLDP类型的 packet— in消息中解析出 所述 OFS收到所述 LLDP数据包的端口 in— port, 以及，
查询所述邻居列表， 判断是否存在与解析得到的 MAC、 IP相匹配的邻居 列表表项， 如果不存在， 在所述邻居列表中新建邻居列表表项以记录解析得 到的 MAC、 IP和 in— port, 然后使用 packet— out消息将所述 LLDP数据包 FLOOD; 如果存在，
则判断与解析得到的 MAC、 IP相匹配的邻居列表表项对应的 in— port是 否与解析得到的 in— port相同， 如果相同， 使用 packet— out消息将所述 LLDP 数据包 FLOOD, 如果不同，
将该邻居列表表项对应的 in— port修改为解析得到的 in— port，然后丟弃所 述 LLDP数据包。
所述邻居列表发送单元 590， 用于将所述邻居列表发送至 0FC， 以供所 述 0FC根据邻居列表建立全网的网络拓朴， 以及，
当所述邻居列表改变时， 将改变后的邻居列表发送给所述 0FC， 以供所 本发明实施例中的 0FS可以基于计算机系统来实现， 图 2a、 图 2b、 图 2c所示的方法均可在基于计算机系统的 0FS来实现。 图 6示出了基于计算 机系统来实现的 0FS的实施例。 本实施例中 0FS可以包括： 处理器 601、 存储器 602和通信接口 603， 其中：
通信接口 603， 用于与 OFC或其他 OFS通信。 具体地， 通信接口 603 用于接收 LLDP数据包和第一次 TCP握手包；存储器 602用于存储程序指令、 控制器列表和流表等； 处理器 601 用于在接收所述 LLDP数据包之后， 调用 存储器 602中存储的程序指令， 执行如下操作： 当通过所述角色子字段判断 接收到的所述 LLDP数据包的发送方类型为 OFC时，新建或更新所述控制器 列表表项， 新建或更新的控制器列表表项包括所述 LLDP数据包中携带的所 述本地 OFC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port; 以及， 在接收用于建立 TCP连接的第一次 TCP握手包后， 调用存储器 602中存储 的程序指令， 执行如下操作： 根据所述 TCP握手包中携带的目的 MAC以及 目的 IP查找所述控制器列表中是否有对应的控制器列表表项， 如果有， 则根 据所述控制器列表中对应的控制器列表表项中的 MAC、 IP以及 in— port更新 流表项， 使得所述 0FS能够通过流表将发往 0FC的包转发到 0FC。
其中， 处理器 601 可以是中央处理器（ central processing unit, CPU ) 、 专用集成电路 ( application-specific integrated circuit, ASIC )等。 其中， 本 实施例中的 OFS可以包括总线 604。 处理器 601、 存储器 602以及通信接口 603之间可通过总线 604连接并通信。 其中， 存储器 602可以包括： 随机存 取存储器（ random access memory, RAM )，只读存储器（ read-only memory, ROM ) ， 磁盘等具有存储功能的实体；
处理器 601 还可以用于执行方法实施例二中描述的各步骤， 本发明实施 例在此不再详述。
本发明所述 OFS带内通信方法及 OFS中， 所述方法包括： 接收 LLDP 数据包， 所述 LLDP数据包包含发送方的 MAC、 IP以及用于标识发送方类型 的角色子字段； 当通过所述角色子字段判断接收到的所述 LLDP数据包的发 送方类型为 OFC时， 新建或更新所述控制器列表表项， 新建或更新的控制器 列表表项包括所述 LLDP数据包中携带的所述本地 OFC的 MAC、 IP以及收 到所述 LLDP数据包的端口 in— port; 获取用于建立 TCP连接的第一次 TCP 握手包，根据所述 TCP握手包中携带的目的 MAC以及目的 IP查找所述控制 器列表中是否有对应的控制器列表表项， 如果有， 则根据所述控制器列表中 对应的控制器列表表项中的 MAC、 I P以及 in— port更新流表项，使得所述 OFS 能够通过流表将发往 OFC的包转发到 OFC。 通过釆用本发明的 OFS带内通 信方法及 OFS， 控制面信令和转发面数据承载于同一个 OpenFlow网络中， 仅需维护一个网管系统， 即可实现网络通信， 降低了组网成本。
本领域普通技术人员将会理解， 本发明的各个方面、 或各个方面的可能 实现方式可以被具体实施为系统、 方法或者计算机程序产品。 因此， 本发明 的各方面、 或各个方面的可能实现方式可以釆用完全硬件实施例、 完全软件 实施例 （包括固件、 驻留软件等等）， 或者组合软件和硬件方面的实施例的形 式， 在这里都统称为"电路"、 "模块 "或者 "系统"。 此外， 本发明的各方面、 或 各个方面的可能实现方式可以釆用计算机程序产品的形式， 计算机程序产品 是指存储在计算机可读介质中的计算机可读程序代码。
计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。 计算机可读存储介质包含但不限于电子、 磁性、 光学、 电磁、 红外或半导体 系统、 设备或者装置，或者前述的任意适当组合，如随机存取存储器 （RAM)、 只读存储器 （ROM)、可擦除可编程只读存储器（EPROM或者快闪存储器）、 光纤、 便携式只读存储器 (CD-ROM)。
计算机中的处理器读取存储在计算机可读介质中的计算机可读程序代 码， 使得处理器能够执行在流程图中每个步骤、 或各步骤的组合中规定的功 能动作； 生成实施在框图的每一块、 或各块的组合中规定的功能动作的装置。
计算机可读程序代码可以完全在用户的计算机上执行、 部分在用户的计 算机上执行、 作为单独的软件包、 部分在用户的计算机上并且部分在远程计 算机上， 或者完全在远程计算机或者服务器上执行。 也应该注意， 在某些替 代实施方案中， 在流程图中各步骤、 或框图中各块所注明的功能可能不按图 中注明的顺序发生。 例如， 依赖于所涉及的功能， 接连示出的两个步骤、 或 两个块实际上可能被大致同时执行， 或者这些块有时候可能被以相反顺序执 行。 发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权利要求 书
1、 一种开放流交换机 OFS带内通信方法， 其特征在于， 由 0FS执行， 所 述 0FS包括控制器列表，所述控制器列表用于保存一个或多个控制器列表表项， 所述控制器列表表项包括本地开放流控制器 OFC的 MAC、 IP以及与所述本地 OFC的 MAC、 IP对应的所述 OFS接收所述 OFC发送的链路层发现协议 LLDP 数据包时的端口号， 所述方法包括：
接收所述 LLDP数据包， 所述 LLDP数据包包含发送方的 MAC、 IP以及用 于标识发送方类型的角色子字段；
当通过所述角色子字段判断接收到的所述 LLDP 数据包的发送方类型为 OFC时， 新建或更新所述控制器列表表项， 新建或更新的控制器列表表项包括 所述 LLDP数据包中携带的所述本地 OFC的 MAC、 IP以及收到所述 LLDP数 据包的端口 in— port;
所述方法还包括：
获取用于建立 TCP连接的第一次 TCP握手包， 根据所述 TCP握手包中携 带的目的 MAC以及目的 IP查找所述控制器列表中是否有对应的控制器列表表 项， 如果有， 则根据所述控制器列表中对应的控制器列表表项中的 MAC、 IP以 及 in— port更新流表项， 使得所述 0FS能够通过流表将发往 0FC的包转发到 0FC。
2、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括步骤： 广播发送方类型为 0FC的所述 LLDP数据包，使得其他 0FS也能够执行， 所述接收所述 LLDP数据包， 所述 LLDP数据包包含发送方的 MAC、 IP以及用 于标识发送方类型的角色子字段， 和， 当通过所述角色子字段判断接收到的所 述 LLDP数据包的发送方类型为 0FC时， 新建或更新所述控制器列表表项， 新 建或更新的控制器列表表项包括所述 LLDP数据包中携带的所述本地 0FC 的 MAC, IP以及收到所述 LLDP数据包的端口 in— port的步骤。
3、如权利要求 1所述的方法，其特征在于，所述角色子字段位于所述 LLDP 数据包中的标签长度值 TLV字段。
4、 如权利要求 1所述的方法， 其特征在于， 所述 OFS包括硬件模块以及软件模块；
所述接收所述 LLDP数据包，具体为：所述 OFS的硬件模块接收所述 LLDP 数据包， 根据接收到的所述 LLDP 数据包查询所述流表产生 LLDP 类型的 packet— in消息， 并将所述 LLDP类型的 packet— in消息发送到所述软件模块； 所述角色子字段的获得过程如下：
所述 OFS的软件模块接收所述硬件模块发送的 packet— in消息， 解析所述 packet— in消息， 判断所述 packet— in消息是否是所述 LLDP类型的 packet— in 消息；
当判断所述 packet— in 消息是所述 LLDP类型的 packet— in消息时， 所述 OFS的软件模块从所述 LLDP类型的 packet— in消息中解析出所述 LLDP数据 包， 并从所述 LLDP数据包的 TLV字段中解析出所述角色子字段；
所述新建或更新所述控制器列表表项， 具体包括：
所述 OFS的软件模块从所述 LLDP数据包的 TLV字段中解析出发送方的 MAC, IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收到所述 LLDP数据包的端口 in— port;
所述 OFS 的软件模块查询所述控制器列表， 判断是否存在与解析得到的 MAC, IP相匹配的控制器列表表项， 如果不存在， 新建控制器列表表项以记录 解析得到的 MAC、 IP、 in— port, 并设置预定的老化时间， 然后使用 packet— out 消息将所述 LLDP数据包 FLOOD; 如果存在，
所述 OFS的软件模块判断与解析得到的 MAC、 IP相匹配的控制器列表表 项中的 in— port是否与解析得到的 in— port相同， 如果相同， 则将该控制器列表 表项对应的老化时间重置为预定的老化时间， 然后使用 packet— out消息将所述 LLDP数据包 FLOOD, 如果不同，
所述 OFS的软件模块进一步判断该控制器列表表项对应的老化时间是否到 达， 如果到达， 将该控制器列表表项中的 in— port修改为解析得到的 in— port, 然 后使用 packet— out消息将所述 LLDP数据包 FLOOD, 如果未到达，
所述 0FS的软件模块丟弃所述 LLDP数据包。
5、 如权利要求 1所述的方法， 其特征在于， 所述 OFS包括硬件模块以及软件模块；
获取用于建立 TCP连接的第一次 TCP握手包， 根据所述 TCP握手包中携 带的目的 MAC以及目的 IP查找所述控制器列表中是否有对应的控制器列表表 项， 如果有， 则根据所述控制器列表中对应的控制器列表表项中的 MAC、 IP以 及 in— port更新流表项， 使得所述 OFS能够通过流表将发往 OFC的包转发到 OFC, 具体包括：
所述 OFS的硬件模块接收用于建立 TCP连接的第一次 TCP握手包， 解析 所述第一次 TCP握手包得到目的 MAC和目的 IP， 根据解析到的目的 MAC和 目的 IP查询所述流表， 产生 TCP类型的 packet— in消息， 并将所述 TCP类型 的 packet— in消息发送到所述软件模块；
所述 OFS的软件模块接收所述硬件模块发送的 packet— in消息， 解析所述 packet— in消息， 判断所述 packet— in消息是否是所述 TCP类型的 packet— in消 息；
当判断所述 packet— in消息是所述 TCP类型的 packet— in消息时，所述 OFS 的软件模块从所述 TCP类型的 packet— in消息中解析出所述第一次 TCP握手 包，并从所述第一次 TCP握手包中解析出源 MAC、源 IP、目的 MAC和目的 IP; 所述 OFS的软件模块根据解析出的目的 MAC和目的 IP查询所述控制器列 表， 判断是否存在与解析出的目的 MAC和目的 IP相匹配的控制器列表表项， 如果存在， 生成第一流表项和第二流表项， 并将所述第一流表项和第二流表项 发送给所述 0FS 的硬件模块， 所述第一流表项中记录源 MAC 为解析出的源 MAC, 源 IP为解析出的源 IP， 目的 MAC为解析出的目的 MAC， 目的 IP为解 析出的目的 IP， 转发端口为与解析出的目的 MAC和目的 IP相匹配的控制器列 表表项中的 in— port, 所述第二表项中记录源 MAC为解析出的目的 MAC, 源 IP 为解析出的目的 IP， 目的 MAC为解析出的源 MAC， 目的 IP为解析出的源 IP， 转发端口为所述 TCP类型的 packet— in消息中的 in— port字段；
所述 OFS的硬件模块， 接收所述第一流表项和第二流表项， 并将所述第一 流表项和第二流表项添加至所述流表。
6、 如权利要求 5所述方法， 其特征在于， 当所述控制器列表存在与解析出的目的 MAC和目的 IP相匹配的控制器列 表表项时， 还包括步骤：
所述 OFS的软件模块产生 packet-out消息，将所述 packet-out消息发送给 所述 OFS的硬件模块，所述 packet-out消息的执行动作 action字段指向所述流 表；
所述 OFS 的硬件模块解析所述 packet-out消息， 得到其中的所述第一次 TCP握手包， 解析所述第一次 TCP握手包得到目的 MAC和目的 IP， 根据解析 到的目的 MAC和目的 IP查询所述流表， 找到与解析到的目的 MAC和目的 IP 相匹配的流表项， 根据该流表项中的转发端口转发所述第一次 TCP握手包。
7、 如权利要求 5所述方法， 其特征在于，
当所述控制器列表不存在与解析出的目的 MAC和目的 IP相匹配的表项时， 还包括步骤：
所述 0FS 的软件模块通过所述 0FS 的管理端口发送所述 TCP 类型的 packet— in消息。
8、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括：
所述 0FS向所述流表中添加第一初始流表项， 所述第一初始流表项的目的 地址为 LLDP协议的组播地址， 协议类型为 LLDP协议的类型编码， 转发端口 指向 0FC， 数据包长度为全包长度， 优先级为最低。
9、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括：
所述 0FS向所述流表中添加第二初始流表项， 所述第二初始流表项的目的 地址为本地地址， 协议类型为 TCP协议的类型编码， 转发端口指向所述 0FS 的管理端口， 数据包长度为全包长度， 优先级为最低。
10、 如权利要求 1所述的方法， 其特征在于，
所述 0FS还包括邻居列表， 所述邻居列表包括一个或多个邻居列表表项， 所述邻居列表表项包括其他 0FS的 MAC、 IP以及与所述其他 0FS的 MAC、 IP对应的所述 0FS接收所述其他 0FS发送的 LLDP数据包时的端口号；
当通过所述角色子字段判断接收到的所述 LLDP 数据包的发送方类型为 0FS时， 所述方法还包括步骤： 所述 OFS 的软件模块从所述 LLDP数据包的 TLV 字段中解析出发送方 MAC, IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS收到所述 LLDP数据包的端口 in— port;
所述 OFS 的软件模块查询所述邻居列表， 判断是否存在与解析得到的 MAC, IP相匹配的邻居列表表项， 如果不存在， 在所述邻居列表中新建邻居列 表表项以记录解析得到的 MAC、 IP和 in— port, 然后使用 packet— out消息将所 述 LLDP数据包 FLOOD; 如果存在，
则判断与解析得到的 MAC、 IP相匹配的邻居列表表项对应的 in— port是否 与解析得到的 in— port相同， 如果相同， 使用 packet— out消息将所述 LLDP数 据包 FLOOD, 如果不同，
将该邻居列表表项对应的 in— port修改为解析得到的 in— port，然后丟弃所述 LLDP数据包。
1 1、 如权利要求 10所述的方法， 其特征在于， 所述方法还包括步骤： 所述 OFS将所述邻居列表发送至 OFC， 以供所述 OFC根据邻居列表建立 全网的网络拓朴；
当所述邻居列表改变时， 所述 OFS将改变后的邻居列表发送给所述 0FC，
12、 如权利要求 1至 1 1任一项所述方法， 其特征在于， 所述发往 0FC的 包既包括第三次 TCP握手包， 也包括其他 0FS发往所述 0FC的数据包。
13、 一种 0FS， 其特征在于， 包括：
控制器列表存储单元， 用于保存一个或多个控制器列表表项， 所述控制器 列表表项包括本地开放流控制器 0FC 的 MAC、 IP 以及与所述本地 0FC 的 MAC, IP对应的所述 0FS接收所述 0FC发送的链路层发现协议 LLDP数据包 时的端口号；
数据包接收单元， 用于接收所述 LLDP数据包， 所述 LLDP数据包包含发 送方的 MAC、 IP以及用于标识发送方类型的角色子字段；
数据包处理单元， 用于当通过所述角色子字段判断接收到的所述 LLDP数 据包的发送方类型为 0FC时， 新建或更新所述控制器列表表项， 新建或更新的 控制器列表表项包括所述 LLDP数据包中携带的所述本地 OFC的 MAC、 IP以 及收到所述 LLDP数据包的端口 in— port;
握手包单元， 用于获取用于建立 TCP连接的第一次 TCP握手包， 根据所 述 TCP握手包中携带的目的 MAC以及目的 IP查找所述控制器列表中是否有对 应的控制器列表表项， 如果有， 则根据所述控制器列表中对应的控制器列表表 项中的 MAC、 IP以及 in— port更新流表项，使得所述 0FS能够通过流表将发往 0FC的包转发到 0FC。
14、 如权利要求 13所述的 0FS， 其特征在于， 所述 0FS还包括： 数据包广播单元， 用于广播发送方类型为 0FC的所述 LLDP数据包， 使得 其他 0FS也能够接收所述 LLDP数据包，所述 LLDP数据包包含发送方的 MAC、 IP 以及用于标识发送方类型的角色子字段， 和， 当通过所述角色子字段判断接 收到的所述 LLDP数据包的发送方类型为 0FC时，新建或更新所述控制器列表 表项， 新建或更新的控制器列表表项包括所述 LLDP数据包中携带的所述本地 0FC的 MAC、 IP以及收到所述 LLDP数据包的端口 in— port。
15、 如权利要求 13所述的 0FS， 其特征在于， 所述角色子字段位于所述 LLDP数据包中的标签长度值 TLV字段。
16、 如权利要求 13所述的 0FS， 其特征在于，
所述数据包接收单元， 具体用于接收所述 LLDP数据包， 根据接收到的所 述 LLDP数据包查询所述流表产生 LLDP类型的 packet— in消息，并将所述 LLDP 类型的 packet— in消息发送到数据通道；
所述数据包处理单元， 具体用于从所述数据通道中获取 packet— in消息， 解 析所述 packet— in 消息， 判断所述 packet— in 消息是否是所述 LLDP 类型的 packet— in消息，
当所述 packet— in消息的是所述 LLDP类型的 packet— in 消息时， 从所述 LLDP类型的 packet— in消息中解析出所述 LLDP数据包， 并从所述 LLDP数据 包的 TLV字段中解析出所述角色子字段， 以及，
从所述 LLDP数据包的 TLV字段中解析出发送方的 MAC、 IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 0FS收到所述 LLDP数据包的端口 in— port,
查询所述控制器列表， 判断是否存在与解析得到的 MAC、 IP相匹配的控制 器列表表项， 如果不存在， 新建控制器列表表项以记录解析得到的 MAC、 IP、 in— port, 并设置预定的老化时间， 然后使用 packet— out消息将所述 LLDP数据 包 FLOOD; 如果存在，
判断与解析得到的 MAC、 IP相匹配的控制器列表表项中的 in— port是否与 解析得到的 in— port相同， 如果相同， 则将该控制器列表表项对应的老化时间重 置为预定的老化时间， 然后使用 packet— out消息将所述 LLDP数据包 FLOOD, 如果不同，
进一步判断该控制器列表表项对应的老化时间是否到达， 如果到达， 将该 控制器列表表项中的 in— port修改为解析得到的 in— port, 然后使用 packet— out 消息将所述 LLDP数据包 FLOOD, 如果未到达，
丟弃所述 LLDP数据包。
17、 如权利要求 13所述的 0FS， 其特征在于， 所述握手包单元包括： 第 一握手包模块和第二握手包模块；
所述第一握手包模块， 用于接收用于建立 TCP连接的第一次 TCP握手包， 解析所述第一次 TCP握手包得到目的 MAC和目的 IP，根据解析到的目的 MAC 和目的 IP查询所述流表， 产生 TCP类型的 packet— in消息， 并将所述 TCP类 型的 packet— in消息发送到数据通道；
所述第二握手包模块用于从所述数据通道中获取 packet— in消息，解析所述 packet— in消息， 判断所述 packet— in消息是否是所述 TCP类型的 packet— in消 息，
当所述 packet— in消息是所述 TCP类型的 packet— in消息时， 从所述 TCP 类型的 packet— in消息中解析出所述第一次 TCP握手包， 并从所述第一次 TCP 握手包中解析出源 MAC、 源 IP、 目的 MAC和目的 IP， 以及，
根据解析出的目的 MAC和目的 IP查询所述控制器列表， 判断是否存在与 解析出的目的 MAC和目的 IP相匹配的控制器列表表项， 如果存在， 生成第一 流表项和第二流表项， 并将所述第一流表项和第二流表项发送给所述第一握手 包模块， 所述第一流表项中记录源 MAC为解析出的源 MAC, 源 IP为解析出的 源 IP， 目的 MAC为解析出的目的 MAC， 目的 IP为解析出的目的 IP， 转发端 口为与解析出的目的 MAC和目的 IP相匹配的控制器列表表项中的 in— port, 所 述第二表项中记录源 MAC为解析出的目的 MAC, 源 IP为解析出的目的 IP， 目 的 MAC为解析出的源 MAC， 目的 IP为解析出的源 IP， 转发端口为所述 TCP 类型的 packet— in消息中的 in— port字段；
所述第一握手包模块， 还用于接收所述第一流表项和第二流表项， 并将所 述第一流表项和第二流表项添加至所述流表。
18、 如权利要求 17所述的 0FS， 其特征在于，
所述第二握手包模块， 还用于当所述控制器列表存在与解析出的目的 MAC 和目的 IP相匹配的控制器列表表项时，产生 packet-out消息，将所述 packet-out 消息发送给所述第一握手包模块， 所述 packet-out消息的执行动作 action字段 指向所述流表；
所述第一握手包模块， 还用于解析所述 packet-out消息， 得到其中的所述 第一次 TCP握手包，解析所述第一次 TCP握手包得到目的 MAC和目的 IP，根 据解析到的目的 MAC和目的 IP查询所述流表，找到与解析到的目的 MAC和目 的 IP相匹配的流表项， 根据该流表项中的转发端口转发所述第一次 TCP握手 包。
19、 如权利要求 17所述的 0FS， 其特征在于，
所述第二握手包模块， 还用于当所述控制器列表不存在与解析出的目的 MAC和目的 IP相匹配的表项时， 通过所述 0FS的管理端口发送所述 TCP类 型的 packet— in消息。
20、 如权利要求 13所述的 0FS， 其特征在于， 所述 0FS还包括： 第一流表项单元， 用于向所述流表中添加第一初始流表项， 所述第一初始 流表项的目的地址为 LLDP协议的组播地址， 协议类型为 LLDP协议的类型编 码， 转发端口指向 0FC， 数据包长度为全包长度， 优先级为最低。
21、 如权利要求 13所述的 0FS， 其特征在于， 所述 0FS还包括： 第二流表项单元， 用于向所述流表中添加第二初始流表项， 所述第二初始 流表项的目的地址为本地地址， 协议类型为 TCP协议的类型编码， 转发端口指 向所述 OFS的管理端口， 数据包长度为全包长度， 优先级为最低。
22、 如权利要求 13所述的 OFS， 其特征在于， 所述 OFS还包括： 邻居列表存储单元， 用于包括一个或多个邻居列表表项， 所述邻居列表表 项包括其他 OFS的 MAC、 IP 以及与所述其他 OFS的 MAC、 IP对应的所述 OFS接收所述其他 OFS发送的 LLDP数据包时的端口号；
所述数据包处理单元， 还用于当通过所述角色子字段判断接收到的所述 LLDP数据包的发送方类型为 OFS时，从所述 LLDP数据包的 TLV字段中解析 出发送方 MAC、 IP, 并从所述 LLDP类型的 packet— in消息中解析出所述 OFS 收到所述 LLDP数据包的端口 in— port, 以及，
查询所述邻居列表， 判断是否存在与解析得到的 MAC、 IP相匹配的邻居列 表表项， 如果不存在， 在所述邻居列表中新建邻居列表表项以记录解析得到的 MAC, IP和 in— port, 然后使用 packet— out消息将所述 LLDP数据包 FLOOD; 如果存在，
则判断与解析得到的 MAC、 IP相匹配的邻居列表表项对应的 in— port是否 与解析得到的 in— port相同， 如果相同， 使用 packet— out消息将所述 LLDP数 据包 FLOOD, 如果不同，
将该邻居列表表项对应的 in— port修改为解析得到的 in— port，然后丟弃所述 LLDP数据包。
23、 如权利要求 22所述的 0FS， 其特征在于， 所述 0FS还包括： 邻居列表发送单元， 用于将所述邻居列表发送至 0FC， 以供所述 0FC根 据邻居列表建立全网的网络拓朴， 以及，
当所述邻居列表改变时， 将改变后的邻居列表发送给所述 0FC， 以供所述 0FC根据改变后的邻居列表更新全网的网络拓朴。
24、如权利要求 13至 23任一项所述的 0FS， 其特征在于， 所述发往 0FC 的包既包括第三次 TCP握手包， 也包括其他 0FS发往所述 0FC的数据包。
PCT/CN2014/075602 2013-05-24 2014-04-17 一种ofs带内通信方法及ofs WO2014187204A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/949,506 US9832111B2 (en) 2013-05-24 2015-11-23 OFS in-band communication method and OFS

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310198601.3A CN103259728B (zh) 2013-05-24 2013-05-24 一种ofs带内通信方法及ofs
CN201310198601.3 2013-05-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/949,506 Continuation US9832111B2 (en) 2013-05-24 2015-11-23 OFS in-band communication method and OFS

Publications (1)

Publication Number Publication Date
WO2014187204A1 true WO2014187204A1 (zh) 2014-11-27

Family

ID=48963436

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/075602 WO2014187204A1 (zh) 2013-05-24 2014-04-17 一种ofs带内通信方法及ofs

Country Status (3)

Country Link
US (1) US9832111B2 (zh)
CN (1) CN103259728B (zh)
WO (1) WO2014187204A1 (zh)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9106515B2 (en) * 2012-10-22 2015-08-11 Futurewei Technologies, Inc. System and apparatus of a software-service-defined-network (SSDN)
CN103259728B (zh) * 2013-05-24 2016-03-30 华为技术有限公司 一种ofs带内通信方法及ofs
KR101571978B1 (ko) * 2013-08-28 2015-11-25 주식회사 케이티 멀티 플로우 그룹핑에 기반한 대역폭 제공 방법
CN104580025B (zh) * 2013-10-18 2018-12-14 华为技术有限公司 用于开放流网络中建立带内连接的方法和交换机
CN104734988B (zh) 2013-12-23 2018-10-30 杭州华为数字技术有限公司 软件定义网络中路由控制的方法和开放流控制器
CN104735001B (zh) * 2013-12-24 2019-11-05 中兴通讯股份有限公司 软件定义网络中的链路发现方法、装置及系统
CN104753695B (zh) * 2013-12-25 2018-11-30 上海宽带技术及应用工程研究中心 Sdn网络拓扑结构的发现及实时呈现系统及方法
US20150188731A1 (en) * 2013-12-27 2015-07-02 Daniel P. Daly Programmable Distributed Networking
CN104796336B (zh) * 2014-01-20 2018-06-19 华为技术有限公司 一种配置、下发流表项的方法及装置
CN103763207B (zh) * 2014-01-29 2017-03-15 杭州华三通信技术有限公司 软件定义网络中的带内控制连接建立方法及设备
CN105099919B (zh) * 2014-05-15 2018-07-31 华为技术有限公司 报文处理方法及装置
WO2015176257A1 (zh) 2014-05-21 2015-11-26 华为技术有限公司 OpenFlow设备与IP网络设备通信的方法、装置和系统
CN104038446B (zh) * 2014-06-06 2017-07-07 华为技术有限公司 链路发现方法以及装置
CN104283802A (zh) * 2014-10-09 2015-01-14 杭州华三通信技术有限公司 邻居发现方法和设备
US10250464B2 (en) * 2014-10-15 2019-04-02 Accedian Networks Inc. Area efficient traffic generator
CN105791237B (zh) * 2014-12-24 2020-05-08 中兴通讯股份有限公司 协议转化方法和装置
WO2016106742A1 (zh) * 2014-12-31 2016-07-07 华为技术有限公司 Openflow网络跨传统IP网络的拓扑学习方法和装置
CN105991606A (zh) * 2015-02-27 2016-10-05 中兴通讯股份有限公司 一种OpenFlow报文的处理方法及网元
CN104702509B (zh) * 2015-03-31 2019-02-19 新华三技术有限公司 一种隔离sdn协议报文和数据报文的方法及装置
US10567230B1 (en) * 2015-09-25 2020-02-18 Juniper Networks, Inc. Topology information for networks
US20180198704A1 (en) * 2015-09-25 2018-07-12 Hewlett Packard Enterprise Development Lp Pre-processing of data packets with network switch application -specific integrated circuit
US9967373B2 (en) * 2015-10-07 2018-05-08 The United States Of America As Represented By The Secretary Of The Army Test and training enabling architecture gateway implemented on a chip
CN105763463B (zh) * 2016-01-27 2020-01-03 新华三技术有限公司 一种链路探测报文的传输方法和装置
US9979693B2 (en) * 2016-01-28 2018-05-22 Fiber Logic Communications, Inc. IP allocation method for use in telecommunication network automatic construction
CN105871624B (zh) * 2016-05-24 2019-07-16 中国电子科技集团公司第三十研究所 不依赖于控制专网的动态sdn控制信令带内传输方法
CN107566277B (zh) * 2016-06-30 2020-09-25 华为技术有限公司 拓扑确定方法、消息响应方法、控制器以及交换机
US10931636B2 (en) * 2017-03-23 2021-02-23 Pismo Labs Technology Limited Method and system for restricting transmission of data traffic for devices with networking capabilities
CN108600107B (zh) * 2017-11-07 2021-06-01 北京交通大学 一种可自定义内容字段的流匹配方法
CN108616453B (zh) * 2018-04-20 2020-12-18 联想(北京)有限公司 一种用于网络设备的方法、装置和系统
CN108650126B (zh) * 2018-05-09 2021-04-23 华信塞姆（成都）科技有限公司 一种ptn网络中自动发现和配置带内dcn的方法
CN110611917B (zh) 2018-06-21 2021-03-05 华为技术有限公司 信息传输的方法及装置
CN108809767B (zh) * 2018-06-28 2020-09-15 新华三技术有限公司 Mac地址处理方法、设备和级联组网系统
CN109379292A (zh) * 2018-10-09 2019-02-22 郑州云海信息技术有限公司 一种组播方法、虚拟交换机、sdn控制器及存储介质
US11108641B2 (en) * 2019-02-01 2021-08-31 Dell Products L.P. Automatic switching fabric role determination system
US11303504B2 (en) 2020-06-09 2022-04-12 T-Mobile Usa, Inc. Data link error feedback signaling
CN113872783B (zh) * 2020-06-30 2023-08-22 华为技术有限公司 网络配置的方法、装置及计算机可读存储介质
US11637776B2 (en) * 2021-04-27 2023-04-25 Realtek Singapore Pte Ltd. Network device and packet replication method
CN114006872B (zh) * 2021-09-29 2023-08-04 苏州浪潮智能科技有限公司 数据包的传输方法、装置、电子设备及可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008187686A (ja) * 2007-01-31 2008-08-14 Nippon Telegr & Teleph Corp <Ntt> トンネル通信システム、制御装置およびトンネル通信装置
CN101394346A (zh) * 2007-09-21 2009-03-25 日本电气株式会社 网络系统、网络管理装置、通信装置以及路径设置方法
CN103259728A (zh) * 2013-05-24 2013-08-21 华为技术有限公司 一种ofs带内通信方法及ofs

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010020614A1 (de) 2010-05-14 2011-11-17 Friedrich-Alexander-Universität Erlangen-Nürnberg Endoskopiekapsel zum Nachweis eines Stoffwechselproduktes eines in oder an der Wand eines Hohlorgans des menschlichen oder tierischen Gastrointestinaltraktes befindlichen Erregers
US9467363B2 (en) * 2012-01-30 2016-10-11 Nec Corporation Network system and method of managing topology
CN102685006A (zh) * 2012-05-03 2012-09-19 中兴通讯股份有限公司 一种转发数据报文的方法及装置
CN102821009B (zh) * 2012-08-08 2015-01-28 中兴通讯股份有限公司 基于链路层发现协议监控环形网络的方法和装置
CN102946327B (zh) * 2012-11-30 2015-12-23 深圳市磊科实业有限公司 交换机管理系统的拓扑生成方法
US9374285B1 (en) * 2013-02-07 2016-06-21 Big Switch Networks, Inc. Systems and methods for determining network topologies
US9054976B2 (en) * 2013-02-27 2015-06-09 Moxa Inc. Network configuration system based on location and configuration method thereof
US9104643B2 (en) * 2013-03-15 2015-08-11 International Business Machines Corporation OpenFlow controller master-slave initialization protocol
CN104579968B (zh) 2013-10-26 2018-03-09 华为技术有限公司 Sdn交换机获取精确流表项方法及sdn交换机、控制器、系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008187686A (ja) * 2007-01-31 2008-08-14 Nippon Telegr & Teleph Corp <Ntt> トンネル通信システム、制御装置およびトンネル通信装置
CN101394346A (zh) * 2007-09-21 2009-03-25 日本电气株式会社 网络系统、网络管理装置、通信装置以及路径设置方法
CN103259728A (zh) * 2013-05-24 2013-08-21 华为技术有限公司 一种ofs带内通信方法及ofs

Also Published As

Publication number Publication date
CN103259728A (zh) 2013-08-21
US20160080254A1 (en) 2016-03-17
US9832111B2 (en) 2017-11-28
CN103259728B (zh) 2016-03-30

Similar Documents

Publication Publication Date Title
WO2014187204A1 (zh) 一种ofs带内通信方法及ofs
US11153274B2 (en) Method and device for storing and sending MAC address entry, and system
US9106443B2 (en) Forwarding table optimization with flow data
WO2015131486A1 (zh) 一种组播报文的转发方法及装置
US10361954B2 (en) Method and apparatus for processing modified packet
WO2012167697A1 (zh) 抑制网络风暴的方法及处理器
US9264327B2 (en) Communication network management system, method and program, and management computer
WO2012159481A1 (zh) 一种路径最大传输单元发现方法和节点
WO2015085740A1 (zh) 网络路径计算方法及装置
WO2013059991A1 (zh) 数据报文处理方法和系统、报文转发设备
WO2008031346A1 (fr) Procédé, appareil et système de classification de flux complexe de datagrammes fragmentés
WO2014183518A1 (zh) 一种实现数据包转发的方法及系统
WO2012152184A1 (zh) 多端口以太网接口装置及识别其端口的方法
WO2015172668A1 (zh) 网络中拥塞窗口的确定方法和装置
CN101247353A (zh) 流老化方法及网络设备
WO2011103759A1 (zh) 关联的双向标签交换路径的创建方法及系统
WO2012152186A1 (zh) 多端口以太网接口装置及其vpn业务接入的方法
WO2014198064A1 (zh) 一种处理报文的方法和转发器
CN102045250B (zh) Vpls中组播报文的转发方法和服务提供商边缘设备
WO2011127849A2 (zh) 一种数据流传送方法及网络设备
WO2015074423A1 (zh) 一种接入网关中数据报文的转发处理方法
EP2981036A1 (en) Multicast communication method and aggregation switch
WO2014169812A1 (zh) 报文的转发处理方法及装置
WO2011097859A1 (zh) 一种实现灵活qinq的方法及装置
WO2012075832A1 (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: 14801469

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

Country of ref document: EP

Kind code of ref document: A1