Remote Neighbor Relationship

BACKGROUND A Label Distributing Protocol LDP, as a basic protocol of

Multiprotocol Label Switching MPLS is widely used in such fields as operators.

A LDP peer discovery mechanism includes two types:

Basic discovery mechanism, which is used for discovering local LDP peers, i.e. through a Label Switch Router LSR directly connected to a link layer. In this manner, the LSR periodically sends a LDP link Hello message to the multicast address 224.0.0.2 of "all routers within a subnet", so that the LSR directly connected to the link layer can discover said LDP peers.

Extension discovery mechanism, which is used for discovering remote LDP peers, i.e. not through a Label Switch Router LSR directly connected to a link layer. In this manner, the LSR periodically sends an LDP target Hello message to a specified IP address, so that the LSR corresponding to said specified IP address can discover said remote LDP peers.

Extension discovery mechanism is extensively used in such networking as Virtual Private Network L2VPN to realize communication of information (e.g. information carrying L2VPN) among remote Provider Edge PE devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate various examples of various aspects of the present disclosure. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. It will be appreciated that in some examples one element may be designed as multiple elements or that multiple elements may be designed as one element. In some examples, an element shown as an internal component of another element may be implemented as an external component and vice versa.

Fig. 1 is a schematic drawing of network architecture according to an example;

Fig. 2 is a flow chart of a method for establishing a LDP remote neighbor relationship according to a first example;

Fig. 3 is a flow chart of a method for determining a root node for starting to calculate the number of forwarding hops according to a destination address;

Figs. 4A, 4B and 4C are flow charts for performing reverse Time To

Live TTL calculation respectively for the flow chart of Fig. 2;

Fig. 5 is a flow chart of processing of an LDP proxy device according to an example;

Fig. 6 is a schematic drawing of a flow chart of updating a proxy table according to a second example;

Fig. 7 is a schematic drawing of a specific application scenario according to an example;

Fig. 8 is a structural schematic drawing of a router according to an example; and

Fig. 9 is a structural schematic drawing of a server according to an example.

DETAILED DESCRIPTION

As used herein, the term "includes" means includes but not limited to, the term "including" means including but not limited to. The term "based on" means based at least in part on. In addition, the terms "a" and "an" are intended to denote at least one of a particular element.

In a process of establishing a LDP remote neighbor relationship, after a network device receives an LDP message, it usually verifies whether said LDP message is valid or not based on whether or not the TTL is reasonable.

The reasonableness of the TTL is mainly determined by judging a distance between a peer side device and a local side device, the distance herein refers to the number of forwarding hops. To this end, the present disclosure provides a mechanism to verify validity of an LDP message through precisely determining a distance between a peer side device and a local side device and thereby establishing a LDP remote neighbor relationship according to validity of the LDP message. Said mechanism can be applied to a service flow in which the network device needs to verify the validity of the received LDP message. For example, in an extension discovery mechanism, a local side LSR needs to verify, after receiving an LDP Target Hello message (LDP target discovery message) sent by a peer side LSR, validity of said message, i.e. judging whether the distance between the local side LSR and the peer side LSR is reasonable and establishing an LDP neighbor relationship with the peer side LSR after passing the verification.

The present disclosure can be applied to a situation in which Interior Gateway Protocol IGP is an Open Shortest Path First OSPF protocol and it achieve the above-mentioned object through extending the LDP protocol and the OSPF protocol.

In the following, certain examples are described in detail with reference to the drawings.

With the reference to Fig. 1 , Fig. 1 is a schematic drawing of network architecture according to an example. As shown in Fig. 1 , Area 0 is a core area and Areas 1-4 are branch areas.

By extending the LDP protocol and OSPF protocol, routers in the branch areas can obtain distances from peer side routers to themselves through a reverse TTL calculation. In order to support an inter-area reverse TTL calculation, LDP proxy devices need to be deployed in each of the areas. Like common remote LDP neighbors, LDP proxy devices establish neighbor relationship through a Transmission Control Protocol TCP. If there is only proxy capability but no common remote neighbor relationship between two routers, then after establishing the neighbor relationship, no other information than the proxy request or response information related to reverse TTL calculation will be transmitted between neighbors. Wherein, the LDP proxy devices deployed in the branch areas are called area LDP proxy devices (hereinafter referred to as area proxies), and LDP proxy devices deployed in the core area are called core area LDP proxy devices (hereinafter referred to as core area proxies). One branch area may include one or more area proxies, if more than one area proxies are deployed, load balancing may be performed among the area proxies. An area proxy is mainly used for initiating a request to the core area proxy to request the core area proxy to calculate the number of hops upon receiving a proxy request for performing reverse TTL calculation initiated by a router within said area; a core area proxy is mainly used for determining a target area proxy for performing reverse Area Border Router ABR TTL calculation based on the request from the area proxy, and a core area proxy can also perform reverse TTL calculation upon determining that the target area is the core area where it is located.

After establishing a neighbor relationship between the core area proxy and each of the area proxies, ABRs corresponding to interface addresses of the area proxies need to be configured. Specifically, a routing corresponding to an area proxy may be looked for according to a longest matching algorithm, and the ABR corresponding to said routing is the ABR of said area proxy.

In the routers in the above-mentioned networking (including routers having an LDP proxy function or not having an LDP proxy function ), operations relating to process LDP protocol message and to initiate the proxy request for performing reverse TTL calculation and receive a response to said proxy request are performed by LDP application modules or LDP processes (hereinafter referred to as LDP modules) in the routers; operations of reverse TTL calculation or reverse ABR TTL calculation are performed by OSPF application modules or OSPF processes (hereinafter referred to as OSPF modules) in the routers.

Based on the network architecture shown in Fig. 1 , Fig. 2 is a flow chart of establishing a LDP remote neighbor relationship according to the first example. Said flow chart illustrates that after LSR1 sends a LDP Target Hello message to LSR2, LSR2 verifies validity of said message and performs the corresponding processing according to the result of verification. As shown in the figure 2, said flow chart may include the following blocks:

At block 201 , after LSR2 receives the LDP Target Hello message sent by LSR1 , an LDP module of LSR2 sends a request, carrying a source address and a destination address, for obtaining the number of forwarding hops to an OSPF module of LSR2, wherein, the source address refers to the address of LSR2 and the destination address refers to the source address of the LDP Target Hello message (i.e. the address of LSR1) in the example unless otherwise indicated.

At block 202, the OSPF module inquires an OSPF routing table according to the destination address, and searches for matching routings according to the longest matching algorithm ; if no matching routing is found, proceed to block 203; if a matching routing is found, proceed to block 204.

At block 203, the OSPF module returns a failure response to the LDP module to indicate that the destination address is unreachable, said failure response specifically includes a source address (i.e. address of LSR2), a destination address (i.e. address of LSR1), reachable flag, distance, etc. The reachable flag is set to be unreachable, and proceed to block 21 1.

At block 204, the OSPF module determines type of the routing found, if type of the routing is intra-area routing, proceed to block 205; if type of the routing is inter-area routing, proceed to block 206; if type of the routing is external routing, proceed to block 207.

At block 205, the OSPF module determines a root node for starting to calculate the number of forwarding hops according to the destination address in an area corresponding to the intra-area routing, calculates the number of forwarding hops from said root node to LSR2 (this process of calculation is called reverse TTL calculation process in the example), and proceed to block 208 after obtaining a calculation result. Wherein the calculation result may include the number of forwarding hops from said root node to LSR2 or a range of the number of forwarding hops (including a lower limit and an upper limit of the number of hops), it may also include such information as creditability flag.

Specifically, reference can be made to Fig. 3 and its illustrations for a process of determining the root node for starting to calculate the number of forwarding hops by LSR2 according to the destination address at this block 205.

