WO2012062092A1

WO2012062092A1 - Apparatus and method for route inquiry

Info

Publication number: WO2012062092A1
Application number: PCT/CN2011/073838
Authority: WO
Inventors: 马西照
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-11-12
Filing date: 2011-05-09
Publication date: 2012-05-18
Also published as: CN102469012A; CN102469012B

Abstract

The invention provides an apparatus and a method for route inquiry, which is applied to the automatic switched optical network. The route inquiry apparatus includes: An inquiry policy establishment module, which is set for, when receiving a route inquiry request which has not been received before, establishing the inquiry policy corresponding to the route inquiry request which has not been received according to the inquiry policy template; an inquiry policy storage module, which is set for storing the correspondence between the route inquiry request which has not been received and the inquiry policy corresponding to the route inquiry request which has not been received; inquiry policy implementation module, which is set for finding and performing the inquiry policy corresponding to a received route inquiry request in the correspondence. By using the technical solution of the invention, the flexibility of constraint route calculation is improved, and then the diverse route inquiry request can be satisfied.

Description

TECHNICAL FIELD The present invention relates to the field of communications, and in particular to a route query apparatus and method. BACKGROUND With the development of related technologies in the information field, especially the strong promotion of the data service by the Internet, the optical network is required to adjust the logical topology of the network in real time and dynamically, and realize the optimal utilization of resources, which can be fast and high quality. It provides users with various bandwidth services and applications, and has more comprehensive protection and recovery functions, greater operability and scalability. Automatically Switched Optical Network (ASON) is an IP, Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Dense Wavelength Division Multiplexing (Dense Wavelength Division Multiplexing). Sublimated in the environment of DWDM for short, the flexibility and efficiency of IP, the protection of SONET/SDH and the capacity of DWDM are organically combined through an innovative distributed network management system, giving the existing network more intelligence. The utilization of network resources is improved, and it is developed into an intelligent optical network capable of performing automatic switching functions, representing the mainstream direction of intelligent optical networks. Routing technology is one of the core technologies of ASON, and plays an important role in realizing the dynamic routing of connections. The routing protocol used in the traditional IP network is the Open Shortest Pass First (OSPF) protocol, which enables dynamic routing of routes. ASON routing requires more features and greater flexibility. Generally, OSPF (OSPF-TE) routing protocol with traffic engineering based on Generalized Multi Protocol Label Switching (GMPLS) extension is used. In order to adapt to the development of the ASON routing system, the International Telecommunication Union ITU-T Recommendation G8080/Y.1304 gives the relationship between the ASON routing domain hierarchy and the subnet point group. G7715/Y.1706 defines a protocol-independent method for describing ASON routing techniques, including the functional components of ASON routing structure, path selection, routing attributes, abstract information, and state diagram transitions. The routing structure component of ASON includes a routing controller (Router Controller, referred to as RC for short), a routing information database (Data Base, referred to as DB), a link resource manager (LRM for short), and a protocol controller (Protocol). Controller, referred to as PC). The Routing Controller (RC) is responsible for responding to the request for routing information by the Connect Controller (CC) for establishing a connection. It exchanges routing information with the peer RC, and answers the routing query after querying the routing information database. It is also responsible for returning the topology information needed for the management network. In ASON's switched optical network, the requested end-to-end optical channel connection is limited. The channel selection for a connection request will be Constraint Shortest Path First (CSPF). CSPF is mostly integrated in the RC and is responsible for constraining route calculations. The constraints of the route query include, but are not limited to, the bandwidth, the link protection type is strictly matched, the minimum hop count, the minimum link cost, the load balancing, the preemption, the priority, the specified partial explicit route, and the like. All of the above constraints can be specified in the routing query established by a connection, but some constraints (such as the minimum hop count and the minimum link cost) are contradictory. How to choose the priority constraint among the many constraints? Different users have different needs. How to make a reasonable choice according to the diversified needs of users becomes a problem that the routing module must solve. In the related art, the traditional method relies on the shortest path algorithm to directly calculate the path from the first node to the tail node of the query route and compare with the constraint of the route, and one or more paths satisfying the routing constraint condition. Join the result set of the route calculation. When the user changes the priority of the constraint, the shortest path algorithm needs to be modified, which affects the flexibility of the constraint routing calculation. SUMMARY OF THE INVENTION A primary object of the present invention is to provide a route query apparatus and method to solve at least one of the above problems. According to an aspect of the present invention, a route query apparatus for an automatic switched optical network is provided, including: a query policy establishment module, configured to establish a query policy template according to a query policy template when receiving a route query request that has not been received before a query policy corresponding to the route query request that has not been received; the query policy saving module is configured to save the correspondence between the route query request that has not been received and the query policy corresponding to the route query request that has not been received. The query policy execution module is configured to search for and execute the query policy corresponding to the received route query request in the corresponding relationship. The foregoing query policy template includes: a first query unit sub-template, configured to generate a first query unit according to the route query request that has not been received, where the first query unit is configured to parse the received route query request and send the first The second query unit sub-template is configured to generate a second query unit according to the route query request that has not been received, wherein the second query unit is configured to determine whether the received route response of the first query request satisfies receiving The constraint of the route query request to, if not satisfied The foot constraint determines whether the constraint can be changed. If the constraint can be changed, the change constraint sends a second query request. The foregoing first query request includes at least one of the following: an actual route query request, and a full network topology query request. The second query unit is further configured to determine whether the routing response of the first query request satisfies the user-defined extended constraint simultaneously on the premise that the routing response of the first query request satisfies the constraint of the received routing query request. The foregoing query policy execution module includes: a first execution unit, configured to search for a query policy corresponding to the received route query request in the corresponding relationship, and trigger a first query unit of the query policy, parse the received route query request, and send the a second query unit, configured to trigger a second query unit of the query policy corresponding to the received route query request, and determine whether the route response of the received first query request satisfies the received route query request Constraints and/or user-defined extended constraints, if the constraints are not met, determine whether the constraints can be changed, if the constraints can be changed, then change the constraints and send a second query request. The second query unit is further configured to determine whether the routing response of the second query request satisfies the changed constraint, and if not, determine whether the constraint can be changed again until the query succeeds or the query fails because the constraint cannot be changed. According to another aspect of the present invention, a route query method for an automatic switched optical network is provided, including: generating a query policy corresponding to a route query request that has not been received before; and saving the unreceived Corresponding relationship between the route query request and the query policy corresponding to the route query request that has not been received; searching for the query policy corresponding to the received route query request in the correspondence relationship and executing. The foregoing query policy template includes: a first query unit sub-template, configured to generate a first query unit according to a route query request that has not been received, where the first query unit is configured to parse the received route query request and send the same a first query request corresponding to the route query request; the second query unit sub-template is configured to generate a second query unit according to the route query request that has not been received, wherein the second query unit is configured to determine the received Whether the query response of the query request satisfies the constraint of the received route query request, if the constraint is satisfied, the query is successful, otherwise it is judged whether the constraint can be changed. If the constraint can be changed, the constraint is changed and the corresponding route query request is sent. The second query request, otherwise the query fails. The foregoing first query request includes at least one of the following: an actual route query request, and a full network topology query request. After determining that the routing response of the first query request satisfies the constraint of the received routing query request, the second query unit continues to determine whether the routing response satisfies the user-defined extended constraint. The executing the query policy includes: triggering the first query unit, parsing the received route query request, and sending the first query request; triggering the second query unit, determining whether the route response of the received first query request satisfies the received route Query the constraint of the request and/or the user-defined extended constraint. If it is satisfied, the query is successful; if it is not satisfied, it is judged whether the constraint can be changed. If the constraint can be changed, the constraint is changed and the second query request is sent, otherwise the query fails; Whether the routing response of the second query request satisfies the changed constraint, if yes, the query is successful, otherwise it is judged whether the constraint can be changed again until the query succeeds or the query fails because the constraint cannot be changed. Through the invention, based on the policy template, different query policies are established according to different query requests, and the corresponding relationship between the query request and the query policy is saved for subsequent use, and the flexibility of the constraint route calculation is solved. The problem, in turn, achieves the effect of satisfying diverse routing query requests. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 1 is a flowchart of a route query method according to an embodiment of the present invention; FIG. 2 is a flowchart of a route query method according to an example of the present invention; FIG. 3 is a route query device according to an embodiment of the present invention; FIG. 4 is a schematic structural diagram of a route inquiring device according to a preferred embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. 1 is a flow chart of a route query method according to an embodiment of the present invention. As shown in FIG. 1, the route query method according to the embodiment of the present invention includes: Step S102: Establish a query policy corresponding to a route query request that has not been received before according to the query policy template. Step S104: The correspondence between the unreceived route query request and the query policy corresponding to the unreceived route query request is saved. Step S106: Search for a query policy corresponding to the received route query request in the foregoing correspondence and execute the query policy. By the above method, can be easily and quickly set up corresponding to the query request query strategy, the strategy for building a query strategy ^ ¹ correspondence between the query corresponding to the saved queries, in a subsequent working with the same process occurs when the When querying a request, the corresponding query policy can be directly invoked, that is, only when a query request never appears before, the corresponding query policy needs to be established, and when the query request appears again, it directly from the corresponding relationship. Calling the corresponding query strategy can eliminate the need to repeatedly establish a query strategy. This query method greatly improves the query efficiency. At the same time, since the query strategy is established according to the preset query policy template, instead of establishing the latter query strategy based on clearing the previous query strategy, the method for establishing the query strategy makes different or even contradictory query strategies. It can exist at the same time, avoiding the establishment and clearing of query strategies due to different and contradictory query requests, which greatly improves the flexibility of route query. In the above method, for the query request that has not appeared before, after the corresponding query policy is established and the corresponding relationship is saved, the corresponding query policy needs to be reversed from the corresponding relationship and executed, which is followed by subsequent reception. The execution process of the query request is the same. Preferably, the query policy template mentioned in step S102 may further include:

