Realization method and system for enabling LLDP function on non-ethernet link

Abstract

The disclosure provides a realization method for enabling a Link Layer Discovery Protocol (LLDP) function on a non-Ethernet link, which includes: starting LLDP global enabling on a network device at an end and a network device at an opposite end respectively; starting LLDP port enabling on a non-Ethernet interface of the network device at the end and a non-Ethernet interface of the network device at the opposite end respectively. The disclosure further provides a realization system for enabling an LLDP function on a non-Ethernet link, correspondingly. The disclosure extends and improves the physical interface scope supported by an LLDP, and achieves the purpose of enabling the LLDP neighbor discovery function on the non-Ethernet link such as a POS interface by means of supporting usage of the LLDP on the interface such as the POS interface.

Claims

1. A realization method for enabling a Link Layer Discovery Protocol (LLDP) function on a non-Ethernet link, comprising: binding a Universal Logic Ether Interface (ULEI) up with a non-Ethernet interface of a network device at an end and a non-Ethernet interface of a network device at an opposite end respectively; starting LLDP global enabling on the network device at the end and the network device at the opposite end respectively; starting LLDP port enabling on the non-Ethernet interface of the network device at the end and the non-Ethernet interface of the network device at the opposite end respectively; packaging an LLDP hello message at the ULEI of the network device at the end when an interval time for sending a packet hello time of an LLDP is reached; sending the LLDP hello message over the non-Ethernet link to the network device at the opposite end; receiving, at the ULEI of the network device at the end, an LLDP hello message transmitted over the non-Ethernet link from the network device at the opposite end; and processing the LLDP hello message according to the LLDP to generate or update neighbour information.

2. The method according to claim 1, wherein the non-Ethernet interface is a Packet Over SONET/SDH (POS) interface, a High-Level Data Link Control (HDLC) interface, a Frame Relay (FR) interface, or an Asynchronous Transfer Mode (ATM) interface.

3. The method according to claim 1, further comprising: driving, by a timer, a sending state machine at a port to package an LLDP hello message when a set hello time is reached; if the port is the non-Ethernet interface, querying the ULEI bound up with the non-Ethernet interface; if the ULEI bound up with the non-Ethernet interface is not found, discarding the message; if the ULEI bound up with the non-Ethernet interface is found, replacing the non-Ethernet interface with the ULEI; encapsulating the LLDP hello message, and sending the encapsulated LLDP hello message to a rack at the opposite end via a microcode.

4. The method according to claim 3, further comprising: receiving, by a microcode of a rack at the end, the LLDP hello message from the rack at the opposite end; if the port which received the LLDP hello message is a ULEI, querying the non-Ethernet interface bound up with the ULEI; if the non-Ethernet interface bound up with the ULEI is not found, discarding the message; if the non-Ethernet interface bound up with the ULEI is found, replacing the ULEI with the non-Ethernet interface; analyzing the received LLDP hello message; generating or updating the neighbour information.

5. A realization system for enabling a Link Layer Discovery Protocol (LLDP) function on a non-Ethernet link, comprising a global enabling starting module and a port enable starting module, wherein: the global enabling starting module is configured to start LLDP global enabling on a network device at an end and a network device at an opposite end respectively; the port enable starting module is configured to start LLDP port enabling on a non-Ethernet interface of the network device at the end and a non-Ethernet interface of the network device at the opposite end respectively; an interface binding module, which is configured to bind a Universal Logic Ether Interface (ULEI) up with the non-Ethernet interface of the network device at the end and the non-Ethernet interface of the network device at the opposite end respectively; a message sending module, which is configured to package an LLDP hello message at the ULEI of the network device at the end when an interval time for sending a packet hello time of an LLDP is reached, and to send the LLDP hello message over the non-Ethernet link to the network device at the opposite end; a message receiving module, which is configured, at the ULEI of the network device at the end, to receive an LLDP hello message transmitted over the non-Ethernet link from the network device at the opposite end, and to process the LLDP hello message according to the LLDP to generate or update neighbour information.

6. The system according to claim 5, further comprising an aging module, which is configured to periodically cause the LLDP neighbour information, which is not updated before timeout, to age.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a flowchart of a realization method according to an embodiment of the disclosure;