The reverse TTL calculation process in this block 205 may include: performing SPF calculation using the determined root node as a starting point until the local side router (i.e. LSR2) enters a SPF tree, thereby calculating the number of hops H from the root node to the local side router (i.e. LSR2). In this process, starting from the root node (which is not counted in), the number increments by one each time a node is passed until reaching the local side router (which also serves as a node and is counted in). If there are multiple paths to the local side router in the SPF tree, a lower limit of the number of hops HI takes the minimum value among the number of forwarding hops on these paths, and an upper limit of the number of hops H2 takes the maximum value among the number of forwarding hops on these paths. Further, the upper limit of the number of hops H2 may be incremented by 1 to obtain the final upper limit value for the number of hops.

At block 206, the OSPF module initiates a proxy request to the LDP proxy in the area where the LSR2 is located through the LDP module, and receives a proxy response to said proxy request returned by said LDP proxy, said proxy response includes the number of forwarding hops from the root node (determined according to the destination address) to an outlet ABR of the area where LSR2 is located; then LSR2 calculates the number of forwarding hops from the outlet ABR to itself and adds the number of forwarding hops obtained from the LDP proxy to the number of forwarding hops LSR2 has calculated to obtain the number of forwarding hops from the root node to LSR2.

Specifically, reference can be made to Fig. 3 and its illustrations for a process of determining the root node for starting to calculate the number of forwarding hops by the LDP proxy according to the destination address at this block 206.

At block 207, the OSPF module sends a failure response to the LDP module to indicate that the TTL to said destination address is invalid, then proceed to block 21 1.

At block 208, the OSPF module returns a response for obtaining the number of forwarding hops to the LDP module, which carries the number of forwarding hops from the root node to LSR2 obtained by the OSPF module. Said response may further include one or any combination of the following information: source address (i.e. LSR2 address), destination address (i.e. source address of LDP Target Hello message, namely LSR1 address), creditability flag bit, reachability flag bit, etc.

At block 209, the LDP module judges whether the received LDP Target Hello message is valid or not according to the response for obtaining the number of forwarding hops returned by the OSPF module, if it is valid, proceed to block 210, otherwise, proceed to block 21 1.

Specifically, the LDP module can determine the range of the number of forwarding hops according to the upper limit and lower limit of the number of forwarding hops from the root node to LSR2. If said range of the number of forwarding hops is within a reasonable range, the LDP Target Hello message will be judged to be valid. For example, if the range of the number of forwarding hops in the TTL calculation result is not within the range of [255- the upper limit of the number of forwarding hops, 255-the lower limit of the number of forwarding hops], it is judged that the LDP message received by LSR2 is an invalid message.

Further, if the response for obtaining of the number of forwarding hops is allowed to carry a creditability flag bit, when said creditability flag bit indicates that the number of forwarding hops carried in said response is creditable, the LDP module judges the validity of the LDP Target Hello message according to said number of forwarding hops; when said creditability flag bit indicates that the number of forwarding hops carried in said response is non-creditable, the LDP module will not use said number of forwarding hops to judge the validity of the LDP Target Hello message.

At block 210, LSR2 establishes remote neighbor relationship with LSR1 through the LDP module.

At block 21 1 , LSR2 performs corresponding processing through the LDP module according to the processing strategy for invalid messages set by the user, for example, abandoning the received LDP Target Hello message.

At block 205 or block 206 of the above flow chart, LSR2 determines the root node for starting to calculate the number of forwarding hops in the following manner: after finding a matching routing (which is called routing A hereinafter for easy description) according to the destination address, the corresponding Link State Advertisement LSA for the matching routing A as well as a router distributing said LSA are searched for (said router distributing said LAS is called router RA for easy description), then the root node for the reverse TTL calculation is determined according to the router RA and its OSPF neighbors. The detailed implementation is as follows:

(1) If the matching routing is a 32-bit routing, router RA will be used as the root node for performing the reverse SPF calculation, this is because the 32-bit routing is a specific address and is unique, and if the routing is a 32-bit routing, it means that said routing is distributed by said router RA and thus it is used as the root node;

(2) If the destination address is an interface address of the router RA, the router RA will be used as the root node;

(3) If the matching routing is not a 32-bit routing, and the destination address is not an interface address of the router RA, the OSPF neighbors with an interface corresponding to routing A in the router RA are searched for, if there is any OSPF neighbor whose interface address is said destination address, then the router of said neighbor will be used as the root node; (4) Where none of the above-mentioned condition is satisfied, the router RA will be used as the root node.

Further, a creditability flag bit can be set, namely, the creditability flag bit can be set to be 0 (which represents creditable) or 1 (which represents non-creditable) depending on different situations. For example, with respect to the above-mentioned four cases, in the first three cases, the router whose interface address is the destination address can be found, i.e. the corresponding router can be found according to the destination address, so the creditability flag bit can be set to be 0 (creditable); while in the fourth case, the router whose interface address is the destination address is not found actually, so the creditability flag bit can be set to be 1 (non-creditable).

The above blocks can be performed by the OSPF module on the router. The specific flow chart of implementation is as shown in Fig. 3. Fig. 3 is a flow chart of a method for determining a root node for starting to calculate the number of forwarding hops according to a destination address.

At block 301, said method comprises finding a matching routing A according to the destination address, searching for an LSA corresponding to said matching routing A and searching for a router RA distributing said LSA;

At block 302, said method comprises proceeding to block 303 if the routing A is a 32-bit routing or the destination address is an interface address of the router RA, otherwise, proceeding to block 304;

At block 303, said method comprises using said router RA as the root node;

At block 304, said method comprises searching for OSPF neighbors with an interface corresponding to said routing A in said router RA;

At block 305, said method comprises proceeding to block 306 if there is any OSPF neighbor whose interface address is the destination address, otherwise, proceeding to block 307;

At block 306, said method comprises using said OSPF neighbor as the root node;

At block 307, said method comprises using said router RA as the root node.

The above flow chart describes the method for verifying validity of the LDP protocol message only by taking the process of establishment of LDP neighbors as an example, the example can also be used in other cases where validity of the LDP protocol message needs to be verified.

At block 206 of the flow chart shown in Fig. 2, different flow charts may be as shown in Figs. 4 A, 4B and 4C according to different devices that initiate the proxy request, wherein Fig. 4A illustrates a flow chart in which the device initiating the proxy request is a router that does not have the LDP proxy function; Fig. 4B illustrates a flow chart in which the device initiating the proxy request is an area proxy; and Fig. 4C illustrates a flow chart in which the device initiating the proxy request is a core area proxy.

As shown in Fig. 4A, if LSR2 does not have an LDP proxy function, then a process of finally obtaining the number of forwarding hops from the root node to LSR2 by means of proxy includes the following blocks:

At block 401, LSR2 determines that LSR2 itself does not have an LDP proxy function, and then sends a proxy request for performing reverse TTL calculation to an area proxy of the area where LSR2 is located (which area proxy is called area proxy PI hereinafter for easy description), said proxy request carries a source address (i.e. LSR2 address) and a destination address (i.e. LSR1 address).

At block 402, after receiving the proxy request, the area proxy PI sends the proxy request carrying said source address (LSR2 address), said destination address (LSR1 address) and a proxy type identifier to a core area proxy. Wherein the type of proxy request identified by the proxy type identifier is a summarized request requesting the core area proxy to determine routing type after finding matching routings and to perform different processing according to different routing type.

At block 403, after the core area proxy receives the proxy request of a summarized type, then the core area proxy searches the OSPF routings for a matching routing according to the destination address carried in the proxy request by means of longest matching, and determines type of the routing after finding the matching routing. If the routing found is an intra-area routing or a direct connected routing, proceed to block 404; if it is an inter-area routing, calculations are performed by area proxy and proceed to block 405.

