CN104320347A

CN104320347A - Method and device for initiatively updating LLDP

Info

Publication number: CN104320347A
Application number: CN201410606724.0A
Authority: CN
Inventors: 徐鹏飞
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: Hangzhou H3C Technologies Co Ltd
Priority date: 2014-10-31
Filing date: 2014-10-31
Publication date: 2015-01-28
Anticipated expiration: 2034-10-31
Also published as: CN104320347B

Abstract

The invention discloses a method and device for initiatively updating an LLDP. The method includes the steps of initiatively sending an LLDP message with an updated TLV to a neighbor, prompting the neighbor to send the carried TLV to be updated, analyzing the received updated TLV, and updating local neighbor information according to carried TLV information. According to the method and device, a mechanism of initiatively updating the requested TLV through the LLDP is realized, under the condition that the LLDP supports various expanding applications such as PoE consultation, EEE consultation and DCBX consultation, the requirement for initiative and rapid updating can be met, the fast interaction effect is achieved, and the consultation efficiency is accordingly improved.

Description

Method and device for actively updating LLDP

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method and a device for actively updating an LLDP.

Background

LLDP (Link Layer Discovery Protocol) belongs to a slow unidirectional information notification Protocol, and notifies device and port information to directly connected peripheral devices by periodically sending local information, and simultaneously monitors the device and port information periodically sent by the peripheral devices, and establishes a neighbor database for a network manager and an application module to query.

Because the sending of the LLDP message is triggered only by the timing mechanism in the current stable state, when a certain device wants to update the neighbor information immediately, the sending cannot be realized, and only the next packet sending period of the neighbor can be waited, and then the neighbor information is updated by the latest message sent by the device.

Disclosure of Invention

The application provides a method for actively updating LLDP, which comprises the following steps:

actively sending an LLDP message carrying an update TLV (Type-length-value) to a neighbor, wherein the update TLV carries a TLV list to be updated;

receiving an LLDP message of an updated TLV sent by a neighbor, wherein the updated TLV at least carries TLV information in a list to be updated;

and analyzing the received updated TLV, and updating local neighbor information according to TLV information carried by the TLV.

The update TLV includes a reqorrep field for indicating that it requires a neighbor update TLV when the reqorrep value is 0.

The updating TLV comprises a field BasiclTLVNum and a field BasiclTLVTypeList, and is used for defining the number and the list of basic TLVs to be updated.

The update TLV further includes a field OrgTLVNum and a field OrgTLVTypeList for defining the number and list of organization-specific TLVs to be updated.

In order to cooperate with the foregoing manner, the present application further provides a method for initiatively updating an LLDP, including the following steps:

receiving an actively-sent LLDP message from a neighbor device, wherein the message carries a TLV list to be updated;

analyzing the received LLDP message, extracting the TLV list to be updated, immediately collecting the related information of the local TLV, and organizing the LLDP message transmission at least carrying the TLV information in the TLV list to be updated.

The transmitted LLDP message carries complete local TLV information, including TLV information required in the update TLV and other TLV information not listed in the update TLV; or,

the sent LLDP message carries an update TLV, and the update TLV carries an updated TLV list corresponding to the TLV list to be updated.

The update TLV includes a reqorrep field for indicating a response update TLV when the reqorrep value is 1.

Based on the same idea, the application also provides a device for actively updating the LLDP, which includes the following modules:

the request module actively sends an LLDP message carrying an updated TLV to a neighbor, wherein the updated TLV carries a TLV list to be updated;

the receiving module is used for receiving an LLDP message of an updated TLV sent by a neighbor, wherein the updated TLV at least carries TLV information in a list to be updated;

and the processing module analyzes the received updated TLV and updates the local neighbor information according to the TLV information carried by the TLV.

In order to cooperate with the above device, the present application further provides a device for actively updating LLDP, which includes the following modules:

According to the method and the device, the TLV of the LLDP active update request is realized, and under the condition that the existing TLV of the LLDP is used as a negotiation communication mechanism, for example, under various extended application scenes that the LLDP supports PoE negotiation, EEE negotiation, DCBX negotiation and the like, the requirement of active quick update can be met, the quick interaction effect is achieved, and the negotiation efficiency is improved.

Drawings

Fig. 1 is a scenario in which the embodiments provided herein are applicable.

Fig. 2 is a hardware implementation of the embodiments provided in the present application.

Fig. 3 is another hardware implementation of the embodiments provided herein.

Fig. 4 is a flowchart of an implementation of the embodiments provided herein.

Fig. 5 is a flowchart of another implementation of the embodiments provided herein.

Detailed Description