(1) The first query unit sub-template is configured to generate a first query unit according to the unreceived route query request, where the first query unit is configured to parse the received route query request and send the route query request Corresponding first query request.

(2) The second query unit sub-template is configured to generate a second query unit according to the route query request that has not been received, where the second query unit is configured to determine whether the route response of the received first query request satisfies the above The constraint of the received route query request, if the constraint is met, the query is successful, otherwise it is determined whether the constraint can be changed. If the constraint can be changed, the second query corresponding to the received route query request is sent after the constraint is changed. Request, otherwise the query fails. The above query policy template is the basis for establishing a query policy. After receiving a route query request that has never occurred, the information included in the route query request that has never occurred is only required to use the above query policy template as a framework (mainly The information of various constraints is populated into the query policy template, and an executable query policy can be obtained, and the final route query result can be obtained by executing the strategy. Preferably, the foregoing first query request may include a request of at least one of the following: an actual route query request, a full network topology query request. In the specific implementation process, before the actual route query is performed, you can perform the topology query of the entire network to obtain the topology response of the entire network, and then perform the actual route query. Preferably, after determining that the first query request routing response satisfies the constraint of the received routing query request, the foregoing second query unit may further determine whether the routing response meets the user-defined extended constraint at the same time. The above steps actually correspond to a user extension function, that is, the user can further add constraints according to the needs of the original routing query request, and the constraints are determined when the routing response of the first query request meets the requirements. Also have to be considered. Preferably, performing the foregoing query policy in step S106 may further include the following processing:

(1) triggering the first query unit, parsing the received route query request and transmitting the first query request.

(2) triggering the second query unit to determine whether the route response of the received first query request satisfies the constraint of the received route query request and/or the user-defined extended constraint, and if satisfied, the query succeeds.

(3) If it is not satisfied, it is judged whether the above constraint can be changed. If the above constraint can be changed, the above constraint is changed and the second query request is sent, otherwise the query fails.

(4) determining whether the routing response of the second query request satisfies the changed constraint, and if yes, the query is successful, otherwise it is determined whether the constraint can be changed again until the query is successful or the query fails because the constraint cannot be changed. After the query policy corresponding to the received route query request is found from the saved correspondence, only the query policy needs to be triggered to obtain the final route query result. From the establishment process of the above query strategy, each query policy saved in the corresponding relationship is actually a specific executable The process of its execution corresponds to the structure of the query policy template. It is worth noting that when the constraints are variable, the query process can be executed cyclically until the query is successful, or the constraints cannot be changed. 2 is a flow chart of a route query method in accordance with an example of the present invention. The above preferred embodiments will be described in detail below with reference to FIG. This example is used to implement the following query request constraints: When establishing a service, it must strictly follow the link of the multiplex section level. When this service fault is dynamically restored, it is preferentially placed on the link of the multiplex section level, but Walk on the unprotected type of link. The RC's constrained route calculation is generally isolated from the service. Therefore, the establishment of the service and the recovery of the service are respectively corresponding to one route query in the RC. The RC-to-link protection type routing algorithm of this example is as follows: Provides the specified "link protection level" constraint, provides "whether it is strictly matched, and constrains. When the user does not specify the link protection level, the route calculation does not Consider this constraint, that is, any level of link can be used as an alternate route. When the user specifies "link protection level, when, at the same time, specify" strict match, then only the user-specified link is considered in the route calculation, and any other level of link is excluded. When the user specifies the "link protection level" and simultaneously specifies "non-strict matching," the route calculation considers a link greater than or equal to this level, excluding any links below this level. Combining routing requests with RC routing algorithms The following two different routing query strategies are constructed for service establishment and service recovery.

(1) constructing a route query policy when the service is established, as shown in FIG. 2, the method includes the following steps: Step S202: Construct a query policy, that is, construct a query policy according to the route query request, where the query policy includes: a first query unit, This route request constraint includes only the strictly matched link level, and does not need to query the entire network topology, because jt匕 constructs a route query message to the RC in the jtb unit. The multiplex section level link is specified in this query and is strictly matched, and carries constraints such as bandwidth, preemption, and priority. The second query unit determines the query result of the RC. If the CC request is satisfied, the query result is transmitted to the CC. Otherwise, it is determined whether the query constraint can be relaxed. If the query constraint is relaxed, the route query is continued to be sent to the RC. In this example, the constraints cannot be relaxed. On the premise that there is a user extension constraint, the second query unit needs to determine whether the user's extended constraint is satisfied while determining whether the RC query result satisfies the CC request. There is no user extension constraint in this instance, and no judgment is needed. In step S204, the correspondence relationship is saved, and the storage space is allocated for the query policy, and the storage space address is specifically represented by a function pointer. Establish a query request and a query strategy-correspondence relationship, where the query request can be embodied as a set of query constraints. This correspondence can be set in advance or dynamically registered. Step S206, searching for a query policy, that is, inverting the query policy in the corresponding relationship. Step 4: S208, executing a first query unit of the query policy, and sending a first query request. Step S210: Perform a second query unit of the query policy, and determine whether the route response of the first query unit satisfies the constraint of the query request. Step S212, further determining whether the routing response of the first query unit satisfies the user extension constraint. In this example, there is no user extension constraint, and the step is ignored. Step 4: S214, when the routing response of the first query unit does not satisfy any of the above constraints, determine whether the constraint can be changed, and then continue to send the second query request, otherwise the query fails. This step can be iteratively executed until the best route is queried, or the query fails. Step S216: When a route that satisfies all constraints is obtained, the route is returned, and the query is successful.

(2) The query strategy when constructing service recovery is generally the same as when the service is established, and the difference is only how to construct the first query unit and the second query unit of the query policy. The first query unit queries the RC for the route, and carries the link protection type to the multiplex section link level, and strictly matches. The second query unit determines whether the query is successful. If successful, return directly to the CC. Otherwise, the link protection type is changed to the unprotected link level and is strictly matched. If successful, return directly to cc. Otherwise, the link protection type is changed to the multiplex section link level and is not strictly matched. Return the query result to the CC, success or failure. FIG. 3 is a schematic structural diagram of a route inquiring device according to an embodiment of the present invention. As shown in FIG. 3, the route querying apparatus according to the embodiment of the present invention includes: a query policy establishing module 32, configured to: when receiving a route query request that has not been received before, establish and not receive the query policy template according to the query policy template. The routing query request corresponds to the query policy. The query policy saving module 34 is configured to save a correspondence between the unreceived route query request and the query policy corresponding to the unreceived route query request. The query policy execution module 36 is configured to search for and execute the query policy corresponding to the received route query request in the foregoing correspondence. Through the above device, it is only necessary to establish a corresponding query policy when a query request never occurs, and when the query request occurs again, the corresponding query policy is directly called from the corresponding relationship without repeating Establish a query strategy to improve query efficiency. At the same time, the above devices support different or even contradictory query strategies at the same time, which solves the problem of low flexibility of constrained route calculation and can meet diverse user requirements. Preferably, the foregoing query policy template may further include:

(1) The first query unit sub-template is configured to generate a first query unit according to the unreceived route query request, where the first query unit is configured to parse the received route query request and send the route query Request the corresponding first query request.

(2) The second query unit sub-template is configured to generate a second query unit according to the route query request that has not been received, where the second query unit is configured to determine whether the route response of the received first query request is satisfied. The constraint of the received route query request, if the constraint is met, the query is successful, otherwise it is determined whether the constraint can be changed. If the constraint can be changed, the constraint is changed, and then the second corresponding to the received route query request is sent. Query the request, otherwise the query fails. The above query policy template is the basis for establishing a query policy. After receiving a route query request that has never occurred, the information included in the route query request that has never occurred is only required to use the above query policy template as a framework (mainly The information of various constraints is populated into the query policy template, and an executable query policy can be obtained, and the final route query result can be obtained by executing the strategy. Preferably, the foregoing first query request may include a request of at least one of the following: an actual route query request, a full network topology query request. In the specific implementation process, before the actual route query is performed, you can perform the topology query of the entire network to obtain the topology response of the entire network, and then perform the actual route query. Preferably, the foregoing second query unit may be further configured to: if the route response of the first query request satisfies the constraint of the received route query request, determine whether the route response of the first query request satisfies the user-defined extension at the same time. constraint. In a specific implementation process, the second query unit can serve as a carrier for the user extension function, so that the user can add constraints according to actual needs. Of course, it is also possible to establish another independent unit to carry this function. Preferably, the query policy execution module 36 may further include: a first execution unit 362, configured to search for a query policy corresponding to the received route query request in the correspondence relationship and trigger a first query unit of the query policy, and parse the receiving The route query request is sent and the first query request is sent. The second executing unit 364 is configured to: trigger a second query unit that triggers a query policy corresponding to the received route query request, and determine whether the route response of the received first query request satisfies the constraint of the received route query request And/or a user-defined extended constraint, if the constraint is not satisfied, it is determined whether the constraint can be changed, and if the constraint can be changed, the constraint is changed and a second query request is sent. The query policy execution module 36 actually corresponds to the query policy creation module 32, the first execution unit 362 is arranged to execute the first query unit, and the second execution unit 364 is arranged to execute the second query unit. Preferably, the second querying unit may further be configured to determine whether the routing response of the second query request satisfies the changed constraint, and if not, determine whether the constraint can be changed again until the query succeeds or the query cannot be changed again. failure. Under the premise that the constraints are variable, the second query unit can perform the query action iteratively until the optimal route is queried, or the query fails. From the above description, it can be seen that the present invention fully utilizes the input and output interface of the routing controller RC and the CSPF module, which greatly improves the flexibility of the constraint routing calculation. In addition, the present invention uses a scheme for establishing a query policy device corresponding to a routing query request, so that different routing query requests can establish different query policies, and a routing query request and a query policy are established between each other. — Corresponding relationship, when the user changes the query request, it only needs to reconstruct the query policy device, which does not affect the established query strategy and improves the scalability of the system. At the same time, when the user's route query request has expired, it is only necessary to find the corresponding query policy in the corresponding relationship, and it is not necessary to re-establish the query policy, thereby improving the query efficiency. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be executed by a computing device Implemented so that they can be stored in a storage device by a computing device, and in some cases, the steps shown or described can be performed in an order different from that herein, or separately The integrated circuit modules are implemented by making a plurality of modules or steps of them into a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Claims

Claim

A route query device, which is applied to an automatic switched optical network, and includes:

The query policy establishing module is configured to: when receiving a route query request that has not been received before, establish a query policy corresponding to the unreceived route query request according to the query policy template;

a query policy saving module, configured to save a correspondence between the unreceived route query request and the query policy corresponding to the unreceived route query request;

The query policy execution module is configured to search for and execute the query policy corresponding to the received route query request in the corresponding relationship.

2. The device according to claim 1, wherein the query policy template comprises:

a first query unit sub-template, configured to generate a first query unit according to the unreceived route query request, where the first query unit is configured to parse the received route query request and send the first Query request

a second query unit sub-template, configured to generate a second query unit according to the unreceived route query request, where the second query unit is configured to determine the received route response of the first query request Whether the constraint of the received route query request is satisfied, if the constraint is not satisfied, it is determined whether the constraint can be changed, and if the constraint can be changed, the constraint is changed to send a second query request.

The device according to claim 2, wherein the first query request comprises at least one of the following: an actual route query request, a network-wide topology query request.

The device according to claim 3, wherein the second query unit is further configured to determine, under the premise that the routing response of the first query request satisfies the constraint of the received routing query request Whether the routing response of the first query request satisfies the user-defined extended constraint at the same time.

The device according to claim 4, wherein the query policy execution module comprises: a first execution unit, configured to search for the query policy corresponding to the received route query request in the correspondence relationship And triggering the first query unit of the query policy, parsing the received route query request, and sending the first query request; a second execution unit, configured to trigger a second query unit of the query policy corresponding to the received route query request, to determine whether the received route response of the first query request satisfies the received Routing the query request constraint and/or the user-defined extended constraint, if the constraint is not satisfied, determining whether the constraint can be changed, if the constraint can be changed, changing the constraint and transmitting the second Query request.

The device according to claim 5, wherein the second querying unit is further configured to determine whether the routing response of the second query request satisfies the changed constraint, and if not, determine whether it can be changed again. The constraint fails until the query is successful or because the constraint cannot be changed again.

7. A route query method, applied to an automatically switched optical network, comprising:

The query policy corresponding to the route query request that has not been received before is established according to the query policy template;

And storing a correspondence between the unreceived route query request and the query policy corresponding to the unreceived route query request;

The query policy corresponding to the received route query request is searched for and executed in the corresponding relationship.

8. The method according to claim 7, wherein the query policy template comprises:

a first query unit sub-template, configured to generate a first query unit according to the unreceived route query request, where the first query unit is configured to parse the received route query request and send the The first query request corresponding to the route query request;

a second query unit sub-template, configured to generate a second query unit according to the unreceived route query request, where the second query unit is configured to determine the received route response of the first query request Whether the constraint of the received route query request is satisfied, if the constraint is satisfied, the query is successful, otherwise it is determined whether the constraint can be changed, and if the constraint can be changed, the constraint is changed and then sent and the received The routing query request corresponds to the second query request, otherwise the query fails.

The method according to claim 8, wherein the first query request comprises at least one of the following: an actual route query request, a network-wide topology query request.

The method of claim 9, wherein the second query unit continues to determine whether the route response is after determining that the route response of the first query request satisfies the constraint of the received route query request At the same time, user-defined extended constraints are met.

11. The method according to claim 10, wherein executing the query policy comprises:

Triggering the first query unit, parsing the received route query request, and transmitting the first query request;

Trimming the second query unit, determining whether the received routing response of the first query request satisfies the constraint of the received routing query request and/or the user-defined extended constraint, and if satisfied, queries Success

If it is not satisfied, it is judged whether the constraint can be changed, if the constraint can be changed, the constraint is changed and the second query request is sent, otherwise the query fails;

Determining whether the routing response of the second query request satisfies the changed constraint, if yes, the query is successful, otherwise it is determined whether the constraint can be changed again until the query is successful or the query fails because the constraint cannot be changed.