(2) FIG. 2 is a networking diagram of a realization method according to an embodiment of the disclosure;

(3) FIG. 3 is a structural diagram of a realization system according to an embodiment of the disclosure;

(4) FIG. 4 is a flowchart of sending a packet by using the disclosure;

(5) FIG. 5 is a flowchart of receiving a packet by using the disclosure; and

(6) FIG. 6 is a structural diagram of message encapsulation by using the disclosure.

DETAILED DESCRIPTION

(7) To make purposes, solutions, and advantages of the disclosure clearer, embodiments will be described in detail with reference to the drawings. It should be noted that embodiments and features thereof in the disclosure may be combined with each other if not conflicting.

(8) It should be noted that solutions of the disclosure may be used to enable an LLDP function on a non-Ethernet link WAN such as POS, High-Level Data Link Control (HDLC), Frame Relay (FR) and Asynchronous Transfer Mode (ATM) interfaces. Hereinafter, embodiments will be described by taking the POS interface as an example.

(9) FIG. 1 is a flowchart of a realization method according to an embodiment of the disclosure. As shown in FIG. 1, the method includes the following steps.

(10) Step 101: a physical connection between a POS interface of a network device at an end and a POS interface of a network device at an opposite end is established. In this embodiment, the physical connection is established through optical fibres.

(11) Step 102: each of the POS interface of the network device at the end and the POS interface of the network device at the opposite end is assigned an IP address.

(12) Step 103: it is determined that the physical link is connected between the POS interface of the network device at the end and the POS interface of the network device at the opposite end through a Packet Internet Grope (ping) command.

(13) Step 104: each of the POS interface of the network device at the end and the POS interface of the network device at the opposite end is bound up with a ULEI.

(14) This step may be omitted. The purpose of this step is to take full advantage of conventional ULEI technology and improve efficiency of packet transmission through conversion of interfaces.

(15) Step 105: LLDP globe enabling is started on the network device at the end and the network device at the opposite end, respectively.

(16) Step 106: LLDP port enabling is started on the POS interface of the network device at the end and the POS interface of the network device at the opposite end, respectively.

(17) Step 107: when hello time set by a timer is reached, an LLDP hello message is, by the network device at the end, packaged at the POS interface of the network device at the end (including an Ethernet interface and a non-Ethernet interface).

(18) Specifically, the timer is used, according to the preset hello time, to drive a sending state machine at the network device's port to package the LLDP hello message.

(19) Step 108: the network device at the end sends the LLDP hello message to the network device at the opposite end.

(20) Step 109: the network device at the opposite end receives the message and processes it according to an LLDP to generate or update neighbour information.

(21) The above steps 107 to 109 describe that the network device at the end sends the LLDP hello message to the network device at the opposite end. Similarly, when hello time set by a timer is reached, an LLDP hello message may also be packaged by the network device at the opposite end at a port thereof, and be sent to the network device at the end; the network device at the end processes the received LLDP hello message according to the LLDP to generate or update neighbour information.

(22) In this embodiment, necessary configuration parameters and performance parameters for networking performance are configured according to a Management Information Base (MIB) of Operation Administration and Maintenance (OAM) or a Simple Network Management Protocol (SNMP), and this configuration may be displayed, in which the configured parameters mainly include:

(23) IP addresses respectively assigned to a non-Ethernet interface of the network device at the end and a non-Ethernet interface of the network device at the opposite end;

(24) global LLDP function enabling or disabling of network devices;

(25) interval time for global LLDP sending packet of network devices;

(26) holding time for global LLDP neighbours of network devices;

(27) the maximum number of global LLDP neighbours of network devices;

(28) LLDP function enabling or disabling of POS interfaces of network devices; and

(29) the maximum number of LLDP neighbours of POS interfaces of network devices.

(30) FIG. 2 is a networking diagram of a realization method according to an embodiment of the disclosure. In FIG. 2, RX and TX respectively indicate receiving and transmitting. As shown in FIG. 2, pos192-0/1/0/1 in router 1 is connected with pos192-0/2/0/2 in router 2. Messages are transmitted between the router 1 and the router 2 through optical fibres. The router 1 and the router 2 generate neighbour information respectively.

(31) FIG. 3 is a structural diagram of a realization system according to an embodiment of the disclosure. As shown in FIG. 3, the system for enabling an LLDP function on a non-Ethernet link includes: a global enabling starting module, a port enabling starting module, an interface binding module, a message sending module, a message receiving module and an aging module.

(32) The global enabling starting module is configured to respectively start LLDP global enabling on a network device at an end and a network device at an opposite end.

(33) The port enabling starting module is configured to respectively start LLDP port enabling on a non-Ethernet interface of the network device at the end and a non-Ethernet interface of the network device at the opposite end.

(34) The interface binding module is configured to bind an ULEI up with the non-Ethernet interface of the network device at the end and the non-Ethernet interface of the network device at the opposite end, respectively.

(35) The message sending module is configured to package an LLDP hello message on a port of the network device at the end when hello time set by a timer is reached, and to send the LLDP hello message to the network device at the opposite end. Specifically, the timer is used, according to the preset hello time, to drive a sending state machine at the network device's port to package the LLDP hello message.

(36) The message receiving module is configured to receive the LLDP hello message from the network device at the opposite end on the network device at the end, and to process the LLDP hello message according to an LLDP to generate or update neighbour information.

(37) The aging module is configured to periodically cause the LLDP neighbour information, which is not updated before timeout, to age.

(38) Specifically, the aging module is configured to traverse the LLDP neighbour information in a polling manner when the time set by an aging timer times out; and to delete the LLDP neighbour information which has timed out, when aging time of the LLDP neighbour information times out.

(39) Solutions of the disclosure enable the LLDP function on the non-Ethernet link such as a POS interface of a network device in a Command Line (CML) manner.

(40) Certainly, the above “an/the end” and “an/the opposite end” are relative concepts, if one side indicates “an/the end”, the other side will indicates “an/the opposite end”.

(41) FIG. 4 is a flowchart for sending a packet by using the disclosure. As shown in FIG. 4, the process of sending a packet includes the following steps.

(42) Step 401: a timer runs up to preset hello time.

(43) Step 402: the timer drives a sending state machine at a port (i.e., a TX state machine at an LLDP port) to package an LLDP hello message.

(44) Step 403: after packaging the LLDP hello message, it is determined that the port is an Ethernet physical port or a non-Ethernet interface such as a POS interface before sending the message, since the LLDP hello message needs to be sent by a specified port; if the port is the Ethernet physical port, step 406 is executed; if the port is the non-Ethernet interface such as the POS interface, step 404 is executed.

(45) Step 404: different operations are performed based on whether or not the non-Ethernet interface such as the POS interface is bound up with the ULEI; if the non-Ethernet interface such as the POS interface is bound up with the ULEI, step 405 is executed; if the non-Ethernet interface such as the POS interface is not bound up with the ULEI, step 407 is executed.

(46) Step 405: if the ULEI bound up with the non-Ethernet interface such as the POS interface is found, the non-Ethernet interface such as the POS interface is replaced with the ULEI.

(47) Step 406: a packet is sent via a packet transmitting interface, and step 408 is executed.

(48) Step 407: if the ULEI bound up with the non-Ethernet interface such as the POS interface is not found, the message is discarded, and the process ends.

(49) Step 408: a packet receiving and transmitting module (i.e., packet receiving and transmitting LPP) defined in the LLDP receives an LLDP Ethernet message; if it is needed for the non-Ethernet interface such as the POS interface to encapsulate the packet as a PPP Bridging Control Protocol (BCP) message defined in an IEEE 802.3/Ethernet protocol; the encapsulating manner is shown in FIG. 6.

(50) Step 409: the message is sent to a rack at an opposite end.

(51) FIG. 5 is a flowchart of receiving a packet by using the disclosure. As shown in FIG. 5, the process of receiving a packet includes the following steps.