At block 404, the core area proxy determines a root node according to the destination address and calculates the numbers of forwarding hops from the root node to respective outlet ABRs of the core area (said outlet ABRs refer to the ABRs to the area proxy PI that initiates the proxy request among the ABRs of the core area) (this process of calculating the number of forwarding hops being called a reverse ABT TTL calculation process in the example), and returns a response message to the area proxy PI, said response message carries the calculated number of forwarding hops (including upper limit and lower limit of the number of forwarding hops) and identifiers of the outlet ABRs of the core area, it may also carry creditability flags corresponding to respective outlet ABRs and further carry all information in the proxy request (e.g. source address, destination address, request type identifier). Then, proceed to block 408.

At block 405, the core area proxy determines a target area proxy that can process said proxy request according to the destination address, and sends to said target area proxy said proxy request carrying said source address (LSR2 address), said destination address (LSR1 address) and a proxy type identifier. Wherein the proxy request type identified by the proxy type identifier is an acknowledgement request requesting the target area proxy to perform a reverse ABR TTL calculation. For easy description, the target area proxy determined by the core area proxy is hereinafter called an area proxy P2.

Specifically, when the core area proxy determines the target area proxy, it first searches for an ABR (which is called Al herein) corresponding to the routing according to the routing for the destination address and searches for an ABR (which is called A2 herein) of a routing corresponding to interface addresses of the area proxies, then depending on the situation of the searching, a method for the core area proxy to select the target area proxy may include:

(1) If Al and A2 are found and Al is the same as A2, selecting the area proxy corresponding to A2 as the target area proxy;

(2) If A2 is not found, searching a type 3 LSA (i.e. network summary LSA generated by ABR for informing intra-area routers of routing entries outside of the area) generated by Al for a routing whose prefix corresponds to a certain area proxy, and selecting said area proxy to be the target area proxy;

(3) If the target area proxy is still not found by the processing in (2), traversing the type 3 LSA generated by ABRs corresponding to the area proxies, if the type 3 LSA generated by an ABR corresponding to a certain area proxy has a prefix matching the routing of the destination address, selecting said area proxy as the target area proxy.

Another method of determining the target area proxy may include: determining a first ABR set, ABRs in said set are ABRs corresponding to routings matching the destination address; determining whether the type 3 LSAs generated by ABRs in the first ABR set have prefixes matching said destination address, if yes, putting said ABRs into a second ABR set; then ABRs in the second ABR set sending requests to their corresponding area proxies, and determining one of the area proxy devices responding to said requests as a target branch area proxy device, more particularly determining the first area proxy device responding to said requests as the target branch area proxy device.

At block 406, after the area proxy P2 receives said proxy request of an acknowledge type, then the area proxy P2 searches the OSPF routings for a matching routing according to the destination address carried in the proxy request by means of longest matching, and performs reverse ABR TTL calculation upon finding a matching routing that is an intra-area routing to obtain a result of reverse ABR TTL calculation, said result includes the number of forwarding hops from the root node determined according to the destination address to the outlet ABRs of the area where said root node is located (said outlet ABRs refer to the ABRs to the core area proxy that initiates the proxy request among the ABRs of the area where the root node is located), and returns the obtained result of reverse ABR TTL calculation to the core area proxy through a response message. The response message may include the number of forwarding hops (including upper limit and lower limit of the number of forwarding hops) and identifiers of the outlet ABRs, or it may also include creditability flags corresponding to the outlet ABRs or further include all information in the proxy request (e.g. source address, destination address, request type identifier).

At block 407, after receiving a response message returned by the area proxy P2, the core area proxy performs reverse ABR TTL calculation by using the ABRs carried therein as root nodes and using the address of the network segment where the core area proxy is located as the address of a termination node of a SPF tree to obtain the number of forwarding hops from an inlet ABR (the ABR indicated in the response message, which is the outlet ABR of the target area and is the inlet ABR of the core area in view of the core area ) to the outlet ABR of the core area (said outlet ABR refers to the ABR to the area proxy PI that initiates the proxy request among the ABRs of the core area), and then adds said number of forwarding hops calculated at blocks 406,407 and returns the added number of forwarding hops to the area proxy PI through the response message. For example, a lower limit of the number of forwarding hops calculated at block 406 is added to a lower limit of the number of forwarding hops calculated at block 407, and an upper limit of the number of forwarding hops calculated at block 406 is added to an upper limit of the number of forwarding hops calculated at block 407, and the smallest one of all the lower limits of the number of forwarding hops, which is used as the lower limit of the number of forwarding hops, and the largest one of all the upper limits of the number of forwarding hops, which is used as the upper limit of the number of forwarding hops, will be returned to the area proxy PI initiating the proxy request as responses to the proxy request.

At block 408, the area proxy PI receives the response message containing the result of reverse ABR TTL calculation returned by the core area proxy and then returns it to LSR2.

At block 409, after receiving the response message returned by the area proxy PI , LSR2 uses respective ABRs (said ABRs being outlet ABRs for the core area and inlet ABRs for the area where LSR2 is located) in the response message as the root nodes and uses the source address network segment at the local side as the destination address to calculate the number of forwarding hops from said ABRs to LSR2 (said process of calculation is called reverse TTL calculation process in the example); then adds the number of forwarding hops calculated at blocks 406,407 in the response message to the number of forwarding hops calculated at block 409, for example, a lower limit of the number of forwarding hops calculated at blocks 406,407 in the response message is added to the lower limit of the number of forwarding hops calculated at block 409, and an upper limit of the number of forwarding hops calculated at blocks 406,407 in the response message is added to the upper limit of the number of forwarding hops calculated at block 409, and the smallest one of all the lower limits of the number of forwarding hops is used as the lower limit of the number of forwarding hops, and the largest one of all the upper limits of the number of forwarding hops is used as the upper limit of the number of forwarding hops to obtain the number of forwarding hops from the root node determined according to the destination address to the present LSR (LSR2). Wherein, if the number of forwarding hops calculated by LSR2 is greater than or equal to 1 , the number of forwarding hops calculated at block 409 may be subtracted by 1 and then added to the corresponding number of forwarding hops in the received response message to said proxy request.

Specifically, the reverse TTL calculation process performed by LSR2 at this block 409 may include: performing SPF calculation starting from the respective ABRs in the response message until the local side router (i.e. LSR2) enters the SPF tree so as to calculate the numbers of forwarding hops H from the respective ABRs to the local side router (i.e. LSR2). In this process, the number is incremented by 1 each time a node is passed starting from the respective ABRs (which are not counted in) until reaching the local side router (which also serves as a node and is counted in). If the SPF tree includes multiple paths to the local side router, the lower limit HI of the number of forwarding hops is the minimum one of the numbers of forwarding hops of these paths, and the upper limit H2 of the number of forwarding hops is the maximum one of the numbers of forwarding hops of these paths. Further, the upper limit H2 of the number of forwarding hops may be added by 1 to obtain the final upper limit of the number of forwarding hops.

The reverse ABR TTL calculation process in block 404, 406 or 407 in the flow chart shown in Fig. 4A includes the following blocks A-C (blocks A and B do not have to abide by a time sequence requirement):

At block A, the LDP proxy that receives the proxy request searches for a corresponding routing (which is called routing R herein for easy description) according to the "local side source address" carried in said proxy request.

At block B, said LDP proxy performs SPF calculation using the determined root node until all the ABRs have been calculated. Then an inter-area routing calculation is performed using routing R as the routing, specifically, Metrics in the type 3 LSR generated by respective ABRs is added to the costs of paths from the root node to respective ABRs, and the ABR corresponding to the minimum cost is used as the outlet ABR of the area where the root node is located, the ABRs that do not generate LSA corresponding to routing R do not participate in the calculation for obtaining the minimum; if more than one ABRs have the minimum value, then all of them will be used as outlet ABRs. The outlet ABR determined by this process is the ABR to the router initiating the proxy request.

Specifically, with respect to blocks 404 and 406, the root node is determined by the LDP proxy according to the destination address (by means of a method as shown in Fig. 3B); with respect to block 407, the root node is the ABR indicated by the ABR identifier in the proxy response received by the core area proxy.

At block C, with respect to respective outlet ABRs, the LDP proxy calculates the number of forwarding hops H from the root node to respective outlet ABRs according to the SPF calculation result in block B (i.e. the number is incremented by 1 starting from the root node until reaching the outlet ABR wherein the root node is not counted in, and the outlet ABR serves as node and is counted in); if there are multiple paths to the outlet ABR, the lower limit Ha of the number of forwarding hops is the minimum one of the number of forwarding hops of these paths, and the upper limit Hb of the number of forwarding hops is the maximum one of the number of forwarding hops of these paths, then Ha and Hb are added by 1 , respectively.

As shown in Fig. 4B, if LSR2 has an area proxy function, then the proxy reverse TTL calculation process includes:

At block 410, LSR2 sends to the core area proxy a proxy request carrying the source address (LSR2 address), the destination address (LSR1 address) and the proxy type identifier after determining that LSR2 itself has an area LDP proxy function. Wherein the proxy request type identified by the proxy type identifier is a summarized request.

At Block 41 1, after receiving the proxy request of a summarized type, the core area proxy searches the OSPF routings for a matching routing according to the destination address carried in the proxy request by means of longest matching, and determines type of the routing after finding the matching routing. If the routing found is an intra-area routing or a direct connected routing, proceed to block 412; if it is an inter-area routing, calculations are performed by area proxy and proceed to block 413.

At block 412, the core area proxy performs reverse ABR TTL calculation according to the source address and destination address, and returns the result of calculation to LSR2 through a response message, and then proceed to block 416. The specific implementation thereof is similar to block 404 in Fig. 4A.

At block 413, the core area proxy determines according to the destination address a target area proxy (hereinafter referred to as area proxy P2) that can process said proxy request, and sends a proxy request to said target area proxy. The specific implementation thereof is similar to block 405 in Fig. 4A.

At block 414, the area proxy P2 receives the proxy request of an acknowledgement type and then performs reverse ABR TTL calculation according to the source address and destination address carried therein, and returns a result of reverse ABR TTL calculation to the core area proxy through a response message. The specific implementation thereof is similar to block 406 in Fig. 4A.

At block 415, the core area proxy receives the result of reverse ABR TTL calculation returned by the area proxy P2 and then performs reverse ABR TTL calculation using the ABRs carried therein as the root nodes and using the address of the network segment where the core area proxy is located as the termination node address of the SPF tree, and adds the number of forwarding hops calculated at block 415 to the received number of forwarding hops calculated at block 414 , and then returns the result of reverse ABR TTL calculation to LSR2 through the response message. The specific implementation thereof is similar to block 407 in Fig. 4A.

At block 416, LSR2 receives the response message returned by the area proxy PI and then performs reverse TTL calculation using the ABRs in the response message as the root nodes and uses the source address network segment at the local side as the destination address, and adds the calculated number of forwarding hops to the received number of forwarding hops calculated at block 414, 415. The specific implementation thereof is similar to block 409 in Fig. 4A.

As shown in Fig. 4C, if LSR2 has a core area proxy function, the proxy reverse TTL calculation process includes the following blocks:

At blocks 420-421 , LSR2, after determining that it has the main LDP proxy function, searches the OSPF routings for matching routings using the source address of the LDP target Hello message as the destination address by means of longest matching, and determines type of the routing after finding the matching routing, if said routing is an inter-area routing, calculations will be performed by area proxy, i.e. block 422 will be performed.

At this block 421 , if the routing found is an intra-area routing or a direct connected routing, reverse TTL calculation does not need to be performed by proxy, instead LSR2 performs reverse TTL calculation to obtain the number of forwarding hops from LSR2 to LSR1.

At block 422, LSR2 determines a target area proxy that can process said proxy request according to the destination address and sends a proxy request to said target area proxy (area proxy P2). The specific implementation thereof is similar to block 405 in Fig. 4A.

At block 423, the area proxy P2 receives the proxy request of an acknowledgement type and then performs reverse ABR TTL calculation according to the source address and destination address carried therein, and returns a result of reverse ABR TTL calculation to LSR2 (i.e. the core area proxy) through a response message. The specific implementation thereof is similar to block 406 in Fig. 4A.

At block 424, LSR2 receives the response message returned by the area proxy P2 and then performs reverse TTL calculation using respective ABRs carried in the response message as the root nodes and uses the address of LSR2 itself as the termination node address of the SPF tree, and adds the calculated number of forwarding hops to the number of forwarding hops returned by area proxy P2 to obtain the number of forwarding hops or a range of the number of forwarding hops from the root node determined according to the destination address to LSR2. The specific implementation thereof is similar to block 407 in Fig. 4A.

In the flow charts shown in Fig. 4A, 4B or 4C, the proxy device receiving the proxy request is made to perform the corresponding processing by adding a proxy type identifier to the proxy request, but the proxy device receiving the proxy request can be made to perform the corresponding processing by other ways, for example, sides receiving proxy request performs the corresponding processing according to different sides initiating proxy request (i.e. whether the proxy request is from a core area proxy or from an area proxy).

According to the flow charts shown in Figs. 4A, 4B and 4C, the process flow chart of the proxy device after receiving the proxy request can be as shown in Fig. 5, which includes the following cases:

(1) If the present proxy device is the side initiating the proxy request, it is determined whether said proxy device is the core area proxy; if it is not, a proxy request is sent to the core area proxy, the proxy request including the source address, destination address and request type (herein, said request type is summarized request) of said side; if it is, calculation is performed by area proxy to determine the target area proxy device and send a proxy request to the target area proxy device, the proxy request including the source address, destination address and request type (herein, said request type is acknowledgement request) of the present proxy device.

(2) If the present proxy device is the side receiving the proxy request, and if the received proxy request is a summarized request, and the present proxy device is a core area proxy, the OSPF routings will be searched for matching routings by means of longest matching, if no matching routing is found, a failure response message will be returned to the side initiating the proxy request, which may include all information in the proxy request (source address, destination address and request type of said side) as well as the proxy calculation failure information; if any matching routing is found, then

A: If the routing found is an intra-area routing or a direct connected routing, a reverse ABR TTL calculation is performed, then a response message is returned to the side initiating the proxy request, which includes all information in the proxy request (source address, destination address and request type of said side), identifiers of the respective outlet ABRs as well as the corresponding creditability flag and hop number information (including lower limit and upper limit of the hop number); B: If the routing found is an inter-area routing, an area proxy calculation is performed to determine a target area proxy device and send a proxy request thereto, the request including the received source address, destination address and request type (herein, said request type is acknowledgement request).

(3) If the proxy request received by the present proxy device is an acknowledge request, and said proxy device is an area proxy, the OSPF routings will be searched for matching routings by means of longest matching, if no matching routing is found, a failure response message will be returned to the side initiating the proxy request, which may include all information in the proxy request (source address, destination address and request type of said side) as well as the proxy calculation failure information; if any matching routing is found, then

A: If the routing found is an intra-area routing, a reverse ABR TTL calculation is performed, then a response message is returned to the side initiating the proxy request, which includes all information in the proxy request (source address, destination address and request type of said side), identifiers of the respective outlet ABRs as well as the corresponding creditability flag and hop number information (including lower limit and upper limit of the hop number);

B: If the routing found is not an intra-area routing, a failure response message is returned to the side initiating the proxy request, which includes all information in the proxy request (source address, destination address and request type of said side) as well as the proxy calculation failure information.

(4) If the proxy request received by the present proxy device and the proxy type of said proxy device are not like the above-mentioned cases, a failure response message is returned to the side initiating the proxy request, said message including all information in the proxy request (source address, destination address and request type of said side) as well as the proxy calculation failure information.

In order to reduce overhead for reverse ABR TTL calculation of the router, a second example which makes some improvement to the first example is provided. That is, after the LDP proxy device (including area proxy or/and core area proxy) performs the reverse ABR TTL calculation, the calculation result is stored or updated locally; or, the LDP proxy device, after receiving the proxy responses returned by other LDP proxy devices, stores or updates locally the results of reverse ABR TTL calculation carried in said responses. For example, information relating to the result of reverse ABR calculation is stored in the form of a proxy table, each table entries including such information as origination neighbor, source address, destination address, next hop proxy, number of forwarding hops (e.g. including lower limit of hop number, upper limit of hop number), or further including routing information, SPF information, etc.

Origination neighbor: when a proxy request message is received from a neighbor device, the address of said neighbor is the origination neighbor. For example, in the first example when the core area proxy receives the proxy request initiated by area proxy PI , the origination neighbor is the area proxy PI ; if the proxy request is initiated locally, the origination neighbor is null.

Source address: the "source address" carried in the proxy request message. If the proxy request is initiated locally, it is the source address of the present side. For example, in the first example when LSR2 initiates a proxy request to area proxy PI , said message carries a "source address", and said source address is the destination address of the LDP message received by LSR2, which is the address of LSR2 herein.

Destination address: the "destination address" carried in the proxy request message, for example, in the first example the source address of the LDP message received by LSR2, which is the address of LSR1 herein. If the proxy request is initiated locally, it is the destination address.

Next hop proxy: the object that the proxy request message will be sent to, if, after receiving the proxy request, the present proxy device does not need to send the proxy request to other proxy devices, then said entries are null. For example, in the first example after receiving the proxy request sent by area proxy PI, the core area proxy determines that it is necessary to send the proxy request to area proxy P2, then the area proxy P2 is the corresponding next hop proxy.

Lower limit of hop number: the lower limit of hop number calculated by the present proxy device or obtained from the proxy responses returned by other proxy devices.

Upper limit of hop number: the upper limit of hop number calculated by the present proxy device or obtained from the proxy responses returned by other proxy devices.

Routing information: the routing matching the destination address.

SPF information: the source router is the router generating the LSR corresponding to the routing matching the destination address (i.e. the root node determined according to the destination address for starting to calculate the number of forwarding hops), while the SPF tree to the local side calculated from the source router (i.e. root node) is the monitored SPF information.

Based on said proxy table recorded by the LDP proxy device, in the flow chart of establishing remote LDP neighbor relationship, when the LDP proxy device needs to perform reverse ABR TTL calculation, it first inquires the local proxy table to determine whether there are matching table entries, if there are, the corresponding information in said table entries will be used as the result of reverse ABR TTL calculation; if no matching table entries are found, a reverse ABR TTL calculation will be performed according to the method in the first example, and the corresponding proxy table entries will be created after obtaining the number of forwarding hops from the root node to the outlet ABR of the area where the proxy device is located.

For example, after receiving the proxy request from LSR2, area proxy PI looks up the proxy table it has recorded and maintained according to the address of LSR2 and the destination address and source address carried in the proxy request, if any matching table entries are found, said table entries or the number of forwarding hops in said table entries will be returned as the result of reverse ABR TTL calculation; if no matching table entries are found, the reverse ABR TTL calculation process will be started according to the previously described flow chart.

To be specific, if a proxy table entries can be found in the proxy table, in which the "origination neighbor" is the device initiating the proxy request, the destination address is the destination address carried in said proxy request, and the source address is the source address carried in the proxy request, such information as the origination neighbor, source address, destination address, lower limit of hop number and upper limit of hop number in said proxy table entries can be returned to the side initiating proxy request as responses to the proxy request.

Further, said proxy table also needs to be updated dynamically according to the change of the network topology to ensure the real-time and accuracy of data therein. For example, when said "routing information" or "SPF information" changes, a reverse ABR TTL calculation needs to be triggered to re-obtain the number of forwarding hops from the "source address" to the "destination address" of the corresponding table entries and to update the corresponding table entries on the present proxy device and the relevant proxy devices.

Taking the core area proxy as an example, Fig. 6 is a schematic drawing of a flow chart of updating a proxy table according to an example.

At block 601 , when the core area proxy discovers a routing change, it is determined whether said routing exists in the proxy table, if yes, proceeding to block 602, otherwise, ending the flow chart;

At block 602, the core area proxy inquires the table entries whose routing information changes, if the "next hop proxy" is the address of the area proxy (area proxy P2, for example, in this example), proceeding to block 603; if the "next hop proxy" is null, proceeding to block 605;

At block 603, the core area proxy sends to area proxy P2 a proxy request that carries the "destination address" and receives the proxy response returned by the area proxy P2, which carries the number of forwarding hops from the root node to the outlet ABR of the area where it is located obtained by the area proxy P2 according to the "destination address" and through reverse ABR TTL calculation; after calculating said number of forwarding hops, the area proxy P2 updates the corresponding local proxy table entries;

At block 604, after receiving the proxy response returned by the area proxy P2, the core area proxy obtains the number of forwarding hops from the outlet ABR indicated in said proxy response to the outlet ABR of the core area through reverse ABR TTL calculation, then adds the calculated number of forwarding hops to the number of forwarding hops carried in the proxy response, and thereby updates the number of forwarding hops in said proxy table entries, then proceeding to block 606;

At block 605, the core area proxy determines the root node for starting to perform reverse ABR TTL calculation according to the "destination address" in said table entries, and performs reverse ABR TTL calculation using said root node as a starting point, and updates the number of forwarding hops in the corresponding proxy table entries according to calculation result, then proceeding to block 606;

At block 606, the core area proxy inquires the "origination neighbor" in said table entries, if the "origination neighbor" is the address of the area proxy (area proxy PI , for example, in this example), proceeding to block 607; if the "origination neighbor" is null, ending this flow chart;

At block 607, the core area proxy sends to the area proxy PI a notification message carrying relevant contents of the corresponding proxy table entries, e.g. source address, destination address, number of forwarding hops, so as to inform the area proxy PI to update the corresponding proxy table entries.

The flow chart of updating proxy table entries on other proxy devices is similar to the above-mentioned flow chart, for example, if the updating flow chart is initiated by the area proxy P2, then the area proxy P2 will, after updating the corresponding table entries, inform the core area proxy to update the corresponding proxy table entries (when the side initiating proxy request in said proxy table entries is the core area proxy); after receiving said notification by the core area proxy, if it is determined that the side initiating proxy request recorded in the corresponding table entries is other branch area proxy, a reverse ABR TTL calculation needs to be performed to obtain the number of forwarding hops from the outlet ABR of the area where the area proxy P2 is located to the outlet ABR of the core area, and then the corresponding proxy table entries will be updated and the side initiating proxy request (i.e. branch area proxy device) in said table entries will be informed to update the corresponding proxy table entries; otherwise, the corresponding proxy table entries is updated according to the notification without the need to perform the reverse ABR TTL calculation.

Further, if the LDP proxy changes, reselection of the "next hop proxy" needs to be triggered (i.e. re-determining the object to which the present device sends the proxy request message). As for how the selection is performed specifically, it depends on the change of the network topology. For example, with respect to an area proxy device, if the core area proxy device changes, the "next hop proxy" needs to be updated to the address of the new core area proxy device, with respect to a core area proxy device, the target area proxy device needs to be re-determined, and the "next hop proxy" needs to be updated to the address of the new target area proxy device. Then the number of forwarding hops is updated depending on situation.

Further, when the established LDP neighbor relationship is cancelled, devices having a neighbor relationship (e.g. LSR1 or LSR2) may send to the proxy device a proxy retrieval message which may include the source address and destination address of the present side and the Router ID of the OSPF process in the present side. A neighbor which is as the proxy device, upon receiving said proxy retrieval message, will look up the proxy table according to the source address and destination address to delete the corresponding table entries.

A third example is provided, and the only difference between the first example or the second example and the third example is that this third example uses an independent device to perform reverse TTL calculation or reverse ABR TTL calculation. Said independent device may be configured as a proxy server. Devices that require dynamic neighbor protection establish LDP proxy neighbor relationship with said proxy server, respectively, and all the OSPF areas concerned should have at least one device to establish LDP proxy neighbor relationship with the proxy server. In this third example, the device establishing a LDP proxy neighbor relationship with the proxy server is called a proxy client.

Each of the proxy clients synchronizes the OSPF LSA of the present area to the proxy server, and no LDP proxy relationship exists between the proxy clients. After receiving the LSA, the proxy server finds a device in each area as the root node (which can be configured by the user) to perform routing calculation to obtain the routing table of each area. Of course, the routing table of each area can be configured on said proxy server by other means.

As in the first example or the second example, if the router determines that the routing matching the destination address (e.g. the source address of the LDP message received by said router and whose validity is to be verified) is an intra-area routing, then said router can determine a root node for performing the reverse TTL calculation according to said destination address, and start the reverse TTL calculation in the corresponding area, so as to obtain the number of forwarding hops from said root node to said router, and thereby verifying validity of the LDP message according to said number of forwarding hops.

Unlike the first example or the second example, if the router determines that the routing matching the destination address is an inter-area routing, it initiates a proxy request to a proxy client in the area where it is located, said proxy client initiates a proxy request to a proxy server, and the proxy server finishes the calculation of the number of forwarding hops alone according to the routing table of the relevant area it has stored, and returns the calculation result to the proxy client by carrying it in a proxy response, said proxy client forwards said proxy response to the router initiating the proxy request, so that said router verifies validity of the LDP message according to the number of forwarding hops.

Specifically, taking the process of establishing remote LDP neighbor relationship as an example, after receiving an LDP Target Hello message, LSR2 uses the source address of said message as the destination address to perform routing matching using the routing table of the area where said device is located, if the matching routing found is an inter-area routing, a proxy request is sent to the proxy client in said area, and said proxy client forwards said proxy request to the proxy server, said proxy request carries the destination address (i.e. source address of LDP Target Hello message) and the source address (i.e. address of the device where the proxy client is located).

The proxy server searches each of the areas for matching intra-area routings according to the destination address carried in the proxy request and according to the routing tables of each of the areas it has stored, the result of matching and the corresponding processing flow may include the following several instances:

Instance 1 : the router initiating the proxy request is in a branch area and the proxy server finds a matching routing in other branch areas.

Suppose that the branch area where the router initiates the proxy request is area A, while the proxy server finds a matching routing in area B, in this case, similar to the processing flow chart in which a matching inter-area routing is found as shown in Fig. 4 A or 4B, the proxy server performs reverse ABR TTL calculation using a routing table of area B to obtain the number of forwarding hops from the root node (determined according to the destination address) to the outlet ABR of area B, performs reverse ABR TTL calculation using a core area routing table to obtain the number of forwarding hops from the outlet ABR of area B (i.e. inlet ABR of the core area) to the outlet ABR of the core area, and performs reverse TTL calculation using a routing table of area A where the router of the side initiating proxy request is located to obtain the number of forwarding hops from the outlet ABR of the core area to LSR2, then adds the numbers of forwarding hops obtained by the three times of calculation together and carries the added numbers of forwarding hops in a proxy response to return to the proxy client, the proxy client forwards said response to the router initiating said proxy request, so that said router finally obtains the number of forwarding hops from the destination address to the source address.

Instance 2: the router initiating the proxy request is in a branch area and the proxy server finds a matching routing in a core area.

Suppose that the branch area where the proxy client initiates the proxy request is area A, while the proxy server finds a matching routing in a core area, in this case, similar to the processing flow chart in which a matching intra-area routing is found as shown in Fig. 4A or 4B, the proxy server performs reverse ABR TTL calculation according to a routing table of the core area to obtain the number of forwarding hops from the root node (determined according to the destination address) to the outlet ABR of the core area, and performs reverse TTL calculation according to a routing table of area A to obtain the number of forwarding hops from the outlet ABR of the core area to said router, then adds the numbers of forwarding hops obtained by the two times of calculation together and carries the added numbers in a proxy response to return to the proxy client, the proxy client forwards said response to the router initiating said proxy request, so that said router obtains the number of forwarding hops from the destination address to the source address.

Instance 3 : the router initiating the proxy request is in a core area and the proxy server finds a matching routing in a branch area.

Suppose that the proxy server finds a matching routing in an area B, in this case, similar to the processing flow chart in which a matching inter-area routing is found as shown in Fig. 4C, the proxy server performs reverse ABR TTL calculation according to a routing table of area B to obtain the number of forwarding hops from the root node (determined according to the destination address) to the outlet ABR of area B, and performs reverse TTL calculation according to a routing table of the core area where the router initiating the proxy request is located to obtain the number of forwarding hops from the outlet ABR of area B to said router, then adds the numbers of forwarding hops obtained by the two times of calculation together and carries the added numbers in a response message to send to the proxy client, the proxy client forwards said response message to the router initiating said proxy request, so that said router obtains the number of forwarding hops from the destination address to the source address.

Instance 4: no matching routing is found.

In this case, the proxy server returns a failure response message to the proxy client.

Instance 5: when the device receiving an LDP protocol message and verifying validity of said message is a proxy server, the specific implementation of calculating the number of forwarding hops is similar to the above instances; if any matching intra-area routing is found in the area where it is located, a reverse TTL calculation is performed using a routing table of said area; if any matching intra-area routing is found in other areas, a corresponding reverse TTL calculation is performed according to whether said other areas are branch areas or core areas (if said other areas are branch areas, the ABR TTL calculation is performed twice, if said other areas are core areas, the ABR TTL calculation is performed once).

Fig. 7 is a schematic drawing of a specific application scenario according to an example.

Referring to Fig. 7, LDP remote neighbors are configured between RTA and RTB, and RTA is an area proxy of Area 1 where it is located. The number of hops from RTB to RTA needs to be calculated on RTA. Wherein, RTCore-1 is a core area proxy. RTA, RTB and RTD establish proxy neighbor relationship with RTCore-1, respectively. The Cost of each of the links is 1.

An LDP process sends a calculation request message to an OSPF process on RTA, the source address is 1.1.1.1 , and the destination address is 2.0.0.2. The OSPF process looks up an OSPF routing table after receiving the message and performs longest matching using 2.0.0.2/32 as a destination address. In this example, the routing found is an inter-area routing. The RTA OSPF process notifies the LDP process a proxy request message which includes the source address (1.1.1.1), destination address (2.0.0.2) of the present side, and the Router ID (1.1.1.1) and request type (summarized request) of the OSPF process at the present side, and the LDP process sends these information to the core area proxy RTCore-1.

Upon receiving the information, RTCore-1 looks up a local OSPF routing table to find routing 2.0.0.2/32, which is an inter-area routing. Then RTCore-1 performs an area proxy calculation. Specifically, on RTCore-1 , a first ABR set is determined, the ABRs in said set is ABRs corresponding to the routing matching 2.0.0.2/32; if the RTCore-1 determines that in the type 3 LSA generated by ABRs in the first ABR set, the prefix of the routing of ABR2 matches 2.0.0.2/32, then ABR2 will be placed in a second ABR set; then a request is sent to the corresponding area proxies RTB and RTD through ABR2 in the second ABR set, and one of the area proxies responding to said request is determined as a target branch area proxy. Since RTB responds to the request of ABR2 first, it is chosen as the target branch area proxy. RTCore-1 sends an acknowledge request to RTB, which includes the received source address (1.1.1.1), destination address (2.0.0.2) and request type (acknowledgement request).

After receiving the acknowledge request, RTB searches for local OSPF routings, if they are found to be local direct connected routings, a reverse ABR TTL calculation will be performed, which specifically includes the following blocks (1)~(5):

(1) Since the destination address 2.0.0.2 is the address of a direct connected interface of RTB, the source router is RTB;

(2) The received source address is 1.1.1.1 , and the longest matching routing of 1.1.1.1 is found to be 1.1.1.1/32;

(3) An SPF calculation is performed using RTB as a root node until all ABRs have been calculated, and there is only one ABR herein, i.e.

ABR2; the calculation is based on a cost from the ABR (which is ABR2) to 1.1.1.1/32, when the cost from RTB to ABR2 is 1 and the Metric in the type 3 LSA generated by ABR2 is 4, then cost is 1+4=5; since there is only one ABR, said value is just the minimum value;

(4) A hop number from RTB to ABR2 is calculated according to an SPF tree, which is 1 ;

(5) The self-incrementing flag is 0, so the hop number is still 1.

RTB sends to RTCore-1 a response message which includes the "source address of the present side" (1.1.1.1), the destination address (2.0.0.2), the request type (acknowledge request), the outlet ABR (1.0.2.1, i.e. ABR2), creditability flag (creditable) and information of hop number (hop number lower limit being 1 , hop number upper limit being 1) in the request.

After receiving the response message, RTCore-1 performs reverse ABR TTL calculation using an outlet ABR (1.0.2.1) in the message as the source node to obtain a hop number of 3; a hop number of 1 in the message is added thereto to obtain a hop number of 4. A response message is sent to an LDP neighbor RTA, which includes the "source address of the present side" (1.1.1.1), the destination address (2.0.0.2), the request type (summarized request), the outlet ABR (1.0.0.1 , i.e. ABR1), the creditability flag (creditable) and hop number information in the request message.

After receiving a response message, RTA performs reverse TTL calculation using an outlet ABR (1.0.0.1) in the message as the source node to obtain a hop number of 1. Said hop number is added to the hop number (4) in the response message to obtain a hop number of 5. Since 5>1, the final hop number is 5-1=4.

The above example describes a process in which after receiving an LDP message initiated by a peer side, LSR obtains the number of forwarding hop from the peer side to said LSR through reverse TTL or/and reverse ABR TTL calculation, and verifies validity of said LDP message according to said number of forwarding hop, so as to determine whether to establish an LDP neighbor relationship with the peer side. Based on the above described concept and principle, another example is that when LSR initiates an LDP message to request to establish an LDP neighbor relationship with the peer side, said LSR performs reverse TTL and/or reverse ABR TTL calculation using the peer side address as the destination address so as to obtain the number of forwarding hop from the peer side to said LSR, and to determine whether said number of forwarding hop is within a reasonable range; if it is within a reasonable range, said LSR establishes a LDP neighbor relationship with the peer side after receiving an LDP message responded by the peer side. The specific process of implementation for said another example is substantially the same as the previously described example and thus will not be elaborated any more.

Based on the same technical concept, the disclosure also provides a network device applicable to the above-described flow charts.

Referring to Fig. 8, which is a structural schematic drawing of a router 90 according to an example. As shown in the Fig. 8, said router may include a transceiving module 91 , an LDP module 92 and an OSPF module 93. The OSPF module 93 comprises a control unit 931, a routing matching unit 932, and a calculating unit 933.

The LDP module 92 is to request the OSPF module 93 to calculate the number of forwarding hop to the peer side after the transceiving module 91 receives an LDP message sent by the peer side, and establish an LDP relationship with the peer side if said number of forwarding hop is within a specified range;or, the LDP module 92 is to request the OSPF module 93 to calculate the number of forwarding hop to the peer side after the transceiving module 91 sends an LDP message to the peer side, and establish an LDP neighbor relationship with the peer side after receiving a response LDP message from the peer side if said number of forwarding hop is within a specified range; and to obtain from a proxy server the number of forwarding hops from a root node for starting to calculate the number of forwarding hops to said router through a proxy client device in the area where it is located according to a proxy request from the OSPF module 93, wherein the root node is determined according to the destination address. The control unit 931 is to instruct said routing matching unit 932 to match routing according to the received request, instruct the calculating unit 933 to calculate the number of forwarding hop if any matching intra-area routing is found; and request the LDP module 92 to initiate a proxy request if any matching inter-area routing is found.

The routing matching unit 932 is to perform matching of routing using the peer side address as the destination address according to the instruction of the control unit 931.

The calculating unit 933 is to determine the root node for starting to calculate the number of forwarding hops according to said destination address, calculate the number of forwarding hops from said root node to said router and send it to the LDP module 92 according to the instruction of the control unit 931.

The LDP module 92 is specifically to send a proxy request to said proxy server through the proxy client of the area in which it is located, said proxy request carries said destination address such that said proxy server searches in each area whether there is matching intra-area routing according to the destination address carried in said proxy request and according to the routing tables of each of the areas configured thereon.

If the router initiating the proxy request is in a first branch area, the proxy server finds a matching routing in a second branch area, then the proxy server determines the root node for starting to calculate the number of forwarding hops according to said destination address, calculates the number of forwarding hops from the root node to the outlet ABR of the second branch area using the routing table of said second branch area with the root node being used as the starting point, calculates the number of forwarding hops from the outlet ABR of said second branch area to the outlet ABR of the core area using the routing table of the core area, calculates the number of forwarding hops from the outlet ABR of said core area to said router using the routing table of the first branch area, adds the numbers of forwarding hops obtained from the three times of calculations and then returns said added numbers to the proxy client by carrying it in the proxy response, said proxy client forwards the response to the router initiating the proxy request.

If the router initiating the proxy request is in a branch area, the proxy server finds a matching routing in the core area, then the proxy server determines the root node for starting to calculate the number of forwarding hops according to said destination address, calculates the number of forwarding hops from the root node to the outlet ABR of the core area using the routing table of the core area with the root node being used as the starting point, calculates the number of forwarding hops from the outlet ABR of said core area to said router using the routing table of the branch area, adds the numbers of forwarding hops obtained from the two times of calculation, and then returns the added numbers to the proxy client by carrying it in a proxy response, said proxy client forwards the response to the router initiating the proxy request.

If the router initiating the proxy request is in a core area, the proxy server finds a matching routing in a branch area, then the proxy server determines the root node for starting to calculate the number of forwarding hops according to said destination address, calculates the number of forwarding hops from the root node to the outlet ABR of the branch area using the routing table of the branch area with the root node being used as the starting point, calculates the number of forwarding hops from the outlet ABR of said branch area to said router using the routing table of the core area, adds the numbers of forwarding hops obtained from the two times of calculations, and then returns the added numbers to the proxy client by carrying it in a proxy response, said proxy client forwards the response to the router initiating the proxy request.

Specifically, when determining the root node for starting to calculate the number of forwarding hops according to the destination address, the calculating unit 933 searches for the corresponding LSA according to the found matching intra-area routing, searching for the source router distributing said LSA, and determines the root node for starting to calculate the number of forwarding hops according to said source router and its OSPF neighbors.

Specifically, the calculating unit 933 determines the root node in the following manner:

(1) If the matching routing is a 32-bit routing, the source router will be used as the root node for starting to calculate the number of forwarding hops;

(2) If the destination address is an interface address of the source router, the source router will be used as the root node for starting to calculate the number of forwarding hops;

(3) If the destination address is not an interface address of the source router, the OSPF neighbors of the interface corresponding to a specific routing in the source router are searched for, if there is any OSPF neighbor whose interface address is said destination address, then the router of said neighbor will be used as the root node for starting to calculate the number of forwarding hops; wherein, said specific routing is routing corresponding to said destination address;

(4) Where none of the above-mentioned condition (1), (2) and (3) is satisfied, the source router will be used as the root node for starting to calculate the number of forwarding hops.

Further, under the condition that there are multiple forwarding paths, said number of forwarding hops comprises an upper limit and a lower limit; the upper limit of the number of forwarding hops is the maximum of the numbers of forwarding hops of said multiple forwarding paths, and the lower limit of the number of forwarding hops is the minimum of the numbers of forwarding hops of said multiple forwarding paths.