The application provides a scheme for actively updating the LLDP, and the solution solves the problem of actively updating the LLDP by adding a new TLV of the LLDP. For example, when a device needs to acquire the latest device state of a neighbor device, in the existing technical solution, it is only necessary to wait for an LLDP packet sending period to arrive, and the solution of the present application can provide an on-demand request mechanism, so that a network device can actively request the neighbor device to send an update LLDP and update neighbor information at any time when needed, thereby fully playing the device performance and providing a good network application service.

In one example, fig. 1 illustrates a typical network architecture required for the solution of the present application to operate. The network architecture shown in FIG. 1 includes network device SW11, network device SW 13. The network device is a device at any position in the network, and may be an access layer switch, a convergence layer switch, a router, and the like, and as long as the application of the LLDP protocol is concerned, the solution of the present application may be applied. In the example given in this application, an LLDP neighbor is established between SW11 and SW 13.

Referring to fig. 2, the network device SW11 includes a processor 111, a memory 112, a non-volatile memory 113, and a network interface 114, wherein the processor 111, the memory 112, the non-volatile memory 113, and the network interface 114 are connected via an internal bus 115. The processor 111 of the network device SW11 reads computer instructions of the LLDP update control logic from the non-volatile memory 111 into the memory for execution. In the same principle, referring to fig. 3, the network device SW13 includes a processor 131, a memory 132, a nonvolatile memory 133, and a network interface 134, wherein the processor 131, the memory 132, the nonvolatile memory 133, and the network interface 134 are connected via an internal bus 135. Processor 131 of network device SW13 reads computer instructions from non-volatile storage 133 to the memory for execution of the LLDP response update control logic.

Referring to fig. 4, the LLDP update control logic running on the network device SW11 includes a request module and a processing module, and under the cooperation of the above modules, the LLDP update control logic performs the following processing flow:

step 41, the request module actively sends an LLDP message carrying an update TLV to the neighbor, for requesting the neighbor of the opposite end to update the neighbor information, where the update TLV carries a TLV list to be updated.

And 43, the processing module receives the LLDP message carrying the updated TLV sent by the neighbor, wherein the updated TLV at least carries TLV information in the list to be updated.

And step 45, the processing module analyzes the received updated TLV and updates the local neighbor information according to the TLV information carried by the processing module.

In step 41, the network device SW11 sends an LLDP packet to the neighbor, where the LLDP packet carries an update TLV, the update TLV carries a field indicating that the packet is a neighbor update request TLV, and the neighbor network device is requested to send TLV information according to TLV information in the list to be updated.

In step 43, the network device SW11 receives the update TLV sent from the neighbor network device, where at least the TLV information in the list to be updated is carried, and here, the update TLV returned by the neighbor network device may carry complete TLV information including the TLV to be updated, or may only carry the TLV information to be updated.

Referring to fig. 5, the LLDP response update control logic running on the network device SW13 includes a receiving module and a processing module, and under the cooperation of the receiving module and the processing module, the LLDP response update control logic performs the following processing flow:

and step 51, the receiving module receives an actively sent LLDP message from the neighbor device, wherein the message carries a TLV list to be updated.

And 53, analyzing the received LLDP message by the processing module, extracting a TLV list to be updated, immediately collecting the related information of the local TLV, and organizing the LLDP message carrying the updated TLV to be sent.

In step 51, the network device SW13 receives the LLDP packet carrying the update TLV from the neighbor network device SW11, where the LLDP packet carries the list of TLVs to be updated, and is used to inform the network device SW13 that at least the TLV information in the list to be updated needs to be provided for the network device SW11, and for the network device SW13 that receives the LLDP, the TLV information requested in the update TLV or all local TLV information including the TLV information requested in the update TLV may be provided for the neighbor network device SW 11.

The interworking process between network device SW11 and neighbor network device SW13 is illustrated by a more detailed embodiment below in connection with the networking of FIG. 1.

In this embodiment, a new TLV is defined, which may be a basic TLV or an organization-customized TLV, called update TLV (update TLV). The meaning of this TLV is to request neighbors to update the published TLV type (including basic TLVs and organizational custom TLVs) manifest immediately.

If a method of adding a basic TLV is adopted, the definition and value of the UPDATE TLV format can be designed as follows (similar to the principle of organizing a custom TLV, which is only exemplified in the basic TLV manner in this application):

TABLE 1

Field Type

The Type value is fixed to 124. (organization custom TLVs are assigned internally by the organization)

Length field

Length indicates the Length of data following the Length, and does not contain the Type and Length fields.

Field reqOrResp

The value may be REQ (0), which indicates a request update, or RESP (1), which indicates a response to a request update.

Field basicltlvnum

Indicating the number N of basic TLV types that require immediate updating, which may be 0.

Field basicltlvtypelist

N bytes, each byte corresponds to Type (7bits) of a basic TLV, and the last bit is reserved. This field does not exist when basicltlvnum is 0.