(52) Step 501: a rack at an end receives an LLDP hello message from a rack at an opposite end, determines that the message is a BCP message defined in an IEEE 802. 3/Ethernet protocol, and determines that the message is an LLDP hello message according to a target Media Access Control (MAC) in the message, then removes the encapsulation of the BCP message and uploads the message to a packet receiving and transmitting module defined in an LLDP from a ULEI, in which the message is in the form of Ethernet. If an interface BCP negotiation state is focused in original heterogeneous process, it needs to be skipped specifically. The BCP negotiation is not focused when the LLDP hello message is uploaded, the LLDP hello message is uploaded due to interface protocol UP. The protocol UP may be successful IPCP negotiation and is not necessarily successful BCP negotiation. The protocol UP may be any successful negotiation and switch is not needed.

(53) Step 502: after the packet receiving and transmitting module defined in the LLDP receives the LLDP Ethernet message, information including ULEI is distributed to an LLDP service module defined in the LLDP.

(54) Step 503: it is determined that the physical type of an interface receiving the message is an Ethernet physical interface, and then step 506 is executed; it is determined that the physical type of an interface receiving the message is a ULEI, and then step 504 is executed.

(55) Step 504: a non-Ethernet interface such as a POS interface bound up with the ULEI is queried and found, and then step 505 is executed; otherwise, step 507 is executed.

(56) Step 505: if the non-Ethernet interface such as the POS interface bound up with the ULEI is found, the ULEI is replaced with the non-Ethernet interface such as the POS interface.

(57) Step 506: the LLDP service module analyzes the received LLDP hello message, if there are errors in the received LLDP hello message, step 507 is executed; otherwise step 508 is executed.

(58) Step 507: if the non-Ethernet interface such as the POS interface bound up with the ULEI is not found, or if there are errors in the received LLDP hello message, the message is discarded, and the process ends.

(59) Step 508: a receiving state machine (i. e., an RX state machine at an LLDP port) is driven through the message received via the port so as to add, update or delete LLDP neighbour information, and the process ends.

(60) Step 509: a timer drives neighbour aging scanning of the LLDP.

(61) Step 510: neighbour information, which is not updated before timeout, of LLDP neighbours is deleted.

(62) Step 511: the process ends.

(63) The above embodiments by taking the non-Ethernet interface such as the POS interface bound up with the ULIE interface as an example. If the non-Ethernet interface such as the POS interface is not bound up with the ULIE, the network device at the end may directly analyze the LLDP message received from the network device at the opposite end.

(64) FIG. 6 is a structural diagram of message encapsulation by using the disclosure. The message format of LLDP encapsulated by a BCP message is shown in FIG. 6. 802.3 Frame in RFC 2878 is reused, options which should be specified are as follows.

(65) Address and Control, this field is filled with 0XFF03;

(66) PPP Protocol, this field is filled with 0x0031;

(67) If F bit in Flags does not indicate LAN fragment, this field is filled with 0;

(68) Z bit in Flags is filled with 0;

(69) Pads, this field is filled with 0;

(70) MAC Type should follow IEEE 802.3/Ethernet, this field is filled with 1; and

(71) Optional Data Link Layer Padding, this field is omitted in the message.

(72) The above embodiments are described by taking the POS interface as an example. Method for enabling LLDP function on other non-Ethernet interface such as HDLC, FR and ATM can be determined by the analysis, which will not be further elaborated.

(73) In view of the above, the disclosure provides a method for enabling LLDP function on non-Ethernet link such as the POS interface based on LLDP, extends and improves the physical interface scope supported by LLDP, and achieves the purpose of enabling LLDP neighbour discovery function on non-Ethernet link such as POS be means of supporting usage of LLDP on interface such as POS.

(74) The person skilled in the art should appreciate that a part or all of the steps in the above method may be achieved through related hardware instructed by a program. The program may be stored in a computer readable storage medium, such as ROM, disk or CD. Optionally, a part or all of the steps in the above embodiments may be achieved by one or more integrated circuit. Accordingly, each module/unit in the above embodiments may be achieved in the form of hardware or software function modules. The disclosure is not limited to any specific form of combination of hardware and software.

(75) Certainly, the disclosure may have wide variety of possible embodiments. The person skilled in the art may make changes or modifications on the disclosure without departure of spirit and protection scope of the disclosure, these changes or modifications still fall into the protection scope of the appended claims.