Referring to Fig. 9, which is a schematic drawing of the structure of a server 1000 according to an example. Said server is proxy server in the third example. As shown in the Figure 9, said server may comprise: a transceiving module 1001 , a control module 1002, a routing matching module 1003 and a calculating module 1004.

The control module 1002 is to instruct the routing matching module 1003 to match routings after receiving a proxy request carrying a destination address which is forwarded by the proxy client device, wherein, said destination address is the address of a peer side device of the router initiating said proxy request; instruct the calculating module 1004 to calculate the number of forwarding hops from the root node to the router that initiates said proxy request according to the routing matched by said routing matching module 1003, and send the number of forwarding hops through said transceiving module 1001 to said proxy client device for forwarding; wherein, said root node is determined according to said destination address.

The routing matching module 1003 is to perform matching of routings using the routing tables of each of the areas according to the instruction of the control module 1002 and according to said destination address.

The calculating module 1004 is to calculate the number of forwarding hops from the root node to the router that initiates said proxy request according to the instruction of said control module 1002.

The control module 1002 is specifically to:

send a first instruction to the calculating module 1004 if the router that initiates a proxy request is in a first branch area and said routing matching module finds a matching routing in a second branch area;

send a second instruction to the calculating module 1004 if the router that initiates a proxy request is in a branch area and said routing matching module finds a matching routing in a core area;

send a third instruction to the calculating module 1004 if the router that initiates a proxy request is in a core area and said routing matching module finds a matching routing in a branch area.

The calculating module 1004 is specifically to:

after receiving said first instruction, determine a root node for starting to calculate the number of forwarding hops according to said destination address, calculate the number of forwarding hops from the root node to the outlet ABR of the second branch area using the routing table of said second branch area with the root node being used as the starting point, calculate the number of forwarding hops from the outlet ABR of said second branch area to the outlet ABR of the core area using the routing table of the core area, calculate the number of forwarding hops from the outlet ABR of said core area to said router using the routing table of the first branch area, add the numbers of forwarding hops obtained from the three times of calculations and returning said added numbers to the proxy client by carrying it in the proxy response;

after receiving said second instruction, determine the root node for starting to calculate the number of forwarding hops according to said destination address, calculate the number of forwarding hops from the root node to the outlet ABR of the core area using the routing table of the core area with the root node being used as the starting point, calculate the number of forwarding hops from the outlet ABR of said core area to said router using the routing table of the branch area, add the numbers of forwarding hops obtained from the two times of calculation, and returning the added numbers to the proxy client by carrying it in a proxy response; after receiving said third instruction, determine the root node for starting to calculate the number of forwarding hops according to said destination address, calculate the number of forwarding hops from the root node to the outlet ABR of the branch area using the routing table of the branch area with the root node being used as the starting point, calculate the number of forwarding hops from the outlet ABR of said branch area to said router using the routing table of the core area, adding the numbers of forwarding hops obtained from the two times of calculations, and returning the added numbers to the proxy client by carrying it in a proxy response.

The calculating module 1004 is specifically to, when calculating the number of forwarding hops from said root node to the outlet ABR of the area in which it is located:

perform SPF calculation with said root node being used as the starting point, until the ABRs of the area in which said root node is located enter the SPF tree;

select the ABRs that generate a specific LSA from respective ABRs, said specific LSA is LSA corresponding to the routing that matches said destination address, add the Metrics in the types 3 LSAs generated by the selected ABRs respectively to the costs of the paths from the root node to respective ABRs, take the ABR corresponding to the cost having the minimum value as the outlet ABR of said area;

calculate the number of forwarding hops from said root node to said outlet ABR according to the path obtained from the SPF calculation; wherein, starting from the root node, the number of forwarding hops increments each time a node is passed until the outlet ABR of said area is counted in as the last node.

The calculating module 1004 is specifically to, when calculating the number of forwarding hops from the outlet ABR of said second branch area to the outlet ABR of the core area:

perform SPF calculation with the outlet ABR of the branch area in which said root node is located being used as the inlet ABR of the core area and with said inlet ABR being used as the starting point, until the ABRs of the core area enters the SPF tree; select the ABRs that generate a specific LSA from respective ABRs of the core area, said specific LSA is LSA corresponding to the routing that matches said destination address, add the Metrics in the type 3 LSAs generated by the selected ABRs respectively to the costs of the paths from the root node to respective ABRs, take the ABR corresponding to the cost having the minimum value as the outlet ABR of the core area; calculate the number of forwarding hops from the outlet ABR of the second branch area in which said root node is located to the outlet ABR of said core area according to the path obtained from the SPF calculation, wherein, the number of forwarding hops increments each time a node is passed starting from the outlet ABR of the second branch area in which said root node is located until the outlet ABR of said core area is counted in as the last node.

Specifically, the calculating module 1004 is further to, after determining said root node and calculating the number of forwarding hops using said root node as the starting point, set a creditability flag corresponding to the calculated number of forwarding hops; and carry said creditability flag in the proxy response.

Specifically, the calculating module 1004 is to, when determining the root node for starting to calculate the number of forwarding hops according to said destination address, search for the corresponding LSA according to the found matching intra-area routing, search for the source router that distributes the LSA, and determine the root node for starting to calculate the number of forwarding hops according to the source router and its OSPF neighbors.

Specifically, the calculating module 1004 determines the root node in the following manner:

(1) If the matching routing is a 32-bit routing, the source router will be used as the root node for calculating the number of forwarding hops;

(2) If the destination address is an interface address of the source router, the source router will be used as the root node for calculating the number of forwarding hops;

(3) If the destination address is not an interface address of the source router, the OSPF neighbors of the interface corresponding to a specific routing in the source router are searched for, if there is any OSPF neighbor whose interface address is said destination address, then the router of said neighbor will be used as the root node for starting to calculate the number of forwarding hops; wherein, said specific routing is routing corresponding to said destination address;

(4) Where none of the above-mentioned condition (1), (2) and (3) is satisfied, the source router will be used as the root node for calculating the number of forwarding hops.

Further, the calculating module 1004 is further to, under the condition of (1), (2) or (3), set the value of the creditability flag to be creditable corresponding to the number of forwarding hops calculated by using the root node as the starting point; and for, under the condition of (4), set the value of the creditability flag to be non-creditable corresponding to the number of forwarding hops calculated by using the root node as the starting point. Further, under the condition that there are multiple forwarding paths, said number of forwarding hops comprises an upper limit and a lower limit; the upper limit of the number of forwarding hops is the maximum of the numbers of forwarding hops of said multiple forwarding paths, and the lower limit of the number of forwarding hops is the minimum of the numbers of forwarding hops of said multiple forwarding paths.

The above examples can be implemented by hardware, software or firmware or a combination thereof. For example the various methods, processes and functional units described herein may be implemented by a processor (the term processor is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate array etc.). The processes, methods and functional units may all be performed by a single processor or split between several processers; reference in this disclosure or the claims to a 'processor' should thus be interpreted to mean One or more processors' . The processes, methods and functional modules be implemented as machine readable instructions executable by one or more processors, hardware logic circuitry of the one or more processors or a combination thereof. Further the teachings herein may be implemented in the form of a software product. The computer software product is stored in a storage medium and comprises a plurality of instructions for making a computer device (which can be a personal computer, a server or a network device such as a router, switch, access point etc.) implement the method recited in the examples of the present disclosure.

The drawings are merely schematic drawings of an example, and the modules or flows in the drawings are not necessary essential for carrying out the disclosure.

The modules in the device in the examples can be distributed in the device in the examples according to the descriptions of the example, or they can be changed so as to be in one or more devices that are different from that in the examples. The modules in the above examples can be either combined into one module or further divided into several sub-modules. The above sequential numbers mentioned are only for facilitating description, but they are not used to represent which example is more advantage.

The above description includes examples. Any modification, equivalent substitution and improvement made that are according to the spirit and principle of the examples shall be included in the protection scope.