Field OrgTLVNum

The number of organization custom TLV types M, which may be 0, indicating that immediate updates are required.

The field OrgTLVTypelist

M4 bytes, every 4 bytes corresponds to an OUI (3octets) plus Subtype (1octets) organizing the custom TLV. This field does not exist when OrgTLVNum is 0.

The field part is optional, if the field part is of a basic TLV type, the field OrgTLVNum is optional, and if the field part is of an organization custom TLV type, the field BasiclTLVNum is optional, and a user can decide whether to use or keep the field according to own needs.

In an embodiment of the present application, when an LLDP device supporting the present application, for example, the network device SW11, needs its neighbor network device SW13 to update some information immediately, an LLDP message sent by it carries an update TLV in addition to local latest information, where reqorrep fills out REQ (0) to indicate that it requires neighbor update TLV. The updating TLVs carry a list of TLVs to be updated, see Table 1, the number and the list of basic TLVs to be updated are defined by a field BasiclTLVNum and a field BasiclTLVTypeList, and the number and the list of organization self-defined TLVs to be updated are defined by a field OrgtTLVNum and a field OrgtTLVTypeList. The location of the update TLV may occur anywhere after the first three mandatory TLVs, as required by the protocol.

After receiving the LLDP message with the UPDATE TLV, the neighbor network device SW13 supporting the UPDATE TLV parses the TLV, extracts the TLV list to be updated when reqorrep is REQ (0), immediately collects the relevant information of the local TLV, assembles the LLDP message carrying the TLV responding to the UPDATE, and sends the LLDP message.

When the neighbor network device SW13 sends the LLDP packet of the update TLV, two modes of complete sending and update sending may be adopted. The complete sending is carried with all local TLV information to be issued, including TLV information required in the UPDATE TLV and other TLV information not listed in the UPDATE TLV; the UPDATE sending refers to sending only the information of the requested TLV in the UPDATE TLV, and an UPDATE TLV needs to be additionally carried during UPDATE sending, wherein ReqOrResp is filled in as RESP (1), and a TLV list updated this time is filled in, which indicates that the message is the UPDATE sending of the last UPDATE request, but not a common complete sending message. Since the UPDATE transmission is in response to the UPDATE TLV, it is guaranteed that the recipient network device SW13 of the message is certain to be supporting the present application.

The basic TLV requiring updating and/or the organization custom TLV filled in the UPDATE TLV should be a TLV range allowed to be issued in the neighbor network device SW13, if a TLV that is not allowed to be issued by the neighbor network device SW13 is requested, the neighbor network device SW13 ignores the TLV updating request, and the updating requests of other TLVs are processed normally.

When receiving the LLDP message with the UPDATE TLV with ReqOrResp as RESP (1), the SW13 analyzes the LLDP message into the updated and sent LLDP message, UPDATEs the information according to the TLV list carried by the LLDP message, and does not UPDATE the content in the TLV which is not in the list. And the old version of LLDP equipment receives the data carried by the UPDATE TLV and processes the data as the unidentifiable TLV.

According to the method and the device, a mechanism that the LLDP actively updates the request TLV is realized, and the effect of quick interaction can be achieved under various extended application scenes that the LLDP supports PoE negotiation, EEE negotiation, DCBX negotiation and the like, so that the negotiation efficiency is improved.

The above description is only a preferred example of the present disclosure and should not be taken as limiting the scope of the claims, which are intended to be covered by the appended claims.

Claims

1. A method for LLDP active update, comprising the steps of:

actively sending an LLDP message carrying an updating TLV to a neighbor, wherein the updating TLV carries a TLV list to be updated;

2. The method of claim 1, wherein the update TLV includes a reqorrep field to indicate that it requires a neighbor update TLV when the reqorrep value is 0.

3. The method of claim 1, wherein fields basiclvnum and basiclvtypelist are included in the update TLV to define the number and list of basic TLVs to be updated;

4. A method for LLDP active update, comprising the steps of:

5. The method of claim 4, wherein the transmitted LLDP packet carries complete local TLV information, including TLV information required in the update TLV and other TLV information not listed in the update TLV; or,

6. The method of claim 5, wherein the update TLV includes a ReqOrResp field to indicate a response update TLV when the ReqOrResp value is 1.

7. An apparatus for LLDP proactive update, comprising the following modules:

8. The apparatus of claim 7, wherein the update TLV comprises a ReqOrResp field to indicate that it requires a neighbor update TLV when the ReqOrResp value is 0.

9. The apparatus of claim 7, wherein fields basiclvnum and basiclvtypelist are included in the update TLV to define a number and list of basic TLVs to be updated;

10. An apparatus for LLDP proactive update, comprising the following modules: